Describe the problem before the solution
Describe an observed situation: who loses time, which information is missing, which action fails? Explain how people manage today and why you want that to change.
Avoid goals that are hard to verify, such as ‘an intuitive and innovative application’. Prefer an observable result, such as allowing a team to track a request without exchanging several files.
Tell the story of a user journey
Choose a representative case and describe it from beginning to end. State what the user already knows, what they enter and what they receive. Include common mistakes and exceptions.
When several roles are involved, explain who can read, edit and approve. Access rules often influence the work more than a screen’s appearance.
List dependencies
A project can be held up by access, an approval or a data source. Making dependencies visible early helps organise the work.
- Existing tools, available documentation and points of contact.
- Data to import and the person who understands it.
- Content, visual identity and translations to supply.
- Decision-makers and people available for acceptance testing.
- Date constraints and the concrete reason behind each deadline.
Separate essentials from wishes
For every feature, ask whether the first release can achieve its objective without it. Keep a wishlist, but separate it clearly from the launch scope.
Sharing a budget constraint can also help. It makes room to discuss trade-offs in scope, polish and sequencing. It does not replace a definition of deliverables.
A brief template to copy
Complete these sentences with concrete examples. A few lines per point are enough for an initial conversation.
- We help [users] achieve [desired outcome].
- Today they use [current solution] and face [problem].
- The first journey must allow them to [end-to-end action].
- The product must connect to [tools or data].
- The first release is needed by [date and reason].
- We will validate the result by checking [observable criteria].
- Decisions will be made by [role] and tested by [users].
What the first conversation should produce
The aim is not to resolve every technical detail immediately. Identify open questions, risks and the next step that will make the scope clearer.
You should leave with a shared understanding of the problem and what needs further investigation. Do not send passwords or sensitive data in your first message: describing the systems involved is enough.