Most founders think "what to build" means the product. It almost never does. Before the first line of code, there is a sequence of decisions that determines whether the product you build ends up in the hands of paying customers — or sitting finished and unused while you wonder what went wrong.

Why sequencing is the most underestimated decision in early-stage product development — and how getting it right changes everything that follows

There is a specific kind of founder who comes to us with a clear vision and no idea where to start. They can describe the problem they are solving. They can articulate why the market needs it. They have been working on it — slides, conversations, introductions, research — for months, sometimes longer. And yet the actual business has not moved in a meaningful direction, because nobody has helped them answer the one question that determines whether all of that work produces something real.

What do you build first?

Not the product. The product is almost never the right answer to that question, and it is almost always the answer founders give.

What "Build" Actually Means

When a founder says "I know what I want to build," the first thing we do is slow down and define the word.

Most founders, when they say build, mean the product. The software. The app. The platform. They have a technical vision, or they have found a developer, or they have started designing screens — and the building, in their mind, means the thing that will eventually exist in the hands of a user.

What they have not yet thought through is everything else that has to exist for a user to find it, pay for it, keep using it, and tell someone else about it. The legal entity. The business name and the intellectual property that goes with it. The insurance. The brand. The go-to-market model. The financial structure. The customer support function. The pricing strategy. The partnership considerations that will determine whether the product lives as a standalone tool or becomes part of a larger ecosystem.

All of these things are part of building a business. And almost none of them show up on a founder's list of things to do before they start writing code.

The DMV region is fortunate to have one of the richest startup ecosystems in the country — incubators, accelerators, university innovation programs, federal funding pathways, experienced advisors at every stage. That ecosystem is genuinely valuable. It is also, for founders trying to figure out where to start, a source of tremendous noise. Pitch competitions to prepare for. Advisor meetings to attend. Cohorts to apply to. Each one feels urgent. Each one pulls attention away from the foundational work that no pitch competition and no advisor meeting can replace.

We often meet founders who have been pouring hours into a slide deck for a pitch competition they may or may not win — without having clearly articulated, even to themselves, what the ultimate outcome of building this business is supposed to be. To generate passive income? To build and sell? To create a sustainable business they run for twenty years? The answer to that question changes everything about what gets built, how it gets built, and in what sequence.

The visioning exercise comes before the pitch deck. Always.

The First Question That Changes Everything

When a founder is genuinely unsure where to begin, our answer is almost always the same: start with customer discovery, and do not stop until you can defend the idea under pressure.

Not the passive validation that most founders have already done — the advisor who said it sounded promising, the investor who expressed interest, the industry contact who confirmed the problem was real. These interactions are not customer discovery. They are encouragement. They are useful, but they are not a substitute for the specific, structured work of understanding who has the problem, how much it costs them to live with it, what they are currently doing about it, and what it would take to get them to change.

We ask every founder two questions to start. What problem does this product solve? And who specifically are you solving it for?

If the answer to the second question is "everyone" or "any company that has this problem" or "anyone in this industry," we stop. Not because the idea is wrong — but because a product that is for everyone is optimized for no one, and a go-to-market strategy built on a target market that broad will produce a CAC so high the business cannot survive it.

Founders who have not done the specific customer discovery work tend to show up to these conversations with surface-level answers that collapse under a single follow-up question. Founders who have done it can defend the idea with data — not surveys, not secondhand accounts, but the patterns that emerged from twenty or thirty real conversations with the actual people who will use and pay for the product. That defensibility is what gives a founder the confidence to make real decisions rather than waiting for more validation that never quite arrives.

Analysis paralysis is real, and it almost always traces back to insufficient customer discovery. The path forward feels unclear because the evidence is not yet clear enough to make it obvious. More conversations, not more deliberation, is the cure.

The Product That Became an Ecosystem

There is an engagement we return to often when this conversation comes up, because it illustrates better than any framework what the right sequencing actually produces.

A founder came to us with a specific problem in a specific industry. The problem was real, the audience was large and identifiable, and the cost of living with the problem — in time, in labor, in operational complexity — was significant and measurable. The solution the founder envisioned was technically feasible and commercially interesting.

Before a line of code was written, we did the customer discovery.

