What Did I Get Wrong About Productizing a Services Business?

What did I get wrong about productizing a services business?

I thought productizing was mostly a pricing decision. Fix the price, fix the scope, publish it, and the chaos of custom work goes away. What I actually learned is that pricing is the easiest part to standardise and the least important one, because the chaos lives in the inputs rather than in the invoice.

I price fixed fee, and most of my projects land between one thousand and ten thousand dollars. For a long time I treated that as evidence that I had already productized. It is not. A fixed price is a commercial choice about who carries the risk. A productized service is an operational claim that the work itself is the same every time, and those are very different promises.

Six years, more than 70 projects, more than 25 clients, and the thing I keep relearning is that the variance in services work almost never comes from the deliverable. It comes from the client.

What does productizing actually mean?

It means the work is defined tightly enough that the same process produces the same outcome regardless of who buys it. Same inputs, same steps, same output, same duration. A real productized service can be described without knowing anything about the customer beyond which package they picked.

That is a much stronger claim than it sounds. It means you are not just selling a fixed scope, you are asserting that the client's situation does not materially change the work. For some services that is obviously true. For most of what I do, it is obviously false, and the honest thing was to notice that rather than to force it.

The useful test is whether you could hand the brief to someone else with a checklist and get the same result. If the answer depends heavily on judgment applied to a specific context, you have a craft with a fixed price, which is a fine business, but it is not a product and pretending otherwise creates problems later.

Why is fixed-fee pricing not the same as a productized service?

Because fixed fee is about who absorbs uncertainty, and productizing is about removing it. When I quote a fixed fee I am saying that if the work takes longer than expected, that is my problem. That is a deliberate transfer of risk from the client to me, and it works because I have enough history to price it reasonably.

Productizing would mean the work does not vary enough for that risk to exist. Those two things look identical on an invoice and behave completely differently when a project goes sideways. Confusing them is how people conclude that fixed fee does not work, when what actually failed was an assumption about sameness.

The practical difference shows up in what you do when a project runs long. With a real product, a long run means your process broke and you should fix the process. With fixed-fee craft work, a long run usually means you misjudged that particular situation, which is a pricing and qualification lesson rather than a systems one. I have written about what I do when a fixed-fee project goes over scope, and none of those answers involve standardising harder.

What breaks when the scope is standard but the client is not?

Everything that depends on the client showing up. The deliverable can be perfectly specified and the project still takes three times as long because content arrives late, feedback comes from four people who disagree, or the person who hired you leaves halfway through.

This was the part I underestimated most. I was standardising the half of the project I control, which is the building, while the half that actually creates variance sat untouched. Two clients buying the identical package can produce wildly different experiences, and the difference has nothing to do with what was in the scope document.

What follows from that is uncomfortable but freeing. If most variance comes from the client rather than the work, then the highest-leverage standardisation is not in your delivery process at all. It is in who you accept and what you require from them before starting, which is a qualification problem rather than a packaging one.

Where does productizing genuinely work?

On narrow, repeatable, self-contained pieces of work with a clear finish line and almost no dependency on client input. An audit is a good candidate, because you can do the whole thing yourself and hand over a result. A specific technical implementation with a defined endpoint is another.

The pattern is that good candidates are the jobs where you already know what you will find before you look. If you have done something forty times and the shape of the answer never surprises you, the process is genuinely stable and deserves to be packaged. That is not a failure of ambition. It is the recognition that some work is genuinely routine and should be priced and delivered as such.

The opposite pattern is anything that begins with understanding a business. Positioning work, go-to-market decisions, and anything that requires judgment about a specific situation will resist productization no matter how confidently you write the package description, because the first real step is always finding out what is actually going on.

What does it cost you to standardise too early?

You lose the ability to see what is actually happening in your own work. A package tells you what you did. It does not tell you what the client needed, and if you commit to packages before you have enough range to compare, you stop collecting the evidence that would tell you what to package.

There is a second cost that I think is underrated. Standardised offers tend to attract clients who are shopping on scope and price, because that is what a package invites you to compare. Custom work attracts clients who want a judgment call, and those are usually the better engagements at the size I work at.

The third cost is that a package you cannot actually deliver at the promised effort becomes a slow leak. You honour it because you published it, the margin quietly disappears, and you learn the wrong lesson about the whole category of work rather than about the one bad definition.

How do you tell whether a service is ready to be productized?

Look backwards at how many times you have done it and how much the effort varied. If you have delivered something ten or more times and the effort range is narrow, you have a candidate. If you have done it three times with wildly different hours, you have a hypothesis rather than a system.

The second check is to ask what the client has to do. Count the points where the work stops until someone responds. A service with one client dependency can be productized. A service with seven cannot, regardless of how well defined your side of it is.

The third check is whether you can say no to a customisation request without damaging the outcome. If every buyer needs one small exception and each exception is reasonable, you do not have a product. You have a starting point for a conversation, and it is more honest to sell it that way. My decision to stop doing free discovery on small projects came out of exactly this realisation about where the real work begins.

What do I do instead now?

I standardise the parts of the relationship rather than the parts of the work. How a project starts, what I need before I begin, how feedback is collected, how many rounds there are, what happens when something is late. Those are identical across engagements and they absorb most of the variance that used to hurt.

The work itself stays fixed-fee and shaped to the situation. I have a clear sense of what things cost me, so I can quote quickly without pretending the work is interchangeable. The client gets certainty about the number, and I keep the freedom to do what the situation actually needs, which is what they are paying for anyway.

For ongoing work the same logic applies to retainers, where the temptation to package is even stronger and the variance is even higher. I have written about what running flat monthly retainers taught me, and the core lesson is the same one. Standardise the container, not the contents.

What should you do next?

List the last ten pieces of work you delivered and write down, honestly, how much the effort varied within each type. Not what you quoted. What it actually took. The types with a narrow range are your real productization candidates and there are usually fewer than you hoped.

Then look at where the time went in the ones that ran long. If it went into building, your process needs work. If it went into waiting, chasing, and re-deciding, no amount of packaging will fix it and the answer is in how you start projects rather than how you price them. That distinction saves people a lot of wasted restructuring.

If you are somewhere between custom work and packages and cannot tell which direction to move, I am happy to talk it through. It is a decision I have gone back and forth on myself and the reasoning is more useful than the conclusion.