Running services business can feel like a grind. Balancing healthy client and talent pipelines is a never-ending battle, and it’s hard to decouple revenue from headcount or utilization. Once you’ve had some success in the services world, it’s logical to look over at software businesses, with their seemingly infinite scalability, and want to get in on the action.
Investing free cash flow from a services business into a software business is a very common practice for a reason - on paper, it looks like an easy way to achieve the scalability consulting lacks, while escaping the grind that consulting comes with.
The reality isn’t always so pretty - countless consulting businesses have set piles of money on fire trying to build software businesses. Over the last few years, I’ve worked with several consulting companies helping them build software products, and seen firsthand what works and what doesn’t. My conclusion so far: it’s a viable strategy, but there are several traps to look out for to maximize the chances of success.
Organizational and business model misalignment
The biggest challenge for consulting businesses building software is the introduction of a new business model and approach to “product development”. An organization optimized to sell services focuses on different metrics and objectives than those required to build software effectively, which can create some uncomfortable tensions.
An example I’ve seen in practice: Often, your consultants are a wealth of knowledge for your product, but they can’t bill hours to product development. This means that any time spent on helping develop the product has to come out of billable hours, which is often a key metric for consultant success. Effectively, consultant KPIs are at odds with the business’ broader objective of building a software product.
Another example of this tension of business models: Software products often require significant upfront investment before starting to generate cash, while services businesses can be profitable from day one. I’ve seen software projects die in consulting organizations because leadership is measuring the project’s financial performance like a services business. This impatience for profits can stop successful software projects before they are able to show scalability and profitability.
Combatting this tension of business models can be quite challenging, but here are a few tactics I’ve seen work:
Layers between builders and users
In many cases, software products in consulting organizations may be “delivered” to consulting clients via consultants. As an example, a consultancy might build a software to automate client reporting on a government regulation, but the consultants will configure the tool for a specific client engagement, and then use the tool to present results to the client.
While this may be a valid model for delivery, I’ve seen teams following this model fall into the trap of using a similar model for user research and product development - letting consultants be the point of contact with users, and relying on them to relay insights back to the software development team.
I’ve already outlined the issues with layers between users and software builders in more detail in this post, and the same issues apply here. Consultants are often not trained in user research techniques, and therefore may not be reliable researchers or communicators in the product development process. Letting those who deliver the services also do the user research risks a biased understanding of users, leading to products that don’t get used.
Another related version of this problem is a hubris when it comes to user research in consulting organizations. As the logic goes, if we’ve worked with a type of client many times in a consulting context, we should already have an intimate understanding of what they need and have no need for future user research when building a software product. While it’s likely true that strong insights are already there, a software product is a new kind of service, and usually requires a different angle in user research. Just relying on insights from past consulting work risks software teams having major blind spots.
Avoiding this pitfall starts with getting trained user researchers directly in regular contact with users. Otherwise, it’s about building a culture of user research within the organization, which I’ve written about in depth here.
Is it for consultants or our clients?
There are two common strategies for building software in consulting organizations - building a tool that enables consultants to be more effective, efficient, and/or differentiated in serving clients, or building a tool to serve the organization’s clients directly, in a way that is complementary or replaces some consulting services.
Both approaches are valid, but the strategy must be clear from the start. I’ve seen projects that lack certainty about the end user (is it the consultant or our clients?), leading to a messy development process and tepid outcomes. This lack of certainty often comes from leadership feeling that they need to hedge their bets - the lack of familiarity with software ROI time horizons can push decision makers to look to building for internal users (perceived as a clearer path to value) instead of, or in addition to, external users. Leadership of service businesses can also have inherent discomfort with selling to clients, as they may perceive (rightly or wrongly) a risk of cannibalizing their consulting business.
The solution here is simple, but easier said then done: set a clear vision up front on who the singular end user of the product is, and stick to it unless data proves otherwise. Don’t try and start building for two user groups at once!
An alternative approach
I’ll end with a success story - Tiny, a publicly-traded conglomerate of internet businesses worth hundreds of millions, was started from the profits of a services business - Metalab. The approach that worked for them was completely different than what I’ve described above. After spending tens of millions trying to build software internally and failing, they found success acquiring software companies with complementary, but distinct end users (for example, after running a well-known design agency for many years, they acquired the largest social network for designers, Dribbble).
Tiny is an example of creating amazing value out of the profits from a services business, but they surely learned some of the same lessons I laid out above the hard way.
If you’re interested in chatting more about service businesses building software, or interested in understanding how your service business could build software, I’m always up for a chat! Feel free to reach out on LinkedIn or email.