Get in touch

Product Strategy & Discovery

Software Discovery

Define the software the business will run on. Before you commit to building it.

Our software discovery sprint is a structured 4-6 week discovery sprint for complex software and digital transformation projects, where getting the definition right is the difference between a successful outcome and a costly one.

Get in touch

Software Discovery defines what needs to be built, how it fits into the business and what it will take to deliver, before anyone commits to the build.

A screenshot of Miro with some Discovery Sprint content

What is a software discovery sprint?

A focused, 4-6 week sprint that takes a complex software project from intent to fully defined roadmap, ready to build with confidence.

Unlike product discovery, where the focus is shaping and validating a product idea, a software discovery sprint is about defining a software solution that the business already knows it needs. The work isn’t whether to build, it’s what to build, how to build it and what it will take to deliver.

Who it's for?

  • Businesses planning a major software programme

    You’re investing in software that will run a significant part of the business, like an ERP, core operational platform, customer system or bespoke internal tool. You need to know exactly what you’re committing to before you commit.

  • Digital transformation initiatives

    You’re modernising how the business operates, replacing legacy systems or unifying fragmented tools into a single platform. The success of the programme depends on getting the definition right up front.

  • Mission critical system replacement

    You’re replacing software that’s critical to daily operations. The new system has to do everything the old one does, plus everything the business now needs, without breaking what already works.

  • High-risk projects

    Significant budget. Multiple stakeholders. Long delivery cycles. The kind of project where late surprises are expensive and avoidable surprises shouldn’t happen at all.

How we do it

Every Software Discovery starts with the short question 'why?'. Whether you're replacing an existing system or building something new, the challenge, and the opportunity behind it, has to be fully understood and documented before anything else.

  • 1. Understanding the problem

    We start by getting deep into the business and the challenge it's facing.

    • Onsite visit to see the business in context and walk through key processes
    • Discovery Workshop with the key team to define the challenge, objectives and goals
    • Identify risks, constraints and the stakeholders that need to be aligned

  • 2. Research

    With a clear understanding of the problem, we move into focused research.

    • Review existing technologies, APIs, integrations and documentation
    • Interview and shadow the people who will use the final solution
    • Build a clear picture of how the business works today and where the real opportunities sit

  • 3. Exploring ideas

    We start translating the research into a shape the solution can take.

    • Develop UX flows, user journeys and system maps
    • Define the information architecture aligned to the requirements
    • Produce higher-fidelity designs where it adds value, though not always needed at this stage

  • 4. Defining a solution

    We bring everyone back together to refine and prioritise the solution.

    • Definition Workshop to present findings and walk through the proposed solution
    • Apply a MoSCoW (must have, should have, could have) approach to the requirements
    • Agree a prioritised requirements list, focused on what matters most

  • 5. Final presentation

    We close the sprint with everything you need to decide on the validity of the project.

    • Detailed proposal and project outline
    • Clear roadmap and estimated budget
    • Prioritised requirements list

What we cover

Software Discovery looks at the full picture of what it will take to deliver. Not just the software itself, but the business, technical and delivery context it has to fit into.

  • Business and operational definition

    We define what the software needs to do for the business, end to end. Mapping the processes, workflows and operational needs the system will support, aligning stakeholders across departments, functions and leadership, and capturing the outcomes the business needs the software to deliver.

  • Solution architecture and technical approach

    We define how the software will be built and how it will fit into the wider technical landscape. Shaping the architecture, technology stack and platform approach, defining integration with existing systems, data and infrastructure, and identifying where AI capability fits into the solution, now and over time.

  • Scope, phasing and delivery planning

    We define what gets built, in what order and what it will take to deliver. Breaking the programme into deliverable phases, defining scope, dependencies and critical paths, and setting realistic timelines, team shapes and delivery models.

  • Risk, cost and feasibility

    We surface the risks and unknowns before the build, not after. Identifying technical, operational and commercial risks, validating feasibility against budget, timeline and capability, and providing a clear, evidence-based view of what the project will cost.

  • Change and adoption

    We plan for the people side of the change, not just the software. Identifying the impact on teams, processes and ways of working, planning for training, rollout and adoption, and making sure the business is ready for the system it's going to get.

What you get

Upon completion of the Software Discovery, the challenge will have been fully explored and documented. You'll have everything you need to make an informed decision about whether to move forward with the build.

Project Plan

A clear, validated definition of what the software needs to do, who it's for and the outcomes it has to deliver for the business.

Success metrics

The measures the project will be judged against, agreed up front so success is defined before delivery begins, not after.

Prioritised requirements list

A MoSCoW-prioritised list of what the software has to do, what it should do and what could come later, so investment goes where it matters most.

Timeline and roadmap

A clear view of what gets built and when, with realistic timelines, phasing and milestones the business can plan against.

Estimated project cost

An estimated project cost, aligned to the requirements and delivery plan, giving the business a realistic view of investment before committing to the build.

Risks and dependencies

The technical, operational and commercial risks surfaced early, with a clear plan for what it will take to mitigate them.

Identified AI opportunities

Where AI creates real value in the solution, how to embed it safely and what it would take to deliver.