From Idea to Problem (part 1): How to Lay the Foundations for a Product Worth Building

Most teams start a product with lots of enthusiasm, a few sparks of ideas… and no guarantee that anything will actually take off.

Yet the best products—the ones users adopt and that create lasting advantage—almost never emerge from a brilliant isolated idea. They come from understanding a real problem experienced by real users. As Marty Cagan says in Inspired, great product teams don’t build more, they understand better.

In this two-part article, we’ve tried to outline a chronological path: from the first intuition to measurable impact, including the first line of code.

1. Ideas Have No Value — Problems Do

Why Most Products Fail

According to CB Insights, 35% of products fail because they don’t address a real need (“Top reasons startups fail”).

In these cases, the failure is not in execution but in the decision to build.

In most organizations, products fail because two very different things are confused:

• The imagined solution: what the team thinks they need to build (an app, a feature, AI, etc.) → This is a possible answer, but it is not the question.
• The underlying problem: what the user is actually trying to achieve in their life or work (get information quickly, avoid mistakes, save time, etc.) → This is the reason a solution may need to exist.

A product only has a reason to exist if its problem is:

• real,
• frequent,
• costly (in time, money, frustration),
• and currently unsolved.

Hypotheses vs. Knowledge

Marty Cagan insists: at the beginning of a product, everything is a hypothesis (an unverified statement), such as “users want to share their shopping lists.”

A piece of knowledge, by contrast, is a validated truth supported by data or observations (“80% of our users already share their shopping lists, but through screenshots”).

The role of discovery is to turn hypotheses into knowledge, as quickly as possible.

Uncovering the Real Jobs-to-be-Done

“The idea has no value—only the problem does.”

This raises another challenge: how do you properly define a user problem? The Jobs-to-be-Done (JTBD) framework is extremely helpful here, allowing you to rephrase the problem from the user’s point of view:

A job is what the user is really trying to accomplish, regardless of the current solution.

Example:

❌ “My clients want a chatbot.”

✔️ “My clients want an immediate answer without contacting human support.”

This shift in perspective is fundamental. A job is stable and long-lasting, while a solution is temporary.

source: https://www.leanlabs.com/blog/the-jobs-to-be-done-framework-b2b-site-strategy

2. Moving from a Vague Problem to a Clear Opportunity

Once the problem is identified, the goal is to deeply understand it.

Exploration Tools: Interviews, Shadowing, Data, Pain-Point Mapping

User Interviews

The goal is not to ask users what they want (they often don’t truly know), but to understand their context, motivations, and frustrations.

Useful questions:

• The last time you did X, what was difficult?
• What did you try before?
• What surprised you?

Shadowing

Shadowing involves observing users in their real environment.

It reveals tacit behaviors that are often not verbalized during interviews.

Data Analysis

Data can complement the findings:

• abandonment rates,
• time spent,
• frequency of use,
• …

Pain-Point Mapping

A pain point is a moment of friction in the user journey. Mapping them (journey map, service blueprint) helps visualize where value is concentrated.

source: https://www.woopra.com/blog/customer-journey-map

Finally… Reframing as a “Product Opportunity”

A product opportunity is a problem critical enough to justify intervention.

It is framed like this:

“Users [segment] experience [problem] in the context of [situation], which leads to [impact].

Today, they compensate by using [alternative solutions], which have [limitations].

There is an opportunity to [measurable improvement].”

3. Assessing Potential Value Before Prototyping

The Four Types of Risk

Before creating any prototype, you must evaluate the potential of the problem through four key dimensions (Marty Cagan’s framework).

(Note: a prototype ≠ an MVP. Prototypes include Figma mockups, fake buttons, etc.)

1. Desirability (value risk)

Do users actually want this problem solved? Is it urgent or important?

2. Usability (usability risk)

Can users easily use a potential solution? What structural friction might they face?

⚠️ Especially important when defining a solution inside an organization: will the involved teams actually be able to adopt it easily?

3. Feasibility (feasibility risk)

Can the team realistically build it? What are the technical, legal, or organizational obstacles?

4. Viability (viability risk)

Does solving this problem fit our business model?

Define a Testable Hypothesis, Not a Feature

Now that the problem seems promising across the four risk dimensions, the goal is not yet to build a solution.

It is to formulate testable hypotheses that will quickly reveal whether the potential is real.

Example:

❌ “Add a share button.”

✔️ “We believe that if users can share their lists more easily, they will do it twice as often and invite new members.”

Product discovery (next section) is exactly what will validate or invalidate these hypotheses.

4. The Core of Product Discovery

Product Discovery is the process of reducing risk before investing in development. Here are a few methods belonging to discovery:

Rapid Prototyping

Quickly create artifacts (mockups, prototypes, Wizard of Oz, fake buttons) to learn fast.

Example: Build a clickable Figma prototype simulating a simple conversational assistant (3 questions, 3 possible answers) in 2 hours. Five users test the prototype on a call and share their feedback.

Dual-Track Discovery

The Dual-Track model (Cagan) separates two parallel workstreams: Discovery & Delivery. The goal is that discovery never blocks delivery.

Continuous User Testing

Every hypothesis must be confronted with reality:

• concept tests,
• exploratory A/B tests,
• …

5. Deciding What Not to Do

One of the best indicators of a mature organization is its ability to say no.

Without strict prioritization, a product becomes a collection of ideas. Saying no protects coherence, vision, focus, and speed.

Prioritizing by Impact vs. Effort

A simple model (RICE model):

• Impact (value created)
• Effort (resources required)

An opportunity is only interesting if it maximizes value while keeping effort reasonable.

The Opportunity Solution Tree as a Decision Tool

The Opportunity Solution Tree (Teresa Torres) helps map the strategic objective, potential solutions, and experiments/tests.

It enables objective decisions:

• Where is the value?
• Which opportunities are most promising?
• Which solution should be tested first?

Below is an example tree for Spotify.

source: https://productschool.com/blog/product-fundamentals/opportunity-solution-tree

Conclusion: Building Should Come Last

As you’ve seen, we haven’t talked about MVPs or code yet.

A solution worth building is one that has first been understood.

Building is the outcome — not the start.

By following a rigorous path:

1. understand the problems,
2. identify real opportunities,
3. evaluate potential value,
4. test hypotheses through discovery,
5. actively decide what should not be done…

… you drastically reduce the risk of failure.

As Marty Cagan puts it:

“The best way to build a good product is to avoid building a bad one.”

The next part of the article here 😊