Product discovery

Jobs to be done, story mapping, and a scope you can defend.

The most expensive software is the software nobody needed. We find the smallest release that proves the idea, map every step of the job it replaces, and write down what stays out and why, so the first version ships in weeks and teaches you something.

See it in our work

At a glance

Length
Two weeks to start
Price
Fixed, known before we start
You leave with
A story map and a written first release
Afterwards
Discovery runs alongside every release

What it covers

What the discovery sprint covers.

  • Jobs to be done

    What progress the user is trying to make, learned from what they did last week rather than what they say they want.

  • User story mapping

    The whole job drawn out as a map, so the first release is a thin slice across all of it and not a pile of features from one corner.

  • Hypotheses with a result inside two weeks

    Each assumption stated, a way to test it named, and product analytics wired in so the answer arrives with numbers.

  • Continuous discovery

    Discovery does not end when coding starts. It runs alongside delivery, so the roadmap changes when the evidence does.

How we do it

Two weeks to a first release scope.

  1. 01

    A discovery sprint, two weeks

    Interviews, the story map, the thinnest first release, and the risks ranked: value, usability, viability, feasibility.

  2. 02

    Prototype what is uncertain

    Where a risk is real, a prototype or a fake door answers it before engineering time is spent.

  3. 03

    Scope in writing

    What is in version one, what is out, and the reason for each. This is the document you take to your board.

  4. 04

    Analytics from the first release

    Matomo, Segment compatible, vendor agnostic. Every release ships with the instrumentation to judge it.

What you get

A direction you can build on.

  • A user story map of the job
  • A ranked risk list and the experiments that retire the top ones
  • A written first release scope, with what stays out and why
  • Wireframes or prototypes where a risk needed one
  • An analytics plan and the events to instrument

Where we have done it

Real engagements, named.

Questions

Questions we get asked.

How long does discovery take?
Two weeks to start. Long enough to map the job, rank the risks and scope the thinnest first release, and short enough that nobody is paying for a study while the product waits. Then it becomes continuous. Discovery runs alongside every release, so what we learn from real users in month two changes what we build in month three. The first two weeks buy a direction, not a finished plan.
We already know what we want to build.
Then discovery is short and it confirms the scope, ranks the risks, and gets the analytics in place. It rarely takes the full two weeks in that case.
Is this design?
It includes the design decisions that carry risk. Full visual design comes with the build, in the same team.
What does it cost?
A fixed price for the two week sprint. You know it before we start.

What clients say

In their words.

01 / 04

Life Insurance Direct
Before Metricsense, checking calls was a manual process: we selected files for review. Now the platform analyses every call, and we review by risk. It has identified customer experiences we would not have picked up before, and it lets us scale our quality assurance program without increasing headcount, with our team still the human in the loop. It helps us protect our customers, our business and our agents.

Russell Cain

Founder and CEO, Life Insurance Direct

Also under product development

Where it leads next.

All of product development

Not sure this is the right place to start?