The Discovery Sprint: How We Find the Product Inside Your Service Business

The most common thing I hear from service business owners considering software is: "I know there's something there, but I don't know what to build."

That's not a problem. That's the starting point for almost every successful product I've built.

The Discovery Sprint exists precisely for this moment. It's a one-week, £2K engagement designed to answer the question "what should we build?" before you spend anything on actually building it. By the end, you have a methodology map, a business case, a clickable prototype, and a clear recommendation — not a pitch, but an honest assessment of whether building makes sense for your business.

Why service business owners can't see the product

It's not a lack of intelligence or imagination. It's proximity.

When you've been running a methodology for years, it becomes invisible to you. The risk assessment framework your team follows? That's "just how we work." The client onboarding process that reduces churn? "Everyone does something similar." The diagnostic sequence your senior partners use? "That's just experience."

From outside, these are valuable systems that could be encoded into software. From inside, they're wallpaper.

After 100+ product builds, I see patterns that founders can't see from within their own business. I know which types of methodology translate well into software and which don't. I know which revenue model fits which type of service business. I know what "done" looks like because I've shipped it dozens of times.

That pattern recognition is what makes Discovery worth doing before spending £10K+ on a build.

What happens in a Discovery Sprint

Five days. Four deliverables. One decision.

Day 1-2: Methodology Mapping

This is the extraction phase. I work with the founder (and sometimes their senior team) to pull out the methodology that currently lives in people's heads, spreadsheets, and scattered documents.

We map the core process end-to-end. Not a high-level "we do discovery, then delivery, then follow-up" overview — the actual decision points, branching logic, inputs, outputs, and handoffs. The things a new hire would need three years to learn.

Questions I'm asking: Where does client data come in? What decisions get made at each step? What separates a good outcome from a mediocre one? Where do things go wrong? What do your best people do differently from your average people?

The output is a methodology map — a structured representation of how your business actually delivers value. Most founders have never seen their methodology laid out this clearly. Many say this exercise alone is worth the Discovery fee because it forces them to articulate things they've never put into words.

Day 2-3: Opportunity Scoring

Not every part of your methodology is equally suited to software. Opportunity scoring identifies which components have the highest leverage.

I evaluate each component against four criteria:

Repeatability. How consistently does this process run? If it's different every time, software won't help much. If it follows the same structure with variations in data, it's a strong candidate.

Value density. How much of your total value delivery is concentrated in this component? Building software around a high-value component creates immediate impact. Building around a low-value component creates a "nice to have" that nobody uses.

Current friction. Where are the bottlenecks? Where do things slow down, get dropped, or depend on specific individuals? High-friction components are where software creates the most relief.

Scalability potential. Could this component serve more clients if it were systematised? Could clients use it independently? Could other firms license it?

Each component gets scored. The highest-scoring components become the product scope. This prevents the common mistake of trying to build everything at once and ending up with a sprawling product that does nothing well.

Day 3-4: Prototype Building

This is where it gets tangible.

Using the methodology map and opportunity scores, I build a clickable prototype — a working frontend that shows what the software would look like and how users would interact with it. Not wireframes. Not slides. A working application that you can click through and experience.

The prototype covers the core user journeys: how a client would sign up, how they'd use the system, what they'd see, what actions they'd take. It uses your terminology, your branding cues, and your data structures.

Most founders say this is the moment it "clicks." They've been hearing about software abstractly. The prototype makes it concrete. They can see their methodology reflected in an interface and immediately start saying "yes, that's right" or "no, that should work differently."

That feedback is gold. It means when we move to the build phase, we're not guessing about what the client wants — they've already told us by reacting to something tangible.

Day 4-5: Business Case Creation

The final deliverable is an honest business case. Not a sales pitch — an assessment of whether building makes sense.

This includes: revenue projections across the three models (Use It, Sell It, License It). Build cost and timeline. Ongoing costs (hosting, maintenance, development). Break-even analysis. Risks and assumptions.

It also includes a recommendation. Sometimes the recommendation is "build this, here's exactly what to build and why." Sometimes it's "this isn't the right time, and here's why." Sometimes it's "there's an opportunity here, but it's different from what you initially thought."

I've talked founders out of building when the numbers didn't make sense. That's part of the value — spending £2K to avoid spending £10K+ on the wrong thing.

What you walk away with

After five days:

A methodology map that documents how your business actually delivers value — often clearer than anything you've previously articulated.

An opportunity score that identifies which components of your methodology have the highest software leverage.

A clickable prototype that shows what the product would look like and how users would interact with it.

A business case with revenue projections, cost analysis, and an honest recommendation on whether to proceed.

A build specification — if the recommendation is to build, you have a detailed scope that feeds directly into the 30-day build process. No additional planning phase needed.

The Discovery Sprint as a filter

Discovery is designed to be a standalone engagement that earns the next step. There's no obligation to build after Discovery. If the business case doesn't stack up, you've spent £2K and gained clarity — which is infinitely better than spending £10K+ and discovering the problem mid-build.

For context, agencies typically quote £50K+ for the kind of product that comes out of my 30-day build process. But before any of that spending happens, Discovery tells you whether it's worth doing at all.

The seven-point readiness checklist can help you self-assess before reaching out. But if you're reading this post and thinking "there might be something there," that's usually enough to justify a conversation.

Who Discovery works best for

Service businesses with: established methodologies that have been refined through real client work. Revenue (this isn't for pre-revenue startups). Client demand that outstrips current capacity. Expertise that's currently locked in people's heads rather than systems.

Service businesses where Discovery isn't the right fit: those that can't define their methodology in steps. Those looking for a generic SaaS clone rather than something built around their specific expertise. Those that need the software to generate their first revenue (you need an existing business for this to work).

If you want to understand the broader opportunity before committing to Discovery, the pillar post on service business software covers the valuation maths, market dynamics, and case studies. If the "why" is clear and you want to understand the "how" of a 30-day build, read the anatomy of a service business software build.

And if you want to understand why your methodology specifically — not generic AI — is what creates lasting value, this post on AI and methodology makes the case.

Ready to find out what's hiding in your service business? Book a Discovery Sprint →

---

Tom Crossman builds scalable systems and software for service businesses at Hello Crossman. 18 years in product development. Head of Product Engineering at Habito (£3B in mortgages processed). 100+ products shipped. See the case studies →