Most digital projects that struggle did not fail at the build. They started without a shared answer to a few basic questions. Discovery is the short, structured period where those questions get answered, and it is usually the cheapest time to change your mind.
This article is general guidance. It is not a description of any particular client engagement.
What discovery is for
Discovery exists to reduce uncertainty before you commit money and time. A good discovery leaves you with:
- a clear statement of the problem and who has it
- a shared view of what the first version needs to do, and what it does not
- a list of the assumptions most likely to be wrong
- a realistic idea of effort, risk and next steps
It does not need to be long or heavy. For a small idea it may be a few conversations and a one-page summary.
Six questions to start with
- Who is this for? Be specific. "Small businesses" is a category. "Owner-managed shops that currently track orders on WhatsApp" is a starting point.
- What problem do they have today? Describe what they do now and why it is painful or costly.
- Why would they change? Switching has a cost. What would make the new way clearly better?
- What does success look like? Pick one or two measurable outcomes, such as sign-ups, completed orders or hours saved.
- What must the first version do? List the smallest set of things that lets you test the idea.
- What could stop this working? Think about people, data, regulation, money and technology.
Listen before you design
The most useful discovery input is usually conversations with the people who will use the product. Aim for real examples rather than opinions about your idea. Ask what they did the last time they faced the problem, what they tried and what it cost them.
If you cannot easily reach any potential users, that is itself useful information.
Separate assumptions from facts
Write down what you believe, then mark each item as known or assumed. Assumed items that would sink the project if wrong are your priority. Plan the cheapest way to test each one, whether that is a conversation, a simple landing page or a manual version of the service.
Choose a focused first version
Discovery should end with a decision about a first version, not a long wish list. A useful rule: if a feature does not help test your main assumption, it can wait.
Don't forget the non-software parts
A digital product usually depends on things outside the code: who answers customer questions, how people are paid, how content is produced, how personal information is handled. Under South African law, that includes processing personal information in line with POPIA. Raise these early.
When to bring in help
You can run discovery yourself using the questions above. Outside input helps when you are too close to the idea, when several stakeholders disagree, or when you need to turn what you have learned into a realistic build plan.
If you would like to talk through an idea, you are welcome to discuss a project. You do not need a finished brief or a budget.