Build a new software product
You have a problem worth solving, but the product is not yet a settled specification. Begin with the person who will use it, the job they need to complete and the evidence that would justify the next investment.
A practical path forward
- 01
Identify the user, their current workaround and the consequence of leaving it unchanged.
- 02
Prototype the uncertain interaction and test the hardest data or integration dependency.
- 03
Release a complete workflow with essential account, support and recovery paths.
- 04
Review adoption and operational friction before extending the roadmap.
The current situation
Where the friction lives.
An idea lives across documents, mockups and conversations. Stakeholders assume different users and priorities, so each new feature request expands the apparent scope without clarifying the product.
The intended change
A clearer operating state.
One audience can complete one valuable workflow. The team can observe whether it helps, operate it reliably and decide what to change using evidence from real use.
A useful first release
A first release should include the core task, the minimum administration needed to operate it and a way to collect feedback. Secondary audiences, elaborate reporting and speculative platform features can wait.
How to judge the result
Ask a representative user to complete the task from start to finish, including an interrupted or incorrect input. Agree in advance what evidence counts as completion.
Decisions to make early
- What behavior would demonstrate that the product deserves another release?
- Which tasks can remain manual without invalidating the customer experience?
- Who owns support, product decisions and access to the source repository?
A common failure mode
A visually convincing demonstration can hide missing operational work. Review account recovery, data ownership and exception handling before treating the demonstration as a release.