AI Made Building Your Product Free. Crossing the Chasm Is Still Exactly Where It Always Was.

Geoffrey Moore wrote Crossing the Chasm in 1991. Back then, building a credible software product cost real money — teams of engineers, months of work, expensive hardware. Getting a product built was half the battle. Selling it to pragmatists was the other half.

Thirty-five years later, one of those halves has effectively disappeared.

An undergraduate with a laptop and an LLM can now produce a working prototype of almost any SaaS product in a weekend. Building is free. Shipping is free. Iterating is free.

Selling is not. And that asymmetry is the single most important thing to understand about the chasm in 2026.

Crossing the Chasm is Geoffrey Moore’s theory that technology products face a discontinuity between early adopters (who buy vision) and the early majority (who buy proven references). Products stall in this gap because the go-to-market motion that won early adopters doesn’t work for pragmatists. Crossing the chasm requires a narrow beachhead segment, whole-product completeness, reference customers, and — critically — a different operating model from the one that reached the early adopters.

Sign up (free) to allocate dedicated teams to new products

What the Chasm Actually Is (Quick Recap)

Moore built on Everett Rogers’ Diffusion of Innovations curve — innovators (2.5%), early adopters (13.5%), early majority (34%), late majority (34%), laggards (16%). Moore’s insight was that there’s a discontinuity between early adopters and the early majority. They don’t behave the same way. They don’t buy for the same reasons. They don’t trust the same evidence.

• Early adopters buy vision. They’ll tolerate a rough product if it solves a problem their competitors haven’t solved yet. They want to be first.
• The early majority buys references. They’ll wait for someone they trust — another pragmatist in their industry — to prove the product works before they commit.

The chasm is the gap where products die. You’ve signed your visionary customers. Your revenue flat-lines. The pragmatists are watching, and they don’t see enough other pragmatists in the logo slide to take the risk.

Moore’s prescription was a beachhead strategy: pick one narrow pragmatist segment, become the obvious choice for that segment, then expand. Bowling pin by bowling pin. He was right in 1991 and he’s right now.

What’s changed is why the chasm is wider.

The 2026 Reframe: AI Didn’t Make the Chasm Smaller. It Made It Wider.

Here is the asymmetry that defines product strategy in 2026:

The cost of producing a new solution has collapsed to near zero. The cost of convincing a customer to buy it has not changed at all.

Every PM instinctively gets the first half. Cursor, Claude Code, v0, Lovable — the tools are astonishing. What took a team of eight six months in 2019 takes one engineer a weekend in 2026.

Almost nobody is grappling with the second half honestly. A pragmatist CTO in 2026 still needs:

• A peer they respect to vouch for the product
• A detailed security review
• Integration with their existing stack
• A procurement process measured in months
• A deployment plan that doesn’t break their business
• A renewal conversation a year later that doesn’t blow up

None of that got easier because you built your MVP in AI. In fact, it got harder, because your prospect’s inbox is now full of AI-generated pitches from competitors who also built their MVP in AI. Trust is the bottleneck. Distribution is the bottleneck. Reference customers are the bottleneck.

The chasm used to be: “can you build a whole product?” It is now: “can you build enough trust and distribution to be chosen from a sea of products that all look equally good in a demo?”

That changes what should be on your roadmap. A lot.

Products, Not Companies: The Portfolio Framing

Here’s where most chasm content goes wrong. It treats chasm-crossing as something a company does. “Our company needs to cross the chasm.” That’s the wrong unit of analysis.

A mature company has a portfolio of products at different lifecycle stages simultaneously. A cash-cow product in late majority. A growth product climbing the bowling alley. A new product attempting to find visionary customers. A speculative bet that isn’t even a product yet. See the BCG Growth-Share Matrix for the classic portfolio lens and the Ansoff Matrix for how risk varies across your mix.

The roadmap question is not “what lifecycle stage is our company at?” It’s:

Given the portfolio of products we have, are we allocating the right amount of resource to the right problems at the right time?

