Product Strategy & Discovery
Product strategy and discovery before the build.
Define the problem, test the assumptions and agree a credible route into delivery.
Clarity first
When clarity comes first.
A software brief often starts with an outcome rather than a specification. Discovery establishes what needs to change, who needs it and which uncertainties matter before committing to a build.
Understand the problem
Map the users, current workflow and commercial constraints. Separate the problem to solve from an assumed feature list, and agree how a useful result will be recognised.
Test the assumptions
Identify the decisions that depend on evidence: whether data is available, an integration is feasible, users will adopt a workflow or a proposed product can operate within its constraints.
Agree the way forward
Compare practical options, including adapting existing software. Define a first release that can answer the important questions without committing to every later feature.
What discovery delivers
From questions to a clear plan.
The outputs are agreed around the decisions you need to make. They should be useful to the people commissioning, building and operating the software.
User needs and scope
A documented view of users, workflows, priorities and acceptance criteria, with explicit boundaries around what the first release includes and defers.
Feasibility and technical due diligence
Targeted assessment of data, integrations, existing code and technical constraints. Where access is limited, the findings identify what could be assessed and what remains unverified.
Architecture and delivery roadmap
A proposed system shape, significant trade-offs, dependencies and a prioritised sequence of work. Estimates state the assumptions and unresolved risks on which they depend.
Better decisions
Decisions before commitment.
Discovery is useful when its conclusions change a decision. A prototype, workshop or code review should answer an identified question rather than become an end in itself.
Evidence over opinion
Use interviews, workflow observation, available system information and focused experiments where they are appropriate. Keep findings separate from assumptions.
Clear priorities
Agree which capabilities are essential, what can follow and where an existing tool is sufficient. A recommendation to defer or narrow the build is a valid outcome.
Visible risks
Surface access, security, procurement, migration and operational dependencies early. Give each unresolved question an owner and a next action.
Investment
Paid discovery and cost drivers.
Discovery is a paid engagement scoped to your objectives and the complexity of the product or system. Its cost depends on the work needed to reach useful decisions.
Breadth of investigation
The number of user groups, workflows and stakeholders determines the research and decision-making effort. A focused feasibility question needs a different scope from a new product definition.
Technical depth
Existing code, data quality, third-party access and integration constraints affect the assessment. Security or regulated-use questions may require additional specialist input.
Required outputs
Agree the detail needed in prototypes, architecture, specifications and roadmap before work begins. Duration and fees follow that scope; they are not assumed from a standard package.
What happens next
A clear route to delivery.
The close of discovery is a decision point. Review the findings and choose the next investment with a shared understanding of scope, dependencies and risk.
Share and review
Walk through the findings with commercial and technical stakeholders. Resolve disagreements and record the decisions that will guide delivery.
Align on priorities
Agree a delivery scope or the next experiment. Confirm ownership of requirements, access, feedback and acceptance before the build starts.
Move into the right engagement
The next step may be a prototype, a defined product build, a rescue programme or ongoing development. You can also use the agreed outputs with your existing engineering team.
Common questions
Common questions, straight answers.
The scope and deliverables are agreed before work starts. They can include user and workflow definition, feasibility checks, technical due diligence, architecture and a prioritised roadmap. Not every engagement needs every activity.
Start the conversation
Turn your ideas into a plan.
Tell us which decision you need to make and what is still uncertain. We can discuss an appropriate discovery scope.