An idea is not a product yet

Many projects begin with a sentence like:

“What if we developed an application that…”

The problem is that, at that moment, we are already talking about the solution.

We don’t yet know:

• who actually encounters the problem;
• in what situation it appears;
• how it is solved today;
• why current solutions are insufficient;
• what could push the user to change.

An idea is a hypothesis of a solution. It gradually becomes a product when it addresses a problem important enough for an identifiable group of users, delivers an understandable value, and triggers a behavior we can observe.

Before writing the first line of code, I therefore try to answer five questions.

1. Who precisely encounters this problem?

Not “companies,” “students,” or “restaurants.”

These categories are too broad to guide a product decision. They lump together people with opposite needs, different constraints, and incompatible priorities. A Michelin-starred restaurant and a neighborhood pizzeria do not have the same product needs — describing them together means describing neither.

We need to identify a group specific enough to understand its context, its constraints, and its priorities. For example: independent restaurant owners who single-handedly enter their daily till, each evening between 8 pm and 10 pm, on an entry-level Android phone. That description immediately suggests product decisions: mobile ergonomics, short session, tolerance to entry errors, offline mode. The description “restaurants” suggests none.

2. What problem are we trying to solve?

The feature is not the problem.

“We need notifications” is a solution.

The problem might be that users start an important action, interrupt it, and never come back to finish it. If that’s the real problem, several solutions become possible: notification, yes, but also in-app reminder, email, simplified flow, automatic state save, one-tap resume. The first idea is no longer automatically the best.

This way of reformulating a request is not semantic nitpicking. It changes the question the team is asking. A team that receives “add notifications” builds notifications, even if it’s not the best lever. A team that receives “bring back users who interrupt an action” looks for the best lever — often, the one that costs the least to build and returns the most.

3. How is this problem solved today?

A product is never only in competition with other applications. It is also in competition with Excel, WhatsApp, paper, a colleague, a habit, or the decision to do nothing.

A restaurant owner who writes their daily sales in a notebook is not doing nothing: they have a solution, it is imperfect but it works, it is free, and it requires no learning. A product that claims to replace it will have to be better than that notebook — not better in absolute terms, better for them, in their situation, with their constraints.

This comparison often changes the design of the product. We discover that the real competition is not the application we wanted to draw inspiration from — it is a spreadsheet, a notebook, or simply the owner’s memory. From there, the product’s promise is no longer “a better application” but “a solution that replaces what you already do, with less effort and fewer errors.”

4. What change do we expect in the user?

Should they complete an action faster? Come back more regularly? Make fewer errors? Make a better decision? Buy, learn, or collaborate more easily?

If the expected behavior is not defined, it will be difficult to know whether the solution works. The product can be shipped, used, appreciated, and yet change nothing about the problem it was supposed to solve. Without an explicit definition of the expected behavior, no feedback can be interpreted correctly: “users say they like the product” is not the same as “users complete their entry in five minutes instead of thirty.”

The expected behavior must be formulated with a verb and a precise context. “Uses the application regularly” is too general to be verifiable. “Opens the application every evening between 8 pm and 10 pm and completes the entry in under five minutes, five days out of seven” is verifiable — and failure becomes an actionable diagnosis, not a vague frustration.

5. How will we measure this value?

The number of downloads or sign-ups is not always enough.

We need to identify the action that shows the user has actually obtained the promised result. This action is the one that, if we see it happen, proves the product does what it was supposed to do. It is not necessarily the most frequent nor the most visible — it is the one that materializes the promise.

For a learning product, that action might be finish a chapter and get a quiz result. For an invoicing product, it might be issue an invoice and receive the payment within the expected deadline. For a team collaboration product, it might be trigger a documented decision from a conversation started in the tool. None of these actions is identical to a sign-up. All materialize the promised value.

Three theoretical frames that structure this reasoning

This way of thinking joins the Jobs to Be Done theory (Clayton Christensen — Know Your Customers' Jobs to Be Done (HBR)): users choose a solution because they are trying to make progress in a particular situation, not simply because it has more features. This perspective changes what we consider a competitor, what we consider a product improvement, and what we consider a success.

The Value Proposition Canvas (Strategyzer — Value Proposition Canvas) also proposes to study users’ goals, their difficulties, and the benefits they seek before defining the solution precisely. It is a useful framing tool when several people need to align their understanding of the product to be designed, before disagreement translates into sterile technical discussions.

The Lean Startup approach (Eric Ries — The Lean Startup Principles) considers that the true progress of a startup rests on validated learning: build to test a hypothesis, measure real behavior, and learn before investing more. This discipline changes the nature of each delivery: each iteration is an experiment, not just a milestone in a roadmap.

That is also why we must talk to users before and after launch, focusing on their real experiences rather than only trying to sell them the idea (Y Combinator — How to Talk to Users). User interviews produce actionable insights only when they focus on past and recent behaviors, not on future intentions or hypothetical judgments.

The role of a Product Engineer

The role of a Product Engineer is therefore not simply to turn a founder’s idea into code.

It is to connect:

• the user problem,
• the founder’s vision,
• the product decision,
• the technical execution,
• and the measurable results.

Before asking: “How are we going to build this product?”

We must first ask: “What problem do we want to solve, for whom, and how will we know we have succeeded?”

This is the question that distinguishes a founder who builds a product from a founder who builds a technical demonstration. It costs nothing. It changes everything.

---

Main sources

• Clayton Christensen — Know Your Customers’ Jobs to Be Done, Harvard Business Review, September 2016
• Strategyzer — Value Proposition Canvas, product framing tool
• Eric Ries — The Lean Startup — Principles, validated learning methodology
• Y Combinator — How to Talk to Users, user interview guide
• Day 1 — The five questions before developing a mobile feature — 45-minute grid that applies these principles to a specific feature
• Day 3 — 3 tests before hiring your first mobile dev — concrete methods to validate before investing

Did this article resonate?

Insightful — Useful — Disagree —

Was this article useful?

Click a star to leave a note