This is why the Run / Grow / Transform lens matters so much in the chasm conversation. You cannot cross the chasm with a product that is side-of-desk work for a team whose day job is keeping the Run product alive. You need a dedicated team. You need a protected budget. You need a clear objective — likely the same objective for 18 months, with proper key results that the team will stand behind.

And crucially: you need the board to have the grown-up conversation about whether you are genuinely spending something on Transform at all. Silence on Transform is the most common failure mode I see. “We’ll get to it next year” is how companies end up disrupted from underneath by a competitor who did allocate a dedicated team.

What Your Roadmap Should Actually Look Like at Each Stage

This is the table that should exist in every PM’s head but rarely does. At each stage of a product’s journey, the roadmap composition, team shape, and objective type all need to shift deliberately.

Notice the pattern. The roadmap isn’t only “what features ship when.” It’s what shape of team, working on what objective, targeting what customer reality. Capacity-based planning is the tool that makes these trade-offs visible. And if you’re genuinely still pre-chasm — trying to determine whether you have the visionary traction to cross at all — the early-stage validation cluster is the relevant library: problem-solution fit and product-market fit measurement are the load-bearing diagnostics before any chasm conversation is worth having.

The Side-of-Desk Anti-Pattern

The most common failure I see in PE and NED work is the side-of-desk new product. Here’s the pattern:

1. The CEO or founder has a genuinely good idea for a new product.
2. Nobody does a proper business case. Nobody commits to a target.
3. It gets allocated to an existing team who already has a full day job.
4. The team does it when they can, between fires.
5. Six months later the product is half-finished, nobody owns it, and the CEO is frustrated that it “hasn’t taken off”.

The fix is embarrassingly simple and almost nobody does it:

1. Write a proper business case with revenue/customer targets that someone will stand behind personally.
2. If it’s viable, allocate a minimum viable new-product team: 2 engineers and 1 product person. Dedicated. Full-time. Nothing else.
3. Protect that team from interrupt work with the same discipline you protect your WIP limits .
4. Measure the team on outcomes, not output. Are we getting reference customers? Are they renewing? Not: are we shipping features?

Most companies can afford this. What they can’t afford is the priority whiplash of pulling those engineers onto a Run fire every time something breaks. That’s the killer. Dedicated means dedicated.

Try RoadmapOne to protect dedicated team capacity — free sign-up

Is Your Product Stuck in the Chasm a Roadmap Problem or a GTM Problem?

This is the single most important diagnostic question. And it’s the one most product leaders get wrong, because our instinct is to reach for the tool we have — the roadmap.

The test I use on boards:

If your product has been in-market for 18+ months, has happy visionary customers, and revenue is flat, the problem is almost certainly NOT that you need more features.

Going back to my old boss: a bad salesperson will ALWAYS ask for more features. Because it’s easier to go back to engineering with “the prospect said they’d sign if we had X” than to admit you don’t know how to sell what you have. A good salesperson looks at the product and figures out how to sell this, to this pragmatist, with these reference customers.

So when the roadmap starts filling up with prospect-specific features, it’s a red flag. It usually means:

• Your GTM motion doesn’t match the buyer you’re actually selling to (still selling like you’re selling to visionaries when you’re trying to cross the chasm)
• You have the wrong salespeople (hunters vs. farmers; vision-sellers vs. reference-sellers)
• You don’t have the sales collateral pragmatists need (ROI case studies, security docs, integration stories)
• You don’t have enough pragmatist references to give the next pragmatist confidence

None of that is fixable by your engineering team. Adding features to a chasm-stuck product is often actively harmful — you’re adding surface area, bloat, and maintenance debt while the underlying problem (distribution, trust, GTM motion) goes unaddressed. You’re creating a feature factory with a fancy AI-era coat of paint.

The PE / NED Diagnostic for a Chasm-Stuck Product

When I look at a portfolio company with a product I suspect is chasm-stuck, here’s what I actually check — in order:

