“Are you a product company or a services company?”
Updated: Sep 15
That was the first question I asked my client’s CTO about 10 minutes into the company overview. I was asked to help out after their biggest client threatened to pull the plug on a years-long relationship that still had several years left on the contract. The client was frustrated with product “bugginess” and the slow progress of custom features and began questioning the company’s ability to meet their needs. If the company couldn’t present a “get well” plan—including detailed disciplined processes—they were ready to walk away.
“WHAT?!” The CTO was incredulous. “We’ve been trying to answer that for 15 years, and you come in here and ask it after 10 minutes?!”
“Yes,” I said, “and the performance and delivery issues you’re asking me about won’t get resolved until you make a decision on that.”
Immersed in the day-to-day firefighting with bugs, new features, and the overhanging gloom of the unhappy client kept the CTO and their team from seeing it. Having no prior operational training, this connection wasn’t obvious... which is rather common.
Has anyone ever heard a business school professor say, “your people can’t be doing three things at once, so don’t plan on that working for you.” If you haven’t, you’re not alone. It’s so obvious that it seems unnecessary to mention. From my experience, it’s not as obvious as we think, therefore companies do it all the time.
The CTO could be excused for not seeing the “obvious.”
OK, then why didn’t the COO see it? I asked the COO—a sales and finance person—the same thing that I asked the CTO. The COO’s answer was less a nuanced, “we’re not going to pin ourselves to one or the other, and that’s that!”
“Well,” I thought, “this engagement is over.”
I felt bad for the CTO. They were being tasked with solving delivery and performance issues that their executives were proactively causing.
What's going on here?
My educational and professional background is deeply technical. Early in my career I could have easily been sitting where our hapless CTO sat. As a tech geek, the intersection of finance, accounting, development, and operations aren’t exactly our thing.
I truly became an effective technologist only after about five years into my first post-college technical role. That's when I realized the operational influence of the financial and economic realities on the technical demands.
At the risk of hearing the “I told you so's” from my finance friends, this connection opened up an entire universe of possibilities for me and my future clients.
I became obsessed with all angles of operational performance—not just technical prowess or product excellence. Doing so demanded that I gain a strong appreciation for the economics of value. Both internally and to customers. I dove deep into the connection between value-delivery (“operations”) and finance, well beyond just building desired products efficiently.
Having a clear understanding of whether your organization is product or services focused is a “do not pass ‘Go’ do not collect $200”© moment. Unless you nail that down, you can’t run and scale your company effectively.
Making the Distinction Between Product Companies and Services Companies
The difference between product and services companies doesn’t just mean that one company sells a service, and another sells some kind of widget.
It’s so much more, including the economics of the work. Is the work a cost to minimize or an investment to maximize? Do you measure performance objectives in terms of efficiency (taking the least amount of time or money) or effectiveness (putting the greatest distance between you and the competition in the most impactful way)? Each of these affect how you scale, how you deliver, and what you spend money on.
A services company makes money and scales by selling staff time to customers. The clock is on when the value is being provided and off when it’s not. This nearly always involves leveraging a company’s know-how. Though the work might result in a “product” that’s “delivered,” getting to that product and how much it costs is a direct function of how much time it takes. Very often the value is only experienced by the customer while the work is happening. (Think: hair dresser, Lyft, kitchen remodeling.)
Typically, service companies clearly see they’re a service company. They intrinsically understand that more time and more people equals more money. The key for service company success is leveraging capabilities to maximize efficiency. Use as little of your people’s time as possible and charge as much as you can for that time. When they run out of time, bring on more people.
This is also true for non-customer-facing services such as internal IT departments. Keeping costs down is critical to profitability. Internal IT departments are accounted for as cost centers; keeping costs down directly translates into business performance. This is often done by standardizing processes, bringing in tools and automation for efficiencies, and deploying systems internally and to end-users to minimize time-consuming real-time interactions.
Product companies need to invest in research, plus all the people, systems, and processes necessary to build and sell something at a price point commensurate with the expected sales volume and market value.
Saving money creating the product plays less of a role in product companies (or it should). No one at Apple is saying, "spend less time on making it functional and beautiful."
The point of money in a product company is to invest it and recover the investment in selling the product. Where services are cost centers and use appropriate accounting, processes, and policies to keep costs down, product companies are supposed to be profit centers. Their economics use accounting, processes, and policies appropriate for maximizing money made through sales.
When you’re not clear on what your company is, bad things happen:
Juxtaposing or mixing the two creates performance and delivery issues, including:
Using the same people for product innovation and development on providing services robs both efforts of the time and attention needed to do either well.
Short-changing non-recurring engineering time (leveraged time) to make time for real-time services (linear time). The economics are on different sides of the balance sheet.
Constantly changing product requirements based on service requests, constantly forcing product delays, slowing deliveries of products to all customers, and slowing new customer acquisition. Called "requirements volatility" in the biz, gives chills to everyone in the know.
Creating more product versions (too many customer-specific installations) than can be supported. This problem alone spawns too many additional problems to list here.
Using service delivery performance to measure product development metrics and vice-versa (assuming any useful measures are used at all, of course). This leads to more economic superpositions, for example: an appropriate service metric could be how many hours are spent on fulfilling a customer request compared to the hours allocated to that customer—as this is directly proportional to profit, but a product developer measured on how long it takes to figure out a solution to a complex problem may have technical ramifications but not directly tied profit.
It’s doesn’t have to be one or the other – but the lines need to be clear
Let’s not interpret this cautionary tale to suggest that a company can’t be building and selling products as well as providing services. It’s OK to be both a product company and a services company. The economics of products are different from services and so are the operating models. The product side and the services side must be just that: two sides. Conflating them leads to performance problems across the board.
If you’re thinking your performance might be suffering from a blurring of the product vs. services line, Entinex can help. Together, we’ll explore the details and clarify if and where your company is a product company and where it’s a service company. Once we get things clear, we’ll set you up for faster sales, better growth, increased cash flow, improved customer relations, and more innovative products delivered more frequently.
I’m always happy to talk about these sorts of things. Like I said, I’m a geek for it.
Email me at firstname.lastname@example.org.
EPILOGUE: Whatever happened to our hapless CTO?
They left after not too long to a company that knew what it was doing: building a product
and they were deliriously happy.