Turning a services business into a software product
Agencies and consultancies have the domain knowledge product companies spend years acquiring. Most attempts still fail, and they fail for the same three reasons.
Key takeaways
- The advantage is real domain knowledge; the obstacles are cash flow shape, accommodation instinct and different skills.
- Commit the budget and the timeline in advance, because pressure to reverse arrives in the first quarter billings dip.
- Find the deliverable built repeatedly with small variations; that is the product candidate and the demand evidence.
- Decide explicitly whether the product replaces the services business or runs alongside it.
A services business converting to software starts with a genuine advantage: it already knows the problem, the workflow and the customers, which is what product companies spend years and considerable money learning. It also faces three structural problems that sink most attempts, and all three are about the business rather than the software.
Problem one: the cash flow shapes are incompatible
Services revenue arrives when work is delivered. Product revenue arrives slowly and compounds later. Building a product from services cash means diverting your best people from billable work into something that will not pay for eighteen months, and the pressure to pull them back arrives in the first quarter where billings dip. Decide in advance how much you will spend and how long you will wait, and treat that as committed rather than reviewable monthly.
Problem two: every client is different, and the product cannot be
A services team's instinct is to accommodate. That instinct produces a product with a configuration option for every client request, which is a bespoke system with extra steps and worse economics than the consulting it replaced. Productisation requires deciding which variations you will not support, and telling long-standing clients no, which is culturally the hardest part.
Problem three: the skills are genuinely different
- Services sells to one buyer at a time with a tailored proposal. Product sells the same thing repeatedly and needs a repeatable motion.
- Services support is a relationship. Product support has to scale without adding a person per customer.
- Services succeeds by doing what is asked. Product succeeds by deciding what not to build, which is an unfamiliar and uncomfortable discipline.
- Product needs someone whose only job is the product. A part-time owner between client commitments produces a part-time product.
The sequence that works
Find the deliverable you have built for many clients with only small variations. That is the product candidate, and its existence is the evidence that demand is real. Build it for three existing clients as a shared system rather than three projects, charging a licence rather than a project fee. If those three renew without you doing custom work for each, you have a product. If they do not, you have learned that cheaply.
The decision to make explicitly
Whether the services business is funding a product it will eventually become, or adding a product line it will run alongside. Both work; drifting between them does not, because they imply different answers to every subsequent question about resourcing, pricing and who owns the customer relationship. Write the answer down and revisit it deliberately rather than by accident.
A configuration option for every client request is bespoke consulting with worse economics.