We spoke with professionals at every level of the process the product was intended to improve — the business leaders who would approve the purchase, the managers who would oversee implementation, the front-line users who would interact with the product daily. We mapped the full workflow the product would touch, including the adjacent tools and platforms already in use. We asked not just whether people wanted a solution but what they were currently using, where those solutions fell short, and what integration with their existing systems would mean for their willingness to adopt something new.

What we found changed the product strategy entirely — not the core idea, but the architecture around it.

We learned that the product, as originally conceived, would address roughly 15% of the user's workflow. That was enough for initial adoption. It was not enough for long-term retention. We learned that the tools already in use represented both potential competitors and potential integration partners — and that building on open APIs from day one, with a developer portal designed for external integration, would transform the product from a standalone tool into a node in a larger ecosystem.

When we launched, users came. They found value. And almost immediately, they started asking whether the product could connect to the other platforms in their workflow. Those conversations led to introductions. Those introductions led to integration partnerships. Those partnerships opened new markets that had not been in the original plan.

The exit pathway that had seemed speculative at the start — acquisition by one of the larger platforms the product had integrated with — became, within a few years, a real and serious conversation. Not because the product was acquired by chance. Because it had been built, from the beginning, as something an acquirer would want.

None of that was accidental. All of it was a product of understanding the ecosystem before deciding what to build.

The Broader Ecosystem Is Not Optional

The lesson from that engagement is the one we come back to most often with founders who are focused on solving a single problem for a single user type.

You are almost never solving the only problem your users have.

The product you are building exists inside a workflow. That workflow involves other tools, other systems, other vendors, other platforms — each of which has users, a distribution channel, a customer base, and in some cases a partnership program that would pay you to integrate with them. Understanding where your product's solution space overlaps with and complements the solution spaces of the products your users already depend on is not a nice-to-have. It is a core element of product strategy for any B2B SaaS company that intends to grow beyond its initial customer base.

The consolidation happening in software right now — product after product being acquired, categories collapsing into platforms, point solutions becoming features of larger systems — is not a threat to a well-positioned early-stage product. It is, for a product that was built with integration in mind and an open architecture from day one, the exit strategy. Waze being acquired by Google Maps is a useful shorthand for what this looks like when it works: a focused product that solved a specific problem exceptionally well, built in a way that made it a natural addition to a larger platform's offering rather than a competitive threat.

Building toward that kind of outcome is not something you retrofit into a product that was designed in isolation. It has to be in the architecture from the beginning. Which means it has to be in the customer discovery and the market research and the ecosystem mapping that happens before the architecture is designed.

What Wrong Sequencing Actually Looks Like

The founder who gets the sequence wrong is not hard to identify. We see the same patterns repeatedly.

They are writing code for a single customer's specific requirements, without other customers waiting who look like that customer. They have built features that no user has asked for and are not sure why adoption is low. They have been in development for a year and the product still does not feel ready to launch — because "ready" keeps moving as new features get added in the absence of real user feedback to prioritize against.

They are spending ten to twenty hours a week in advisor meetings and pitch sessions, seeking the external validation that would tell them it is finally time to move — instead of spending those same hours building the customer base that would make the validation obvious.

High customer acquisition cost. Low retention. A product roadmap driven by internal opinion rather than user behavior. A business that has been building but has not been learning.

The roadmap is not the solution to this in isolation. But the roadmap, built after genuine customer discovery and ecosystem analysis, is what makes the sequence visible. It is what shows the founder that the integration partnership conversation belongs in year one, not year three. That the developer portal is infrastructure, not a nice feature. That the first customer is not a revenue milestone — it is a learning opportunity that should be treated as more valuable than the check they write.

Why We Build It This Way

The Plan phase is where the sequence gets determined. Not by instinct, not by what the founder feels most prepared to do first, and not by what a pitch competition requires on the next slide.

By the evidence. By what the customers said. By what the ecosystem reveals about where the product fits, who it competes with, who it complements, and what the realistic path from first user to viable exit looks like.

Founders who go through this work do not just build better products. They build businesses that know where they are going before they spend the money to get there. They build with confidence, because the confidence is earned — not from an advisor telling them the idea is good, but from the market telling them, directly, that the problem is real and the solution is something people will pay for.

The question is never whether to build. It is whether you know enough to build the right thing, in the right order, for the right people.

That knowledge does not come from the product. It comes from the work that happens before it.

This is part of a series for early-stage SaaS founders navigating the Plan, Grow, Scale, Repeat journey. Read the full series here.