From a useful question
to a useful product.
A considered process keeps purpose, scope and decisions visible. The work moves forward in stages that can be understood and reviewed.
Define the problem
Describe the person, the task and the current obstacle. Identify what success would look like and which constraints matter: devices, budget, integrations, privacy or timing. The outcome is a focused brief with a clear boundary.
Map the experience
Work through the essential journey before adding secondary features. Include loading, empty and error states; permissions; recovery; and smaller screens. The outcome is a design direction that can be discussed before implementation becomes expensive to change.
Build in understandable stages
Implement a coherent part of the product, review it and use what is learned to guide the next stage. Keep responsibilities and external dependencies visible. Changes to scope should have an explicit decision, rather than quietly increasing cost or complexity.
Verify the agreed behaviour
Check what was built against the acceptance criteria. The right checks depend on the product: browser behaviour, a device journey, permissions, integration responses, data recovery or an observed performance problem. A successful build does not replace checking how the product behaves.
Prepare the handover
Document how the delivered work is configured, maintained and recovered. Confirm who owns the accounts, content and infrastructure. Release the agreed and authorized scope; plan later improvements from evidence and feedback.
Make the change
a clear decision.
Record the new requirement, consider its impact and agree the next step. A smaller, coherent release can be more useful than a larger scope whose essential journey is unfinished.
Read the product planning guide ↗