Product strategy
A vague build gets expensive before the first useful screen exists.
The short answer
A proper software discovery process should end with decisions another team can build from: the user flows, first-release boundary, technical constraints, acceptance criteria and change process. It should also record what is deliberately excluded. If discovery only produces a presentation, the hard decisions have been postponed rather than made.
The dangerous part of a new product isn't the missing feature list. It's the false confidence that everyone means the same thing by it. Discovery makes those differences visible while changing the plan still costs a conversation, then turns the agreed version into something concrete enough to estimate, design and test.
Start with the decision the product has to make easier.
A request usually arrives as a feature: a dashboard, an app, an approval flow, a place for customers to log in. That describes a screen, not the job. The first discovery question is what somebody should be able to decide or complete when that screen exists, and what happens today when they can't.
That changes the conversation. A dashboard may turn out to be a weekly exception list. An app may only need to cover the work that happens away from a desk. An approval flow may be one permission rule attached to a system you already own. The smaller answer isn't a compromise when it removes the actual obstruction.
We ask who is accountable for the result, who does the work, who is affected when it fails and what evidence would make the first release worth continuing. Those answers become the boundary for everything that follows.
The best discovery process moves from evidence to a written boundary.
Workshops are useful when they expose disagreement. They are wasteful when the same people spend a week describing the same opinions in different rooms. A focused process collects the evidence first, brings the right people together for decisions, then writes down the consequences.
1. Name the business constraint
Write the problem in operational terms. Which handoff breaks, which decision takes too long, which customer action stalls, or which risk nobody can see early enough? Attach an owner and a measure. A feature without that sentence has no way to prove it helped.
2. Observe the current work
Follow the task from start to finish with the people who do it. Collect the forms, spreadsheets, messages and workarounds they already use. The awkward exception on a Friday afternoon is often more important than the clean happy path described in a kickoff call.
3. Map the users and rules
List who can start, view, change, approve and reverse each action. Add the systems that supply or receive data. This is where hidden roles, integrations, audit needs and notification rules stop being surprises inside development.
4. Choose the smallest proof
Select the first release that tests the uncertain part of the idea. Keep the work required to make that slice trustworthy, and move everything else into an explicit later list. Small means focused, not flimsy.
5. Write the buildable version
Turn the agreed flows into wireframes, a scope with inclusions and exclusions, acceptance criteria, dependencies and a change process. Someone who wasn't in the room should be able to read it and understand what they are being asked to build.
Discovery deliverables are useful only when they settle a question.
A thick document isn't automatically a complete one. The useful test is whether each artifact removes a specific ambiguity that would otherwise return during the build. The set should be proportionate to the product. A five-page public site doesn't need the same pack as a portal with three user roles and two back-office integrations.
The documents also have to agree with each other. A wireframe that shows an approval button, a scope that never names approvals and acceptance criteria that only say the page loads are three different products. Discovery is finished when those contradictions have been resolved, not when every template has been filled.
| Artifact | Question it settles | What good looks like |
|---|---|---|
| Current-state map | Where does the work actually break today? | Real handoffs, exceptions and owners, not an idealised process |
| User flows | Who does what, and in which order? | Roles, branches, failures and the path back from an error |
| Wireframes | What information and action must each screen support? | Enough detail to test the task without polishing the interface |
| Scope | What is included in the first release? | Specific inclusions, explicit exclusions and named dependencies |
| Acceptance criteria | How will everyone know a deliverable works? | Observable behaviour, including permissions and failure states |
| Change process | What happens when the plan changes? | A written way to assess cost, timing and approval before work starts |
The difference is what gets cut, not how many workshops get booked.
We don't treat discovery as a waiting room before development. It is allowed to change the product, recommend an existing tool or conclude that the first version should be much smaller. If the answer is already clear, we'll stop rather than invent more activities to fill a phase.
The output is portable. You can ask another capable team to price it because the documents describe the work instead of our internal process. That is a useful pressure test on the scope, and it prevents the discovery partner from winning the build simply because nobody else can read what they wrote.
The people responsible for delivery stay close to the work. Technical and design constraints aren't appended after the strategy has been approved. They shape the first-release decision while the plan is still cheap to change.
Know when discovery is done.
Discovery is done when the first-release decision is clear enough to price and the largest remaining unknowns are visible. It is not done when every future feature has been designed. That replaces one kind of uncertainty with a lot of speculative detail.
Before moving into a build, ask someone who missed the workshops to read the pack. They should be able to explain the user, the job, the first-release boundary, the important rules, the dependencies and how completion will be judged. Every confused answer points to one more decision, not another round of general discussion.
If the team still disagrees about the result the first release must prove, keep working on that. If the disagreement is about a later feature, record it and move on.
Worth knowing before you start
Bring the real forms, spreadsheets and message threads into discovery. A verbal description removes the exceptions that the product eventually has to handle.
Put exclusions beside inclusions in the same scope. A separate future list gets forgotten when somebody sees a familiar feature name.
Write acceptance criteria in language a user can observe. 'The integration is complete' is not observable; the record appearing in the right place with the right permissions is.
Ask a person who did not attend the workshops to explain the first release from the documents. Their questions are the cheapest scope review you will get.
Further reading
Common questions
Long enough to settle the first-release boundary and expose the expensive unknowns, but no longer. A focused product with one user group needs much less work than a platform with permissions, integrations and several operating teams. The output should define the duration, not a standard calendar package.
Yes. The flows, wireframes, scope and acceptance criteria should be written so another capable team can build from them. If the documents only make sense to the team that produced them, they have not reduced your dependency or your risk.
For user-facing work, usually. Wireframes force the team to decide what information appears, what action happens next and what each role can see. They do not need visual polish. Their job is to expose missing rules before those rules become code.
That is a valid result. You may find an existing tool, a process change or a much smaller first release that handles the real problem. Learning that before a build is what the phase is for, even when it is not the answer anyone hoped to hear.
Bring the current process, the people who own it, examples of where it fails, the systems already involved and any commitments you cannot change. You do not need a finished feature list. In fact, treating one as fixed too early usually hides the question discovery needs to answer.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.