Products vs services: biotech edition

Over the years at Kaleidoscope, we’ve noticed a quirk in biotech and pharma companies that often surprises people not familiar with the industry: full time employee (FTE) and service expenses can be much easier to approve than software expenses. In this post, we discuss some reasons why.

Budget decisions have always been influenced by the way expenses are categorized. Traditionally, software budgets fall under CapEx, and labor budgets like FTE salaries and service fees are captured under OpEx (although cloud and SaaS models have made this a lot more fluid). As we’ve built Kaleidoscope and had more open conversations with both software buyers and sellers in the space, it’s been interesting to see how much smoother it seems for labor budgets to be approved, and just how much this can shape the way founders selling to bio and pharma position their companies and their competition.

Taking a step back, the battle to cut costs is intense across bio right now. SVB’s collapse last year (and the market conditions preceding this) triggered a dramatic domino effect of layoffs in the space that sadly seem to be spilling over into this year. Just the other week, Allakos, Dewpoint, Bayer, PMV and Ikena made big, big cuts to their workforces and – as a result of this wave of labor casualties – new ways of scrutinizing expenses are, in the words of the WSJ, “gaining clout.” For example, there’s been a big push in Pharma towards zero-based budgeting, which puts the onus on managers to justify every new and old recurring expense periodically (i.e. they must start from zero every quarter or year). 

Regardless of which budgeting method bio companies move towards, the underlying theme is the same: scrutiny. Scrutiny of purchases, scrutiny of the people making them. But if this scrutiny is being applied equally to software and FTEs or services (case in point: layoffs), why do stakeholders seem more prepared to justify one over the over? Because buying software is scarier than hiring.

There are some things in life that are fun to buy, and B2B software is not one of them. Most of the things we love shopping for are low-stake decisions where, if we make a poor choice, there aren’t many consequences. If you buy some chips at the grocery store that don't taste good, you can just decide not to buy them again. For B2B software, it’s a completely different story – enterprise tools are complex pieces of software that require careful and deliberate thought to understand, and the decision to use these tools can impact many people. If I make a poor software purchase, bad things can happen for the company and for me personally, as the buyer who convinced everyone to make the purchase. 

This is compounded by the fact that, for a lot of B2B software, the ‘magic’ moment, or return on investment, isn’t felt immediately. It can take a while to implement and get used to any new tool that’s tackling team-wide workflows, and (warranted) attitudes of ‘why do we have to add another tool to our lives’ can add to the friction. This gap between buying software and seeing the results can be stressful for the buyer, who may feel like they’re getting blamed for introducing a new tool that didn’t immediately make things smoother or easier for everyone else. 

On the other hand, an employee or a service is tangible. You can physically see that they’re there, that they’re working, and this gives companies the assurance that they’re making progress towards easing their pain points, even if that’s not always the case (i.e. throwing more people at a problem often doesn’t work or can be more expensive).  Employees are also more fungible than tools. People can be moved around or swapped into different roles and focus areas in a way that software can’t. You buy a tool for a specific purpose, and if your priorities change the next quarter, that tool does not magically change to reflect that.

Then, there’s the learning curve of hiring employees vs. using software. Once you’ve put in a few reps at hiring and integrating employees into your team, the process becomes much more streamlined and repeatable. Your experience onboarding the n+1th hire is not going to be materially different than your experience with the nth hire. That predictability doesn’t exist with software; each new tool you bring on could be a fundamentally different experience or process than the last.

So, what does this quirk mean for founders selling into bio/pharma? That it could be an easier sell if they position their companies as providing services instead of products. 

We met a founder recently who was building in the healthcare automation space. After a few months of selling into speciality practices, he noticed the same quirk and immediately repositioned his narrative to be a services company (i.e. we build and maintain automations for you as a service). As a result, he also repositioned his competition. Rather than competing with the hundreds of other automation tools and software budgets, this founder was now competing with labor budgets – and he leaned heavily into this. He came up with a list of job roles for each speciality that did manual, admin work his company could automate away, and calculated the amount of hours it took each person each day to do that work, and the cost of each hour of labor. From this, he had a strong way of calculating labor-based RoI for each clinic that, against the backdrop of labor shortages in the healthcare admin world, was incredibly compelling for buyers. Much more compelling than throwing up a quadrant of 20 other automation companies and putting his own logo in the top-right corner. 

At Kaleidoscope, we’ve also noticed that certain things we do are thought of as services rather than software. Things like walking someone through onboarding (although we have productized self-serve flows), helping with initial data import or integrations set up, education around best practices – whether that’s customers asking for our advice on option A vs. option B for other parts of their toolkit (e.g. cloud providers), or education around how to best leverage Kaleidoscope. 

The way we see it, these services are a natural need for any buyer who is implementing B2B software top-down. Implementing a new tool can feel like a big change, and people need support. We’re cautious about accounting for these needs by being very intentional with how we engage with our customers, like making onboarding a co-operative activity, or maintaining ongoing touch-points. For example, every customer we work with gets something akin to a forward-deployed team from Kaleidoscope, which includes a scientist, engineer and product point of contact, to jump in and help if needed. 

However, we’ve stayed away from positioning Kaleidoscope as a services company. 

Although it could make selling and budget approval easier, the question of repositioning an entire company from software to services carries big implications and should be a much more intentional, strategic decision. It’s a decision that fundamentally changes the nature of your business model, how you engage with your customers, and what their expectations of you are. 

Ultimately, if someone is buying services, your focus is not about getting them set up and running in a software tool. Instead, the baseline assumptions of you as the provider change: higher levels of hands-on customization, a high-touch 1:1 relationship that dynamically evolves with  needs, and a commitment to meeting those needs consistently. You become the interface through which the customer achieves their goals, rather than a piece of software. This shift impacts everything you do as a business. Your sales approach is different, the make-up and size of your team is different, your own expenses are allocated differently, and you have to be comfortable with scaling at a drastically different pace than if you were building a product company. 

The founder we mentioned above is a great example of this. He didn’t just reposition his company as a marketing play; he restructured his entire business and roadmap around his decision to build a services company. Rather than the pure SaaS play he set out to build, what he’s currently building is comparable to the ServiceNow ecosystem, where  there’s a whole network of independent partners that exist to implement ServiceNow’s solutions into enterprise companies. This trickles down into the day-to-day decisions this founder has to make, like making sure he’s hiring enough Solution Architects to build and maintain his customers’ workflows, and figuring out if he wants to train independent solution architects to implement his product for wider reach.

At Kaleidoscope, our approach is a more moderate one of layering services on top of a product. We’re taking a customer-centric approach to building a software tool, and this means giving our customers a lot of support and guidance for trusting our platform, setting themselves up for success, and advocating for us internally. It’s about pairing a beautiful product experience that empowers teams to be self-sufficient, with human capital that gets them there in the smoothest and most efficient way possible. Although it might be tempting to try to take advantage of the labor budget loophole, if our goal was to be a true services company, we would be building very different things with our internal engineering and product expertise than we are today.

So, in the question of product vs. service, think carefully about what you want to be as a company, and build accordingly. If you’re building something people need, sales will click into place whether you’re a product or a service.

If you want to chat more about anything we wrote, or you’re interested in finding a way to work together, let us know!