Going AI-First Without Killing the Cash Cow

A lot of the SaaS CEOs I talk to right now are living with the same tension. They run a real business with real customers and real recurring revenue, and they also believe, sometimes quite strongly, that the way their category works today will look outdated within five years. So they start building the AI-native version of their product. Then they walk into a leadership meeting, ask the team to shift focus toward something that has zero revenue, and watch every head of sales, marketing, and engineering push back.

This came up in depth during a recent Enterprise Mastermind call. One founder running a mature, profitable SaaS product described exactly this situation. His team had already built a new AI-first product under its own brand, launched a beta, and moved about half of engineering onto it. The hard part was everything after that: deciding how much of the company to point at the new thing, and how to bring a revenue team along when their numbers still come from the old one.

Why the Legacy Business Fights Back

The pushback is completely rational, and it helps to understand why before you try to overcome it. Your sales reps, SDRs, and marketers are measured on revenue that comes from the existing product. When you ask them to spend their webinars, email campaigns, and content on a product that is still searching for product-market fit, you are asking them to trade a known number for an unknown one. Engineering has its own version of this, because the legacy product still needs maintenance, security work, and enough new features to stay competitive.

The founder on our call put a number on the cost. When his marketing team shifted campaigns toward the new product, new MRR from the core business dipped noticeably for that period. It wasn't catastrophic, but it was real. His view was that he didn't care about a few thousand dollars of extra MRR from the old product; he wanted the kind of step change in growth that the old product would never deliver again. That's a reasonable CEO position. It's also exactly the kind of trade-off that makes a revenue team nervous.

• The revenue team's incentives point backward. Their comp and targets are tied to the product that is paying the bills today.
• Engineering can't abandon the legacy product. Existing customers still need bug fixes, uptime, and a product that stays relevant in the market.
• The new product needs completely different go-to-market. A webinar that sells the legacy tool won't sell the AI-native one, so marketing effort can't simply be shared.
• There is a measurable short-term cost. Shifting focus usually means a dip in new MRR from the core product, at least for a while.

Ryan summed up the underlying dynamic by pointing back to Clayton Christensen's The Innovator's Dilemma, which he studied with Christensen directly. As Ryan put it, "cash-flowing legacy companies have zero incentive to innovate for the new thing, unless they're closely held and privately held. Then you can take the short-term pain to get the long-term gain." Kodak and Blockbuster each had roughly a decade to respond to the shift that eventually took them out. The founders who survive these transitions are the ones who notice early and act while the core business still has the cash to fund the experiment.

The Intercom Playbook, and Why You Shouldn't Copy It Blindly

Almost every founder wrestling with this has studied what Intercom did with Fin. They stopped building new features for the classic product, put everything behind the AI agent, eventually renamed around it, and talked publicly about how hardcore they had to be. Their co-founders have said that if cutting the old stuff doesn't feel painful, you probably aren't cutting enough.

The founder on our call made a sharp point about that story. Intercom is a customer support company, and AI agents happened to fit support extremely well. Fin was also built as a layer on top of Intercom, so going all in didn't mean walking away from the underlying platform. Your category may not map so cleanly. Forcing an all-in move because it worked for someone else, in a business with different economics and different customers, can end badly.

• Study the playbook for its principles. The lesson from Intercom is about focus and willingness to accept pain, not about copying their exact moves.
• Check whether AI fits your category as well. Support was an unusually good match for AI agents; your space may need a different path.
• Look at your architecture. If the new product is a layer on the same engine, you can share more of the stack than if it's a clean-sheet rebuild.

So the useful question becomes less about whether to go all in and more about how much commitment is enough, and when the evidence justifies more.

50/50, 90/10, or 95/5: Picking Your Split

The founder in our session had landed at a 50/50 split between old and new. He was honest that this felt more like a compromise than a decision. His team had proposed it, he couldn't quite find the conviction to push harder, and he was already asking himself whether he'd still be comfortable with 50/50 in November and December.