1. Is there a dedicated team on this product? If it’s split across two other products or reports into a Run leader, that’s already a smell.
2. Is there a written business case with targets ? Not an OKR. A proper business case with revenue, timing, and investment assumptions someone signed off on.
3. What does pragmatist segment concentration look like? Do we have three reference customers in the same narrow segment, or twelve logos scattered across six industries? Scatter = still trying to sell to visionaries.
4. What’s the logo retention in the target segment specifically? Not overall. In the segment we claim to be winning.
5. What is the GTM team composition? Who is the person whose job it is to close pragmatist buyers? Do they have the right collateral?
6. What is the roadmap composition? If >30% of the roadmap is prospect-specific features rather than segment-wide capability investment, the sales function is driving the roadmap. That’s the wrong way around.

Usually by question 3 or 4 the problem is obvious. And it’s almost never “we need to ship more.”

The Cagan / SVPG Angle: This Is an Operating Model Shift

Marty Cagan is right that the product operating model matters more than any individual framework. And the chasm transition is fundamentally an operating model shift.

Selling to visionaries is a vision-led operating model. Your best PM is often the founder or a close proxy. Decisions are fast. You tolerate rough edges. You say yes to logo-driving features because one logo changes the trajectory.

Selling to the early majority is an outcome-led operating model. Decisions are driven by data from your target segment. You say no to vanity logos outside your beachhead. You measure reference customer creation, not feature velocity. Your team needs to internalise the four product risks — especially Value and Viability, which are the ones that bite at the chasm.

Most chasm-stuck products are running a vision-led model long after the visionaries stopped buying. The founder’s instincts — which got the product to product-market fit — are now actively working against crossing the chasm, because a pragmatist buyer doesn’t care about vision. They care about whether five other companies in their industry are getting measurable value.

How RoadmapOne Helps

This is what RoadmapOne was built for. A visual capacity grid lets you see — at a glance — whether your supposed Transform product actually has a dedicated team, or whether those two engineers are also allocated to three other squads. Tag objectives by Run / Grow / Transform or by Three Horizons and the analytics tell you what percentage of your capacity is actually going to the new products you claim to be investing in. Usually much less than the board thinks.

Frequently Asked Questions

Is “crossing the chasm” still relevant in 2026?

More relevant, not less. The underlying psychology — pragmatists buy references, not vision — hasn’t changed. What’s changed is that AI made the build side of the chasm easier, which makes the sell side the dominant constraint. The chasm is now disproportionately about trust and distribution.

How long does crossing the chasm usually take?

For a B2B SaaS product with a narrow beachhead segment, 18–36 months from early-adopter revenue to pragmatist dominance is normal. Any less and you probably haven’t actually crossed — you’ve just got more visionaries. Any more and the window is closing and a better-resourced competitor will beat you into the early majority.

Should I still do a big product launch?

Only if your beachhead segment is genuinely ready. A big launch to the broad market while you’re still mid-chasm is usually a waste of budget — pragmatists don’t buy from launch events, they buy from references. Better to spend that money on reference customer creation.

How do I know if I’m stuck in the chasm?

The classic signs: revenue has plateaued after initial visionary wins; your pipeline is broad and shallow across many industries rather than narrow and deep in one; your roadmap is dominated by prospect-specific features rather than segment-wide capability; your best salespeople are quietly asking for more engineering resource. Any two of those and you should investigate.

Do I need more engineers to cross the chasm?

Almost never. You usually need a dedicated team (even a small one), a clearer target segment, and more investment in GTM — different sales skills, better collateral, stronger reference customers. More engineers is a rounding error compared to fixing the distribution problem.

Sign up (free) to visualise your chasm-stage resource allocation

Conclusion

The chasm hasn’t moved. AI didn’t help you cross it — it just made the entrance look more crowded. The work of convincing a pragmatist buyer to bet their career on your product is the same work it was in 1991.

What has changed is the leverage. A company that runs the chasm transition well — proper business cases, dedicated minimum viable teams, ruthless segment focus, and honest allocation of Transform capacity — can now do it with a fraction of the build cost that companies in 1991 faced. The saving goes straight into the bits that actually matter: GTM motion, reference creation, and segment focus.

The companies that will win the next decade aren’t the ones who use AI to build more features faster. They’re the ones who notice that build cost has collapsed, that sell cost hasn’t, and who reallocate their roadmap accordingly.

Most won’t. That’s the opportunity.