Do not begin with screens. Begin with the person experiencing the problem, the decision they need to make and the result the business can observe.
Key takeaways
- Define the costly behaviour before discussing features.
- Make the first release complete enough for customers and staff to use.
- Use architecture to support what the team needs to learn next—not to predict every future need.
Start with the customer or staff problem
A product idea becomes buildable when it describes what happens today, why that is costly or limiting and what should improve. Interview the people closest to the work and include difficult cases—not only the ideal path.
Define the smallest complete workflow
An MVP is not an arbitrary collection of easy features. It is the smallest end-to-end experience that delivers a useful result. Include the staff tools, permissions and error handling required to run it.
Make architecture follow the learning plan
Choose technology after understanding users, data, integrations and risk. Early architecture should make change affordable without adding complexity the product does not yet need.
Prepare for implementation
Write acceptance criteria, name the people making product decisions, list dependencies and decide how the team will review each working release. A useful plan answers enough questions to begin without pretending nothing will change.
Is the idea ready to become a product plan?
A promising idea is ready for planning when the team can describe the user, the current alternative and one observable result. These tests expose whether discovery should continue before implementation begins.
| Decision area | Useful evidence | Warning sign |
|---|---|---|
| Problem examples | Recent cases from the people experiencing the problem | A feature list with no current workflow behind it |
| First release | One end-to-end outcome including administration and exceptions | Several disconnected screens labelled as an MVP |
| Product decisions | A named person can settle product tradeoffs | Every question waits for group consensus |
| Launch learning | The team knows what behaviour or result it will observe | Success is defined only as releasing on time |
Example: turn “a customer app” into a testable workflow
Instead of starting with accounts, dashboards and notifications, follow one customer from request to confirmed result. Identify what information is required, who handles an exception, what staff must administer and what confirmation proves the request is complete. That single path gives design and engineering a clear first scope.
Apply this to your software project
Bring one example of the workflow, the people involved, the bottleneck you see most often and what should improve. You do not need a finished specification.
For help with this decision, see Turn a product idea or troubled build into a clear plan.