Are we building SaaS products the wrong way?
I recently attended a conference where one of the themes was digital customer success. Attendees were implored to adopt a digital first strategy for all customers, backed up with a human touch when needed. Digital first; human first was the mantra.
An early part of what most companies do when delivering different aspects of scale often involves adding a new product into the tech stack, which as a result grow like topsy. It’s become big business with an increasing number of add-on products: app telemetry, in-app messaging, surveys, customer education, onboarding, community …. the list continues to grow. I recognise that these are all important capabilities but the more I heard, the more I thought about the approach most are taking. This tech first approach is often the result of fragmented, inside-out thinking. Product/platform accretion is not only costly, it often creates a fragmented user experience with different logins and interfaces. It also significantly complicates the challenge of building a comprehensive customer data model; the all important single customers view. Whilst end customers may achieve some benefit, much of this is vendor, not customer driven.
The more I thought about this issue, the more I revisited a thought thread I have had for many years. Here’s how it goes.
B2B SaaS companies are product companies.
Whilst often supportive of growth, service revenues attract lower multiples than product revenues.
The biggest driver of retention and growth is the measurable results key customer roles achieve.
The product should be the primary vehicle for delivering measurable results.
The product should be built around the process of delivering measurable results for key customer roles.
Ergo, the product is the vehicle to deliver digital customer success!
Rather than invest in a multitude of disparate third party platforms, I have long advocated for product-led customer success; I published an e-book on the subject back in 2016. The e-book grew out of a conversation with a CEO of a company I was advising. In 2015, my client asked about how the company could scale CS massively and for thoughts on the number of CSMs needed for the following financial year. After some thought, my answer was along the lines “I’ll give you back three CSMs in return for five software engineers. I had sketched out in Balsamiq (a wire frame product design tool) what an in-app success process would look like. Whilst some third party telemetry products were part of the design, the core of what was proposed was product-based; built in-house. I calculated that the investment paid off in 18 months and generated growing margins as the number of customers scaled. Code sales better than people!
I am not against using third party products: make or buy is always an important consideration when building capabilities. If third party products are to be employed they must meet the following criteria of outside-in, customer-led design:
They are delivered in-product.
As far as the user is concerned, they are using your product. No need to login or get used to a different interface.
The capability and when it is offered is entirely in context: specifically related to what the user is trying to achieve.
The data they generate is fully integrated into the product and customer data model.
Few that I have seen meet these criteria.
Of course, much has changed in the seven years since I first explored product-led customer success, not least technology capabilities, accelerated by the recent developments in AI. Fundamentally however, the idea is the same: your product should be designed around what key customer want to achieve. I call them achievement paths.
Here’s what an achievement path looks like in an AI enabled world.
Discovery: Identification of the key role specific pain/gain point the user wants to address and their maturity in that capability.
Goal-setting: Suggested goals for the metrics that measure that pain/gain guided by AI driven maturity models. New or increased goals can be set at any time.
Next best value: Contextually specific interventions and guidance on how to use the product and the business changes needed to address that pain/gain and achieve the goal.
Progress reporting: Role specific dashboards that track progress to goals, preferably driven by data from your or an integrated product. This should include notifications to non-users, especially the decision makers, with a summary of corrective actions needed if applicable.
Achievement paths are the way new users initially use the product. As their experience grows, they will increasingly go direct to the features they want: familiarity breeds competence. They always however have access to achievement paths and particularly to progress (results) reporting. This is not how most product teams currently think. They are constantly searching for and adding new features rather than explicitly focusing on how users achieve measurable results in the challenges they face and the results they are measured on. The focus is too often on adoption, not customer results. That’s an important distinction as high adoption doing the wrong things or doing the right things badly will rarely deliver the results customers need to justify renewal and growth. It may be their failing but your product will probably get the blame.
Focusing on achieving product-led results achievement needs a shift in how we prioritise activities on our roadmaps. The question is not which features are most requested but what developments enable the greatest number of customers to achieve the biggest improvements in the metrics that matter to them. I use a simple 2x2 matrix to think about roadmap priorities.
The grid forces a focus on what is going to deliver results for the customer AND the company. It’s not an either-or choice.
Results for the customer is a ranking, based on your detailed knowledge of what matters most to each role and how they measure it. If you know how customers measure success, and you must, then this an aggregate of the potential improvement multiplied by the number of customers with that goal.
The interesting quadrant is high customer results; low revenue potential. If it is delivering for customers, it must have value to the company.
This requires thought about how this capability can be monetised: if it delivers results for customers, the right pricing and packaging should unlock revenue. Think about the impact on retention, growth and advocacy as lifetime value may benefit significantly from the capabilities in this quadrant.
My ebook from 2016 included this maturity model for product-led customer success. Back then, there were a few B2B SaaS products operating at Levels 1-2. The advent of product-led growth has increased that and I now see many, but still a minority, operating at 3-4 yet still nothing at level 5.
I suspect the rate of change will accelerate; driven by a greater understanding of the importance of customer results for growth. the increase in understanding of product-led approaches and the advent of generative AI.
At least that is my hope!
Not all companies are falling in to the trap of scale by product accretion. One of my favourite companies, Hubspot, use third party products but almost everything I have seen and experienced (I am a customer) is product-based; i.e. accessed in-app. They are increasingly focused on measurable results for key customer roles as the driver for interventions; although they are not quite there yet in this regard.
The next time your product managers ask you what should be on the roadmap, tell them you don’t want any new features. Tell them you want to build a number of achievement paths to make it much easier for customers to improve their results by using the product better and making the changes they need in how they work. Tell them the payoff will be a significant improvement in retention and a significant competitive advantage. Expect to have to repeat yourself several times!