How I Actually Find the Product Inside a Service Business

A practitioner walkthrough using RiskPod — what I actually noticed, what I asked, what I ruled out, and why.

Everyone asks how to find the software product inside a service business. Here is the actual diagnostic process I used with RiskPod — not the marketing version, but the real decisions made in real time.

How I Actually Find the Product Inside a Service Business

A few weeks ago I got a comment on LinkedIn from Yavor Alexandrov that stopped me mid-scroll. He asked about the distinction between methodology and manual labour — specifically, how do you identify which processes in a service business are actually ready to become software?

It's the right question. And the honest answer is that after 100+ builds, the process feels like instinct to me. Which is precisely the problem — I've never written it down.

So this post is that. Not the polished "Discovery Sprint" framing you'll find on the Hello Crossman services page. The actual diagnostic process, walked through using RiskPod as the example. What I noticed when Mark first described his business. What I asked. What I ruled out. And why it ended up as 550 signups in 48 hours rather than a £130K agency project that never shipped.

What you're actually listening for in the first conversation

Mark Weclawek got in touch after getting agency quotes that made his eyes water. £120K–£130K+. Six-month timelines. He described his business: a compliance and risk contractor recruitment firm in financial services. Placing specialist contractors into regulated roles.

Here's what I heard while he was talking.

The word "again". He kept saying things like "we go through the same process again" and "every time we take on a new contractor it's the same steps." That's the signal. Repetition is the raw material of software. If a founder describes their work in unique, bespoke, case-by-case terms — that's a consulting business, and software won't help much. If they keep using words like "again", "every time", "same process" — there's a product in there.

The name of the bottleneck. At some point in almost every first conversation, the founder either says or implies the thing that slows everything down. For Mark it was matching. "It's just... finding the right contractor for each role takes time." Not finding contractors — they had plenty. Finding the right one. That's a matchmaking problem. Matchmaking problems are highly productisable.

What falls apart without them. I asked Mark what would happen if he took a two-week holiday with no phone. He laughed. The answer was: placements would stop. That's not a criticism — it's information. The thing that stops when the founder isn't there is usually the thing that becomes the product.

Finding the repeatable atomic transaction

Once I understood the business was in compliance contractor placement, the next question was: what is the smallest indivisible unit of work that happens over and over?

Not "recruitment." That's too big. Not "the whole process from job brief to placement confirmation." Too complex to start with.

The atomic transaction for RiskPod was this: a contractor applies their details, and a job opportunity is matched to them.

That's it. Everything else — the document verification, the admin dashboard, the messaging, the broadcast emails — is infrastructure around that single transaction. But the transaction itself is simple: contractor profile in, match out.

This matters because it tells you what to build first and what to build later. If you can't make that single transaction work — a contractor puts their details in and gets a relevant job opportunity back — nothing else matters. Build that, and everything else becomes a supporting feature.

For every service business I look at, I'm trying to find that atomic transaction. For a training provider it might be: learner takes an assessment, receives a personalised learning path. For a compliance consultancy: client fills out a questionnaire, receives a gap analysis. For a marketing agency: client inputs their goals, receives a content brief. Strip everything back to the one repeatable thing.

The diagnostic questions I actually ask

There's no official list. But there are questions I find myself asking in almost every initial conversation, because the answers tell me what I need to know.

"What do you do for every single client, without exception?" This surfaces the repeatable core. If the answer is "it depends" for every step, there might not be a product yet. If certain steps are always the same — intake, assessment, matching, reporting — those are the candidates.

"What do your best clients ask for between engagements?" Self-serve access to their data. Automated updates. A dashboard they can check without calling you. The feature requests your clients make most often are your product's core functionality, because they're describing the friction they feel.

"Where do things slow down?" Bottlenecks are opportunities. Mark's bottleneck was matching — it was manual, time-consuming, and depended entirely on him knowing which contractors had which certifications in which jurisdictions. That's a problem software loves: structured data matching against structured criteria.

"If you had to hire someone to do this specific part, what would you write in the job ad?" This is my favourite question, because it forces founders to articulate the decision-making criteria they've never had to explain before. Mark's hypothetical job ad would have said something like: "Must understand compliance certifications, rate expectations in financial services, and how to assess contractor experience across multiple regulatory jurisdictions." That job ad became the matching algorithm.

How the methodology gets extracted

This is the part that's genuinely hard to explain, but I'll try.

Mark's matching process wasn't documented anywhere. It lived entirely in his head, built up over years of placing contractors. The question was how to get it out in a form that could become software.

I didn't ask him to document his process. I asked him to walk me through a specific recent example. "Tell me about the last contractor you placed. What did you know about them? What did you know about the role? Why did you put those two together?"

He talked for about twenty minutes. By the end of it, I had the shape of a weighting system. Skills mattered most — maybe 40% of the decision. Rate compatibility was important — if the contractor's day rate was way above the client's budget, it was a non-starter regardless of skill fit. Jurisdiction experience was significant in this niche because financial services regulation varies considerably across territories. Availability and profile completeness rounded it out.

I wrote those back to him as a list with rough percentages and asked if it felt right. He adjusted a couple of numbers. That conversation — maybe thirty minutes total — became the 5-dimensional matching algorithm that sits at the core of RiskPod. Skills 40%, rate compatibility 20%, jurisdiction experience 20%, availability 10%, profile completeness 10%.

