The starting point
An early product conversation can quickly become a list of screens, integrations and features. Before deciding what to build, step back: whose problem are you solving, and what would a useful first version help them do? A focused brief gives design and engineering a shared starting point.
Write the problem before the feature list
Describe one audience, the task they need to complete and what makes that task difficult today. Use plain language. ‘Our operations team re-enters the same order into three systems’ is more specific than ‘We need a modern dashboard.’
Talk to the people doing the work. Ask them to walk through a recent example, including the workarounds they use. Separate what you have observed from what you still assume. Keep those open questions in the brief instead of quietly treating them as requirements.
Choose one complete, useful journey
A first release should have a clear beginning and end. For a booking product, that might be finding an available appointment, making a booking and receiving confirmation. A polished search screen alone does not complete that task.
Map the steps and the information each one needs. Include the unglamorous parts: permissions, empty states, cancellations and what happens when something fails. These details belong in the scope conversation, not just in the final round of testing.
Make the boundaries explicit
Divide ideas into what is necessary for the first journey and what can be considered later. Record why each decision was made. A ‘not yet’ list keeps useful ideas visible without making every idea a launch requirement.
Agree on the constraints with your team. Existing systems, content preparation, data migration, accessibility needs and the people who will maintain the product can all affect the plan. If an integration is uncertain, investigate it before relying on it in a delivery estimate.
Decide how you will learn from it
Choose a few signals connected to the original problem. For the operations example, you might observe whether someone can complete an order without duplicate entry, where they need help and which exceptions remain manual. Define how you will collect that feedback before launch.
Give someone responsibility for reviewing the findings and deciding the next change. A first release is a starting point for learning, not a commitment to build every item on the original wish list. Leave room in the plan to respond to what users actually need.
Put the thinking into practice
Ready for your next step?
