The Decision to Build a Second Product

What you actually need to know

• The first product must be self-sustaining before the second one starts. Founder attention cannot be split across two products that both need it.
• The second product needs separate headcount. Engineers cannot maintain two products without one of them degrading.
• The fastest path to revenue for a second product is selling to the first product's customer base. But it cannot be the only path.
• Separate codebases, separate deployments, separate roadmaps. Coupling the two products creates maintenance debt in both.
• If the second product is meant to replace the first, treat it as a migration project, not a new product.

The core argument

The pattern I have seen repeatedly is a founder who reaches a plateau in the first product's growth and decides the answer is a second product. The first product has a hundred customers. Growth is slow. The founder has been working on the same problem for two years. A new idea feels like a fresh start, a way to apply everything learned from the first product to something that has not yet hit the ceiling.

What actually happens: the first product slows down because the founder's attention is divided. The second product does not get the focused effort it needs to find product-market fit. Neither product reaches its potential. The team is confused about priorities. Customers from the first product feel the service degrading.

The founders who build successful second products are not escaping the first one. They have made the first product boring in the best sense. It runs predictably. The team knows what to build next without asking the founder every day. The support tickets are handled by a process, not by escalation. There is margin in the business to fund the second product. From that stable base, the second product gets a dedicated team and a dedicated focus.

The decision is not "should I build something new?" The decision is "does the first product's stability give me permission to build something new?" If the answer is genuinely yes, the second product is a strategic expansion. If the answer is "it will be fine," that is rationalization.

How to know the first product is ready

Three signals indicate the first product can support a second one:

90-day founder absence test. Could the first product operate for 90 days without a decision from you? Not without any input, but without anything that requires your specific authority. If the team could handle product, sales, and support for 90 days on their own, the first product is stable.

Automated growth. New customers are signing up without the founder sourcing them. The acquisition mechanism works without founder-led sales or founder-written content. The first product is growing on its own.

Net Revenue Retention above 100 percent. The existing customer base is growing faster than it churns. The product works well enough that customers stay and buy more. This removes the pressure of having to constantly replace churned revenue.

If all three are true, the first product gives you permission. If any one of them is missing, fix it before starting the second product.

Setting up the second product for success

The second product needs its own team. At minimum: one person who owns the product and business, and one engineer who builds it. This team is not borrowed from the first product. It is dedicated.

The second product's roadmap is separate from the first product's roadmap. There is no shared backlog. Decisions for the second product are made by the second product team based on their customers' needs, not by the first product team based on what is convenient.

The second product has its own revenue goal and its own timeline to profitability. It is not subsidized by the first product indefinitely. Set a specific milestone (for example, $10,000 MRR in 12 months) and a specific resource commitment. If the milestone is not reached, the second product is a failure and should be shut down or sold. If it is reached, it gets more resources.

Common mistakes founders make when building a second product

1. Building the second product as a feature of the first product's codebase. This creates technical debt in the first product and limits the second product's architecture.
2. Using the same brand without deliberate intent. The second product either strengthens the first brand or dilutes it. Decide which before naming it.
3. Not defining success criteria before launch. Without a specific revenue goal and timeline, the second product survives indefinitely on the first product's goodwill.
4. Treating the first product's customers as a guaranteed market. Some will buy the second product. Most will not. Build the acquisition channel independently.
5. Starting the second product during a rough patch in the first. A second product built from a place of escape rather than stability is almost always a mistake.

Where to start: a 3-step second product decision

Step 1: Run the 90-day absence test. Write down every decision you made this week about the first product. Which of them could your team have made without you? If the answer is fewer than half, the first product is not ready to support a second one.

Step 2: Define the second product's minimum viable resource requirement. What is the smallest team that could build and sell this product in 12 months? What does that cost? Can the first product fund it without putting the first product at risk? If not, wait.

Step 3: Set a 12-month revenue milestone and a clear shut-down condition. Write down the number the second product needs to reach in 12 months to justify continued investment. Write down the number at which you will shut it down. Both numbers need to be specific before you start.

How I Think About This as a Builder

Yashveer Singh. Founder of Yashveer Labs. I have thought carefully about when to expand and when to stay focused. The projects I have built are focused, not scattered. The decision to build something new is a decision I take seriously, because the cost of doing it wrong is both products operating at less than their potential. If you are at this decision point and want a perspective from someone who thinks carefully about product scope, the contact page is there.

Related reading

• The Decision to Add Enterprise Sales
• The Decision to Build a Customer Success Team
• The Decision to Add a Free Plan
• The Decision to Build Your Own Platform vs Use Someone Else's