Fall in love with the problem, not the solution

A prototype can be ready before you manage to book your first customer conversation. That is useful. It also makes it easy to spend a week building something nobody asked for.

The dangerous part is that the screen works. The form submits, the dashboard shows numbers, and the demo looks convincing. Every finished detail gives you another reason to defend the product. You still need to find out whether it deserves to exist.

Uri Levine's Fall in love with the problem, not the solution names the discipline involved. My reading is practical. Before choosing what to build, find out what work someone is trying to finish and what gets in the way.

Ask to see the last time

"Would you use a system that organizes your orders?" is a comfortable question. Someone can say yes without changing anything in their life.

I would rather ask them to show me the last order that caused trouble. Which message arrived first? Where did they record the price? How did they notice missing information? How long did they wait before they could continue?

Imagine a distributor receiving orders through WhatsApp and copying them into a spreadsheet. The first idea might be a customer portal. Watching the work might reveal that copying takes very little time. Orders wait because one person has to approve every discount.

In this hypothetical example, a portal could organize incoming requests and leave the delay intact. The queue has moved to a different address.

Describe the problem without naming a technology

A useful description would be "the person handling an order waits for approval before confirming delivery." You can investigate who approves it, when that happens, and which orders could proceed without help.

"We need an AI agent" has already chosen an answer. It says nothing about why an order is stuck.

Before drawing the interface, record:

• Who does the work and in what situation.
• What they use today, including messages and paper.
• Where they wait or have to repeat a step.
• What observable change would justify switching processes.

Use recent examples. A conversation about yesterday's work usually tells you more than a prediction about what someone might do next year.

Test the change in the work

For the distributor, the first experiment could be a discount rule for routine orders. Over an agreed period, someone applies the rule manually and records exceptions. You do not need software to find out whether approval was the main delay.

Decide what to observe before starting. For example, reduce the time between receiving a complete order and confirming it, without increasing later corrections. That is a proposed measure for the experiment, not a promised result.

Write down what would disprove the idea, too. If orders still wait because stock is missing, the diagnosis was incomplete. Discovering that before development is a useful outcome.

A prototype belongs in the experiment when it answers a specific question. Can the team enter an order without assistance? Does the approver have enough context? If the experiment ends with "it looks nice," it needed a better question.

Separate interest from commitment

Praising a demo costs little. Setting aside time for a pilot, supplying suitable data, and changing a routine cost more. Those commitments tell you more about priority.

An accepted pilot still does not prove there is a market. Follow usage beyond the first week. Check whether people return when you stop reminding them. Ask what they would give up to keep using the product.

A problem can also be real but too small to support a business. Saving a few minutes may help without justifying a subscription, an implementation project, and another tool to manage.

Decide what would make you stop

Before the next development cycle, write down one condition for continuing and another for stopping. Share both with the people building the product.

That agreement matters even more once working code exists. Time already spent weighs on the discussion, but it does not make another week of work compulsory.

Before requesting another feature, return to the last real case. Find out what got stuck, who had to intervene, and whether the proposed change would have helped at that moment. Use that to decide what belongs in the product.