Most product failures don’t happen because the engineering was bad; they happen because the team built the wrong thing. We fall in love with an idea, skip the “boring” parts, and rush straight into development. But as industry legends like Marty Cagan and Eric Ries have taught us, the most expensive way to learn is to build the full product.

To build products that customers actually love—and that sustain a business—you need a rigorous hierarchy of knowledge. You must answer critical questions before you ever touch a codebase. Here is the blueprint for what you need to know before you start building.

1. The North Star: Start with Vision

Before you build, you need to know the “Why.” The Vision is your long-term objective (2-5 years). It isn’t a list of requirements; it’s a description of the world you want to create. Without a clear vision, you aren’t building a product; you’re just shipping features in the dark.

2. The Route: Strategy and Sequence

Strategy is your sequence of focus. You cannot solve everything for everyone at once. You need to know: Who is our first high-expectation customer? Which market segment do we win first? If Vision is the destination, Strategy is the specific path you’ve chosen to get there.

3. The Hidden Traps: Uncovering Assumptions

Think of your Strategy as the path you’ve chosen to walk and your Assumptions as the hidden traps lying beneath the surface. Before you start building, you must expose what you don’t know.

Using the “Cagan Four,” we identify these traps early:

• Value Risk: Do they actually have this problem? Will they pay for this solution?
• Usability Risk: Can the target user actually navigate the workflow?
• Feasibility Risk: Do we have the technology and time to build this?
• Business Viability Risk: Does this fit our legal, financial, and sales constraints?

4. Probing the Ground: Turning Risks into Hypotheses

Once you identify a trap, you don’t build a feature to fix it; you create a Hypothesis to test it. A hypothesis is a way to “probe the ground” ahead of you.

“If we provide [Solution X], then [User Y] will achieve [Outcome Z]. We will know this is true when we see [Metric].”

5. The Discovery Loop: Validating Before Delivery

This is where the rubber meets the road. Instead of a static list of features, you use an Outcome-Based Roadmap to organize your journey. This roadmap isn’t a commitment to build specific things; it’s a commitment to solve the traps (problems) you identified in Step 3.

Within this loop, you follow a strict sequence:

1. Discovery (Validate): Use low-fidelity prototypes, “smoke tests,” or user interviews (Teresa Torres style) to validate the hypothesis. You want to learn in hours, not weeks.
2. Build (MVP): Once the idea is validated through discovery, build the smallest possible version of the actual feature (Eric Ries style).
3. Measure: Use quantitative logs and qualitative feedback to see if the “trap” was cleared and the outcome achieved.
4. Learn & Refine: Based on the data, do you Pivot (change the path) or Persevere (keep walking)?

The Bottom Line

What you do before you start building determines whether you are an “Order Taker” or a “Product Innovator.” Success isn’t about how much code you ship; it’s about how much certainty you have that the code matters.