Start with a problem you can describe plainly
Enough evidence begins with clarity, not enthusiasm. Before deciding to build, write the problem in language a prospective user could recognise without needing your product vocabulary. Name who encounters it, the moment it appears, the current workaround, and the unwanted consequence of leaving it unresolved.
A useful problem statement is narrow enough to guide a first release. “Small teams need better operations” is a direction, not yet a buildable problem. “A small operations team loses track of recurring supplier approvals because requests live across email and chat” gives you something that can be examined, challenged and reduced to a focused task.
Clarity also means separating a problem from a preferred solution. If the evidence only shows that people find approvals hard to track, it does not yet prove they need a particular dashboard, workflow engine or automation. Keep the problem stable while remaining willing to change the mechanism.
- Can you state the user, triggering moment, current workaround and consequence in four sentences?
- Could someone reasonably disagree with your interpretation of the problem? If not, the statement may be too vague to test.
- Does the problem recur often enough, or carry enough consequence, to deserve a deliberate change?
Look for evidence of present behaviour
The question is not whether people like the idea in the abstract. It is whether the problem already shapes behaviour. Evidence becomes more useful when it shows what people do now: repeated manual steps, copied information, delayed decisions, avoided tasks or separate tools joined together by habit.
This evidence need not be exhaustive before a first release. It should be specific enough to show that the proposed user has a real job to complete and that existing approaches leave a meaningful gap. Notes from conversations, examples of current workflows, support requests, public discussions and direct observation can all be useful inputs when interpreted cautiously.
Treat stated interest as a starting signal rather than a conclusion. Someone may say they would use a product because the idea sounds sensible, while their present actions reveal little urgency. A stronger signal is a willingness to spend time explaining the workflow, try a constrained alternative, share a non-sensitive example, or return to the problem without prompting.
- Record exact workflow details rather than only positive reactions.
- Ask what happens if the problem is not solved this week.
- Identify the smallest behaviour a release would need to change or simplify.
Define the smallest useful promise
A first release should make one useful promise that can be understood, attempted and assessed. It does not need to represent the complete business or final product vision. In fact, a broad first release can hide whether any individual part is useful, because usage and outcomes become difficult to interpret.
Choose the smallest outcome that connects directly to the clarified problem. This often means supporting one audience, one repeated situation and one end-to-end task. The release may rely on manual operations behind the scenes, provided the boundary is clear and responsible. Automation should be added where it reduces meaningful work or error, not simply because automation sounds advanced.
Accessible interfaces are part of this promise. If the intended user cannot understand the next action, recover from a mistake or use the core flow with common access needs in mind, the release cannot fairly test the product idea. Accessibility is not decoration applied after validation; it affects whether the evidence reflects the product’s usefulness.
- Describe the first release as: “For [audience], help them [complete task] when [situation] happens.”
- Remove features that do not help complete that task.
- Define one clear completion state a user can recognise.
Example: deciding whether to release
Example — a founder is considering a lightweight tool for a small team that repeatedly prepares weekly handoff notes. The problem is not “team communication is difficult.” It is that the person coordinating handoffs collects updates from several places, rewrites them into a consistent format and still misses unresolved items.
The founder gathers several concrete workflow descriptions. They find that the same coordinator role repeats the process weekly, that existing notes are assembled manually, and that missed items create follow-up work. This is enough to frame a testable release, but not enough to justify a broad collaboration platform.
The first useful release could accept a short set of updates, organise them into a reviewable handoff draft and make unresolved items visible before sharing. Its outcome measure might be whether a handoff draft is completed and reviewed through the release, alongside a qualitative check on whether it reduced a specific manual step. It should not claim to prove long-term retention, market size or a universal need after a small initial test.
- Decision: proceed only if the problem, recurring workflow and narrow completion state are documented.
- Release boundary: one handoff format for one team type, not every communication workflow.
- Measure: completion of the core task and evidence about the manual work it replaces.
Use measures that answer a decision
Measurements are valuable when they help you decide what to do next. Before building, choose a small set of signals connected to the first useful promise. For example, you may want to know whether people can complete the core task, where they stop, whether the output is used, and whether the original problem appears less burdensome in the specific context you defined.
Avoid collecting activity data merely because it is available. A count of visits, clicks or sign-ups may be informative, but it is not automatically evidence of usefulness. Pair behavioural signals with the product outcome you care about. If the release helps someone prepare a handoff, assess the handoff flow rather than treating general attention as the same thing.
Set decision rules in advance, but keep them proportionate. You may decide that repeated failure to complete the core task means simplifying the interface, while consistent use of a workaround outside the product means reconsidering the problem or scope. The purpose is not to manufacture certainty; it is to make learning visible and actionable.
- What outcome would show the release is useful in its narrow context?
- What observation would cause you to simplify, change scope or stop?
- Which signals are direct evidence, and which are only background context?
What “enough” evidence actually means
Evidence is enough to move to a first useful release when it supports a modest decision: build a small, bounded way to help a defined audience complete a real task, then measure what happens. It is not enough when it consists only of a broad trend, an appealing feature list or untested confidence that a large market must exist.
A practical threshold is a coherent chain: a clearly described problem; indications that it affects present behaviour; a narrow useful promise; an interface people can reasonably use; and measures that can reveal whether the promise holds. Weakness in one link does not always require abandoning the idea, but it should shape the next test rather than be ignored.
IVRYN is an independent product studio based in Paris. Its public portfolio includes Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB and Victor Laybats; each product has its own domain, audience and product page. That context bounds this guidance: it describes a disciplined way to reason about focused software products, not a claim that every product follows one universal path or that this approach guarantees a result. The relevant public principles are clear scope, measurable usefulness and responsible automation.
- Proceed when you can explain the chain from problem to measurable first outcome.
- Keep the release small enough that a result changes your next decision.
- Do not confuse a first release decision with proof that the full product should be built.
Frequently asked questions
How many interviews are enough before building a first release?
There is no universal interview count. Build when you have sufficiently specific evidence of a recurring problem, a narrow task to improve and a way to measure whether the first release helps; more conversations are useful when those elements remain unclear.
What is the difference between a prototype and a first useful release?
A prototype mainly tests an idea, interaction or explanation. A first useful release lets a defined audience complete a real, bounded task and provides evidence about whether that outcome is useful.
Should a first release include automation?
Include automation only when it clearly supports the defined task and can be used responsibly. Manual or simpler steps are often appropriate when they keep the first release understandable, accessible and easier to evaluate.
Sources and further reading
These resources provide the wider reference frame. Product statements on this page are limited to the public information provided by IVRYN.