Practical guide
Turning an idea into a first release
Choose one task, test the assumptions behind it and define a first release you can support.
Choose whose problem you are solving
A product idea gets easier to discuss when someone can describe the moment they would use it. Who is that person? What are they trying to finish? What do they do today, and why would they change? Answer those questions before agreeing a feature list.
Choose one initial user and one task. Other customers and use cases can wait until you understand this one. If you cannot find someone who recognises the problem, a more detailed specification will not give you the missing evidence.
Draw the complete journey
Walk from the trigger to a result the person can use. Include how information arrives, who checks it and what happens after the last screen. A request form is only useful if someone receives the request and can act on it.
For a hypothetical maintenance booking service, the first journey could let a customer request a visit, let an operator confirm a time and tell the customer what happens next. Automatic scheduling can wait if the operator can handle the initial volume. A request disappearing into an inbox cannot.
Test the expensive assumption early
What could make the whole idea fail even if the software works? Perhaps customers will not provide the necessary information. Perhaps the service depends on a supplier who cannot respond in time. Write those assumptions separately from the build tasks.
In the booking example, I would test whether customers accept a later confirmation before investing in scheduling automation. A conversation, a rough prototype or a manually handled request might answer that question. Choose the smallest test that can answer it.
Write a brief someone can challenge
On one page, describe the user, the task, the current workaround and the proposed first journey. Add what you will leave out, which assumptions remain open and what you need to learn from the release. Give each step an owner, including any manual work behind the scenes.
Show it to someone who would use the product and someone who would support it. Ask them to walk through a normal case and a failed one. Where do they get stuck? Agree how the team will track completed tasks, spot failures and collect feedback. Use what you learn to decide what must be ready for the first release.
Small still has to work
This approach works best when you can introduce a product gradually and learn from its use. A release needs more preparation when a failure could cause serious harm or it depends on a large migration. Required safeguards and recovery belong in the first release. Reduce the audience or the range of tasks until the team can support it responsibly.
Written for this site, 4 October 2026.