Creating Service-Based Software:
Or Don’t
I’ve built software products for two kinds of companies: The first is a standard software company, a product company. This is straightforward: You create software and someone uses it, and they pay you to use it.
The second kind of company is a service company that seeks to be a software/service hybrid. Maybe it’s a company that started out as a service company but wants to be a software company, or at least be valued like a software company. With these types of companies, there’s a customer need but fulfilling that need requires a very complex and ambiguous process. Hence, the company uses a service to fulfill it.
The challenge with the service company is getting the service to scale — if the company sells more services, the company needs to hire more people, and the marginal costs go up. On the other hand, if this was software there would be no impact to marginal costs, so someone thinks, “let’s use software in place of our service.”
As I started off saying, I’ve witnessed this multiple times, and I’m going to talk through where I’ve seen things go wrong — where the common assumptions and misconceptions plague efforts to create a software company from a service company. Then, I’ll walk through my view on how a company could possibly move from a service company to a software company.
First, some advice… don’t do it.
Before I talk about building a service-based product, first a word of advice: Don’t do this.
Seriously, if you have the ability to do option one (build and sell software), do that. Focus on getting the software right. Even if it’s a complex process or a difficult problem. Try focusing on one part of the problem, a single use case, and just get that right. Then build from there.
In most cases, that’s a better strategy in the long run because you’ll build better software. You won’t have another option. If the software doesn’t work or if there’s a missing use case, you have to deliberately decide whether to build it or hack it. Maybe you can do some sort of manual process in the background to meet a specific customer need, but that’s understood as an exception. The focus is on software, and every manual process will have to get removed.
But maybe you have to…
Okay, I’ve tried talking you out of it, but maybe it’s too late. Maybe those few manual processes have graduated from an exception to a function — what was a task someone has done, now has become someone’s job. Congratulations! You have a service function now! Likely it starts with the word “customer” followed by an “s” word: “solutions,” “success,” “support,” or “services.” Let’s call them CS. And if those people “drive a function of revenue,” well, congratulations! You’re a service company!
So, this happened. Probably, it didn’t happen when you were there. As has been my experience, you’re brought in as a product hire to help make this service into a software product.
so, you’ll start the way everyone does…
The first time I went through this process, I was a head of product for a software/services startup. When I was hired, there was already a head of UX who had done the herculean job of trying to define the service — making it time bound, mapping out the interactions, and creating a true process to be followed.
You will start with Designing the System and Processes
This is how it will start: a process design. It will look like a business process diagram, a service diagram, or some other UX artifact. And, you’ll work from there.
At the software/services startup that I mentioned, we put a huge process diagram on the wall. It was massive. Every interaction that the product automated was there for everyone to see. And as we were asked for alterations to the product — additions and refinements — we would change the diagram.
But there were challenges with this: the service kept changing. Although we made everything a series of configurations, the services team would inevitably start trying something new, something that the sales team thought up on a call, and something that wasn’t configurable: A new deliverable. A different way to have the interaction. Something that was completely unaccounted for.
About 20 months after I started at the software/services startup, I presented the work we had done and the challenges to a product Meetup. The room was filled with almost 100 earnest product professionals of all experience levels. I sat at the front of the room and discussed the product, the processes we had built, and the challenges we had with trying to productize a service.
I was looking to tap the collective wisdom of these product professionals. I was hoping for inspiration, a novel idea, or some weird wild-ass thing to try. Instead, I got more of the same:
- Create more standards for the service
- Design the process
- Agree to the standards
- Build the product from the standards
I left that meeting realizing that everyone was telling me to do exactly what we were doing. The problem was that it wasn’t getting us the results we needed fast enough. The process kept changing. Sales kept selling different versions of the service, and there was simply a ton of variation in the way each service person did their job. You could put everyone in a room, they’d all agree to the standards, and then they’d leave and change everything.
A few months later, I left and went to a traditional software company — one that sold software for money.
But, the assumption is wrong.
The approach to standardize the process and build from the standard is Product 101; it’s what everyone at that Meetup advocated. So, why doesn’t it work?
You start with the model…
As everyone in the meetup said, you are going to start with a design, a diagram, and agreed upon standard — whatever that format is. Maybe you’ve interviewed the team and talked to them about “how they do it today.” You’ve taken notes. You’ve shown them diagrams of the process. They’ve commented on them and made suggestions. You’ve agreed and aligned.
So, in this model, you and the team refine the standard The customer service/success/support/solutions (CS) person bases their delivery on the standard. The CS person and the customer have a service interaction, and the *customer uses the software later on.
You use this framework to launch: The product, design, and engineering teams are agreeing on standards, looking at software, and getting feedback. Ideally, they are getting feedback from the customers, but maybe it’s just the CS folks for now.
…but something is wrong…
But once launched, that feedback will be harsh. The feedback is that the software doesn’t do it the way they do. The software is too limiting. The software is built on invalid assumptions. The software, in short, is not as good as the service, and so the service fills in the gaps.
In order to “fix” the software, more interviews happen. More things are revealed. Assumptions made about service agreements are reexamined because it turns out they weren’t entirely accurate. The “standards” weren’t standard. Everyone did it a little bit differently. Every client asked for something a little bit different, and sales sold each client on something a little bit different. And all of those differences weren’t even agreed upon parameters in the software, so now the team has to decide whether to do a whole refactoring job on the architecture. And, in the meantime, the service has changed, so all of the standards need to be updated anyway. It’s just as well.
…so you do it again.
This was once through the loop. I went through this loop several times at the software/service company. I went through this loop several times before the scores of product professionals at a Meetup told me to “standardize the process,” which is what we were doing. Why was this advice wrong?
Here are three reasons:
1. The service cannot be dictated to you — it will be generalized
First, the assumption is that you can capture everything from conversations with a CS person and put it in whatever diagram you create. But, what happens is that the service CS person has so many interactions with the customer that they can’t recount everyone. They are making a generalization based on their memory and their perception, and you are basing your standardization on that generalization. They are telling you how they think the service works as they see themselves doing it.
You have to treat this as any other research problem and realize that even these people — your colleagues — are presenting you a world as they see it, and maybe that’s not how it even is
2. The CS person’s job is to deliver great service, not the standard
What’s more, the CS person’s job isn’t to get the standard right. Often, it isn’t even to abide by the standard. Their job is to deliver great service, to make the customer happy, get them to renew. If the standard or the software puts a blocker in their way, they will go around it — and they might not even tell you about it. Especially, if you tell them to abide by the standard but measure their success on renewals.
3. The service changes more frequently than the standard ever can
And because the CS person’s success is measured on revenue or renewals, they will alter a standard to make it work for a customer. If the agreed upon interaction is a certain timeframe, but the customer needs twice as many for half the time, well, the CS person will do it. If the customer needs the CS person to log the information into the software, the CS person will do it. The CS person will do whatever they can to make the customer happy — including using their creativity . . . which will defy any previously agreed upon standard process.
Look at those three systemic issues, and you notice that this project handled in this way is doomed to fail. So what’s the alternative?
Focus on understanding the service.
At the software/service company, there was one item we did do that gave us unexpected results — we started recording the interactions. Not all of them. Some of them. We recorded the calls and got transcripts. And what we found out was eye opening.
From the sheer data it was clear something was off: the customer was supposed to ask questions and then listen to answers, but when we looked at the data, the customer was talking upwards of 70% of the time.
Additionally, we had always assumed that the customers knew what questions to ask — what value they were looking for. But, when we looked at the transcripts, it was clear that the customer had no idea what they were looking to get out of the service — and that meant the other participant needed to steer them with questions. Hence, the customer doing most of the talking, and the other participant seeing where they could be helpful.
This was huge. One of our core assumptions was flawed. And, more importantly, no one told us about this in a feedback session.
Anyone who has done any customer research knows that there are insights people generally don’t share — things like doubt, confusion, apathy, and ignorance. Whether for shame or overcompensation or bias, people generally want to present themselves differently than how they act, and so that’s why this point is key: the most important thing you can do in developing a service-based product is record and analyze every part of the service interaction.
Build what you record, and then break it.
Rather than designing a process based on different people’s perspective of what they believe the service should be, look at what it is. Detail and interrogate the interactions.
Take a meeting between a CS person and a customer, for example. What’s going on in the meeting? Well, it’s a time set aside to exchange information. But also, it might be the only time that the customer is thinking about this issue. And, the CS person isn’t just exchanging information, but they are also adding social pressure to do a task laced with the pleasantries of a trained service professional. And, all that’s before you get to the actual content being shared.
As you analyze the recordings / the artifacts / the data — you will learn the true challenge behind the service. You may even figure out what the service can’t do. And, that’s what you should build.
The job of the software should never be to “automate the service.” That is for people who think that the future will be Rosey the Robot Maid on the Jetson’s. It helps the future fit their mental model, but we have seen the future. It’s not one robot that does all the things–it’s a series of products that do specific things. Rather than Rosey, we got Roomba for vacuuming and smart appliances that hook into a voice assistant. We got several small things that do all the jobs of the one service.
Build the software as an alternative to the service. . .
Once you have a near complete set of features that replace the core service offering, you can offer them bundled as an alternative to the true service. The software should be a lower cost alternative — one that can still get marginal profits, even if you have to offer them an incentive in the short term to use the alternative.
Providing the software as an alternative helps to understand if customers will actually switch. There will always be customers who want service. They think depend on the person. They like the meetings with a human on the other end of the call. But, as many of us have seen as we move to AI tools that have replaced translators and editors, sometimes, we are okay moving over if we get other benefits — like speed.
And make sure everyone is on the same page
Underlying the challenge in the service-based product or a software / service hybrid are misaligned incentives. Remember the standardization scenario above? Remember the players? Sales. CS. Product and Engineering. Now, ask yourself, how are these people incentivized? What are their goals?
In thinking through this well-worn scenario, everyone misses that the sales and CS folk have revenue targets — goals on acquiring and retaining customers. And if there are things that are fungible that the customer asks for, they will provide it. That’s their job. That’s the reason they were hired. They provide great service.
But, what of the Product and Engineering folks? Often, the revenue goal is distant for them. Rather, they are focused on scale, usage, and customer happiness. They are trying to optimize the product being built–even if the customer is not getting everything they ask for while the product is under construction.
These misaligned incentives are at the core of why building a service-based product is often doomed — it’s why I’ve seen it go off the rails more than once.
At the heart of it, building a service-based product should not be an endeavor for a product and engineering only — it should be endorsed, shared, and incentivized across the entire company — those CS folks.
Ultimately, if the incentives stay misaligned, the company will become a service company. The easy way to see this is to examine those gross margins. Anything below a 70% gross margin that calls itself a “software company” is likely a pile of misaligned expectations from the leadership that will eventually bubble up to the board and investors. And with the investing climate of late 2022, there’s probably less patience to wait for the software to catch up to the service. More likely, the company will go through the loops I describe above.
It’s better to call it out from the beginning and understand how this journey will go — a journey of discovery, building, and creating alternatives.