The software didn't invent that weighting. Mark did, through years of making those calls manually. We just wrote it down and made it run without him in the room.

This is the distinction Yavor was pointing at. Methodology vs manual labour. Mark's methodology was the matching logic — the criteria, the weighting, the judgment about what mattered. The manual labour was applying it by hand, across spreadsheets and email threads, for every single placement. The software replaced the manual labour and encoded the methodology.

What I decided not to build

This is the part nobody talks about. Every build involves as many decisions about what not to include as what to include.

Stripe payment infrastructure was built into RiskPod's architecture from the start, but not switched on. There was no reason to take payments before there were clients using the platform. Building payment flows for a pre-revenue platform would have been two or three days of work that added zero value at launch.

White-label client portals — the ability for each employer client to have their own branded interface — were scoped as a future feature, not a launch feature. Desirable, but not essential for the first 550 signups to validate the core value proposition.

CV parsing with AI was discussed. Dropped. Nice-to-have, but the 10-step onboarding wizard would collect the same information more accurately, because it asked structured questions rather than trying to extract structure from unstructured documents.

The principle is: if a feature doesn't directly make the atomic transaction work better, it's version 2. When I'm scoping a build, I'm constantly asking "what is the minimum set of features that makes a contractor's profile match to a job opportunity, reliably, without Mark?" Everything that isn't on the critical path to that is out.

This is harder than it sounds. Founders have usually been thinking about their product for months before they talk to me, and they've accumulated a long list of features. The discipline is not building the list — it's identifying the single feature that matters and doing that really well.

Why the day 5 prototype changes everything

I sent Mark a working prototype five days after we started. Not a mockup. Not wireframes. A working application he could log into, click through, and react to.

This wasn't a confidence trick or a sales technique. It's the most efficient way to surface the decisions that can't be made in the abstract.

Before the prototype, I'd asked Mark whether contractor profiles should show their rate as a range or a single figure. He said a range. After seeing it in the prototype, he changed his mind — a single target rate with a tolerance field was cleaner. That conversation took thirty seconds looking at the actual screen. It would have taken thirty minutes of hypothetical discussion without it.

Founders are not good at reviewing specifications. They are very good at reacting to things they can see and touch. The prototype converts abstract product decisions into concrete ones. "Move this field up" is a much better conversation than "I'm not sure the information architecture is right."

The day 5 prototype also anchors the entire build. It sets the visual language, the user flows, the terminology. Everything built in weeks 2, 3, and 4 is extending and connecting that foundation, not reconceiving it. That's why 30 days is achievable — because the hardest decisions get made early, with the founder's input, while changing them is still cheap.

The question that tells you if there's really a product

After all of this — the first conversation, the atomic transaction, the methodology extraction, the scoping — there's one final question I ask myself before committing to a build.

Does the market already exist, or does the product have to create it?

For RiskPod, this was easy. Mark's existing network of contractors and employers already wanted this. They were already using a version of it — just one that ran through Mark's inbox. The product wasn't creating demand, it was meeting demand that already existed and was being served expensively and slowly.

This is the strongest signal that a service business has a real product to build. When your existing clients are already doing the thing your software would do — just badly, slowly, manually — you don't have to convince anyone the problem is worth solving. You just have to make the solution better than the spreadsheet.

550 signups in 48 hours wasn't luck or clever marketing. It was Mark's existing network recognising that the thing they'd been asking for — a proper platform for compliance contractor matching — had finally appeared. The software validated immediately because the market already existed and trusted him to build it.

---

Frequently asked questions

How do you know if a service business has a product inside it?

The clearest signal is a repeatable transaction the founder performs for every client, where the bottleneck is the founder's time and judgment rather than the problem's complexity. If the same steps happen every time, and those steps could run without the founder in the room, there's a product. If every engagement is genuinely bespoke — different problem, different approach, different outcome — the product isn't ready yet.

What if the founder can't articulate their methodology?

Walk them through a specific example rather than asking them to describe the process in the abstract. "Tell me about the last client you onboarded" produces better information than "how does your onboarding work?" Most founders can narrate a specific story even when they can't describe the general process, because the general process is invisible to them.

How do you decide what to build vs what to leave for version 2?

Start with the atomic transaction — the smallest indivisible unit of value the software needs to deliver. Any feature that doesn't directly enable that transaction is version 2. This is harder than it sounds because founders have usually accumulated months of feature ideas. The discipline is identifying the one thing that matters and doing it well, not building the list.

How long does this diagnostic process take?

The first conversation is 30–45 minutes. Methodology extraction — if done properly, walking through specific examples and building the decision criteria — takes another 2–4 hours spread across a week. The prototype follows shortly after. Most of the important decisions are made in the first two weeks, before significant development cost is committed.

Is this the same as a Discovery Sprint?

The Discovery Sprint is the formalised, £5K version of this process that produces a build-ready specification, business case, and prototype as deliverables. The diagnostic process described here is the thinking that underlies it — the questions, the frameworks, the instincts that I apply whether it's a formal sprint or an initial call. If you want to go through this process with your own business, start with a free call.

---