Other members shared the splits they've used. One CEO going through the same transition said his entire development team now works on the new product, while his CTO handles firefighting and maintenance on the legacy platform. That's closer to a 95/5 split on the engineering side, and he described it as an attempt to firewall the two businesses as much as possible. Another founder took the most extreme route: he sold the legacy part of his business outright, merged it into a company where a separate team runs it, and now spends none of his time on the old product. His new product is moving toward a fully agentic model with almost no user interface at all.

• Total segmentation. Put nearly all developers on the new product and assign one senior leader to keep the legacy product running.
• Sell or spin out the legacy line. If a buyer or partner can run it, you free up all of your own attention for the new bet.
• A separate entity. One member suggested breaking the new product into its own legal entity so employees know exactly which business pays them, which realigns incentives quickly.
• The 50/50 middle ground. It's the easiest to get agreement on, and also the one most likely to leave both products under-resourced.

The separate-entity idea got pushback. For a company with outside investors, where restructuring engineering alone took three months, creating new entities and moving people into them felt like far more work than it was worth. That's a fair objection, and a good reminder that the right split depends on your cap table, your team, and how far along the new product already is.

Let Revenue, Not Conviction, Tell You When to Go All In

Ryan's advice was the most practical part of the discussion. He suggested that the degree of commitment should follow the evidence. In his words, "to the extent that you don't have 95% plus confidence that you're right, I would wait until you have revenue." He wasn't talking about waiting for the new product to match the old one. He suggested a concrete bar: get to around $15,000 a month in total MRR on the new product. That's enough to show that real customers will pay for what you've built.

His full framework was simple. Keep putting resources into the new thing. If it runs into problems, pivot it, and expect a couple of iterations before it becomes the next good thing. Then, as Ryan put it, "once you actually have product-market fit for the new thing, then you put all your bullets behind it."

• Keep investing steadily before PMF. The new product needs enough resources to iterate quickly and learn.
• Expect iterations. Your first version of the AI-native product may not be the one that wins, and that's normal.
• Set a revenue milestone. Something like $15,000 in MRR is a clear, defensible signal to your team and your board.
• Go all in after PMF. Once customers are paying and pulling, that's the moment to shift the rest of the company.

This approach also solves part of the team problem. It's much easier to ask a revenue team to move over when you can show them paying customers than when you're asking them to trust your vision.

Create Market Pull Before You Ask for Buy-In

One of the smartest tactics from the call came from a CEO in the middle of his own pivot. Before his team had even built the new product, he created landing pages, solution pages, feature pages, and blog posts on his website describing the product he believed the market would want. It was an experiment to test whether he was skating to where the puck was going.

That week, a thoughtful, well-qualified lead came in through one of those pages. When he brought it back to his leadership team, the reaction changed overnight. People who had been skeptical saw real market pull, and it gave them energy to move toward the future. He had to go back to the prospect and explain that the product wasn't ready yet and invite them to become a pilot customer. That cost him one small lead. What he gained was internal alignment, which is worth far more.

• Pre-market the future product. Publish pages and content about what you plan to build before you build it.
• Treat inbound interest as validation data. Real leads coming in show that the demand exists outside your own head.
• Use that evidence internally. A single strong lead can do more to shift a skeptical team than any all-hands speech.
• Be honest with early prospects. Offer them a pilot spot and a chance to shape the product.

Making the Hardest CEO Call

One member described saying "this is it" as probably the hardest decision a CEO ever makes. I think he's right. You're choosing between a known business that works and an unknown one that could be much bigger, and there's risk on both sides. Go all in too early and you might starve a healthy business for a product that never finds its market. Stay at 50/50 too long and the new product becomes a so-so side project while a competitor builds the thing you saw coming.

The founders handling this well share a few habits. They acknowledge the tension openly with their teams. They protect the legacy product with a clear owner instead of pretending it will run itself. They look for evidence outside the building, whether that's inbound demand or paying pilot customers. And they set a clear threshold for when the company will move from experiment to all in. If you're in the middle of this transition right now, write that threshold down, share it with your leadership team, and let the market tell you when it's time.