Product discovery & scoping
Know what you are investing in before the build begins.
Scope
From existing material to an agreed scope
Understand the current work
Map the critical workflows, users, documents and systems. Identify exceptions and constraints with the people who handle them.
Test the uncertain parts
Use prototypes, technical checks or data samples where they answer a material question. Choose the method around the uncertainty.
Define the delivery basis
Document the proposed scope, priorities, acceptance criteria, dependencies and assumptions behind the estimate.
A scope you can make decisions with
The work, including the awkward parts
Who uses the product, what happens to each record, which rules matter and where the exceptions go. We review existing material before asking your team to explain everything again.
Something concrete to review
Requirements, process maps, architecture or a clickable prototype, depending on what needs to be resolved. A workshop is useful when it settles a question; it is not the deliverable on its own.
A first release with boundaries
Priorities, acceptance criteria, dependencies and the assumptions behind the estimate. You can see what is included, what needs another decision and what can wait.
A spreadsheet can be a specification in disguise
In ZMatic’s project, interconnected spreadsheets held business rules as well as records. Understanding those dependencies was part of designing the ERP and preparing the migration.
Discovery needs to reach that level of detail. A feature called “orders” is not enough to estimate until the team understands what can happen to an order. See how that shaped ZMatic’s ERP.
Agreeing the discovery scope
Will we get designs and development estimates?
We agree the outputs before starting. Depending on the question, they can include requirements, workflows, architecture, a clickable prototype, a roadmap and estimates. The required depth determines the work.
What happens when discovery reveals a larger problem?
We make the finding and its effect on the scope explicit. You can change priorities, investigate further or stop before committing to the larger implementation.
Who should join a product discovery workshop?
The people who do the work, someone who can decide business priorities and anyone responsible for a critical system or integration. We agree who is needed for each conversation so your whole team does not spend the week in meetings.
Let’s put a boundary around the build.
Share the intended outcome and the systems involved. We can define what needs to be understood before an implementation commitment.