A few years apart, I found myself having the same argument in two very different companies.
In the first, a client came to us with an existing software package. They needed two junior developers to maintain it.
The commercial arrangement was simple: they paid us the salaries of those two people, plus what can generously be described as loose change.
I wasn’t enthusiastic.
My concern wasn’t that the work was beneath us. Someone had a system that needed maintaining. They were willing to pay for it. Fair enough.
My concern was what came next.
The client wanted more people. More developers in the same stack. Then some in another stack. They had requirements, and understandably, they wanted us to build a team around those requirements.
I wanted to focus our hiring around a narrower set of capabilities that we could build expertise and scale around.
Then came the inevitable question:
“If you only hire for those skills, how will you scale?”
I didn’t have a perfect answer.
But I remember being immediately irritated by the implication that, because I didn’t have one, the client was therefore entitled to provide the answer.
Their answer, unsurprisingly, was that we should hire people with whatever skills they needed.
That may have helped them scale.
It wasn’t obvious to me that it would help us scale.
A customer requirement is not automatically a company strategy.
That was one way to accidentally become a services company: allow a sufficiently persistent customer to gradually define what your company does, who you hire, and what capabilities you build.
Years later, I encountered a very different version of the same problem.
This time, nobody was asking us to become a services company.
We were doing it to ourselves.
We had a product. We had clients. And clients had requests.
A feature here. A workflow there. A configuration for one use case. A variation for another.
Individually, most of these requests made sense. There was usually a legitimate reason for them. A customer needed something, and we figured out how to make it happen.
But over time, I started feeling uncomfortable with the pattern.
We were getting increasingly good at servicing requests.
That isn’t necessarily the same thing as improving the product.
The difference is subtle, but important.
When a client asks for something, the immediate question is:
How do we fulfil this request?
A product company should also be asking:
Why are we getting this request, and what should exist in the core product so that we don’t have to solve versions of it individually every time?
That distinction eventually led me to the idea of One-Core.
The basic thinking was simple. Instead of continuously adding solutions around the edges of the stack, could we build a robust core that made those requests easier to handle systematically?
Not because every customer should get exactly the same thing. Products need flexibility.
But flexibility and fragmentation are not the same thing.
You can keep responding to individual requests until your product becomes a collection of exceptions. Or you can periodically step back and ask whether those requests are pointing to something missing in the underlying architecture.
The first approach keeps everyone busy.
The second one might actually reduce the need to keep everyone busy.
Looking back, the two experiences were almost opposites.
In one company, the risk was that a client would define our strategy.
In the other, the risk was that a growing collection of client requests would define our product.
The lesson I took from both is not that you should refuse custom work.
Sometimes a customer request is strategically important. Sometimes it reveals a genuine market need. Sometimes you simply need the revenue.
But there is a line somewhere.
And you probably need to notice when you’ve crossed it.
Because you don’t necessarily wake up one morning and decide to become a services company.
Sometimes, you just keep saying yes.
And one day, you look at your roadmap and realise it isn’t really a roadmap anymore.
It’s a queue of requests waiting to be serviced.
–
Working through a similar product challenge?