Using leading indicators to increase iteration velocity and customer satisfaction
This post is sponsored by Bucket. Bucket provides feature flagging with built-in customer feedback to let B2B product teams increase iteration velocity and customer satisfaction. In addition to feature and permissions management, Bucket automatically collects leading indicators for every feature as soon as it’s released.
Many engineering teams are rightly told to focus on outcome over output. The outcomes are business results and the outputs are product updates that drive those results.
Most product updates should have a clear outcome. As Josh Seiden puts it, outputs are meant to “create a change in user behavior that leads to a business outcome.”
He uses a mattress store as an example:
A mattress store wants to sell more mattresses.
To achieve this outcome, they need customers to come to the store and try the mattresses since nobody buys a mattress without testing it first.
To make that happen, they place the mattresses so they’re easy to lie on, they cover part of it in plastic to keep them clean, and they place signs encouraging customers to try the mattresses. These are the outputs that are meant to drive the outcome.
Output: Make it easier to test a mattress.
Outcome: Sell more mattresses.
In the context of B2B SaaS, a better example is a tool with seat-based pricing. As a business, you want to sell more seats. To do that, you need outputs that encourage collaboration and create the need for customers to invite coworkers.
Focusing on outcomes over outputs is a great framework to ensure that engineering teams think about delivering value, not just features. That’s because software engineers create value by shipping code that solves pain points for users. If you can’t tie a customer pain and a business outcome to a feature, you should reconsider if it’s a priority.
There are exceptions, of course, like refactoring stuff. However, for most updates, it’s best to have a clear outcome in mind.
But, there’s a problem with outcome-driven product development: The feedback loop is slow.
Outcomes are lagging indicators that change very slowly.
For example, if you release an update to increase collaboration, it will take a long time to measure and evaluate its impact on the average number of seats per account.
This leads to two problems:
Using the example above, the collaboration feature you released may not actually address customers' collaboration needs or the UX could be confusing.
While you are waiting on the outcome (lagging) metrics, customers are becoming increasingly dissatisfied with the update. It’s not uncommon either. More than 50% of features fail to have any customer impact in their first iteration.While the feature you just shipped is being evaluated, the team is reassigned to new projects while past update fades from their minds. The impact of this is underappreciated.
Once a team is on to the next thing, the importance of previous releases declines, and the technical context is greatly reduced. Bringing that contextual code knowledge back later is a slow process, making future iterations more expensive.
As a product engineering team, one of the ways to create value quickly is to shorten the feedback loop as much as possible. The shorter your feedback loop, the quicker you’ll know whether you’re building something that truly serves your users.
In the B2B space, the challenge is that feedback tends to be longer and more qualitative, often involving closer interaction with users, champions, or customers. This type of feedback usually requires more in-depth engagement and collaboration, naturally taking longer compared to the more quantitative feedback typical in B2C settings.
Let me share a story from my own experience. A few years ago, I was working on a B2B application, focused on alleviating the pain points users faced with our document management system. We decided to develop a feature that would allow users to effortlessly migrate their folders to our platform in just two clicks. We were convinced this would significantly boost our customers' efficiency. To make this possible, we had to rewrite a key component of our system.
A week after launching, we eagerly awaited feedback from our major customers. But instead of excitement, we heard... nothing. It wasn’t until we were providing third-level support to one of our biggest clients that we discovered the problem: the shiny new feature we were so excited about didn’t even display for them! The culprit? They were using our app on Internet Explorer 8, which wasn’t compatible with the library we used for the rewrite.
If we wanted to catch issues like this faster, what we needed was leading indicators.
Getting ahead of it with leading indicators
When a release goes out, there are plenty of signals you can use to gauge satisfaction.
Are customers adopting it? Do they keep using it? What do they say about it? Are they satisfied with it?
That’s where leading indicators come in.
A leading indicator is a data point that immediately signals the likelihood of feature success (the output) and, subsequently, the likelihood of achieving the associated business outcomes.
Going back to the example, if customers are dissatisfied with a collaboration feature, it’s unlikely that they’ll invite co-workers (which was the desired outcome).
Catching that leading indicator in the days after the initial release gives you an opportunity to convert dissatisfied customers into satisfied customers by iterating quickly.
Acting fast has several benefits:
You still have the momentum and context, meaning iteration times are shorter.
The customers are heard and impressed by the quick turnaround, building trust in the product and the team behind it which increases retention over time.
The team has gained 27 days by catching and fixing issues on day 3 rather than on day 30 or later when the lagging metrics become available.
The team avoids any potential false positives, like seeing an increase in collaboration in the metrics while being unaware of the widespread dissatisfaction. When left unaddressed, this bad experience with the product can lead to account churn.
So, what leading indicators should product teams be tracking?
Outside of technical performance indicators, here are six leading indicators to track:
The bottom line is with these indicators, you can greatly improve how you work. These indicators empower you to take action sooner instead of waiting for the lagging metrics to surface. You get the insights and context you need to take advantage of the momentum you already have to make a larger impact in your organisation and ensure the features you’re working on are actually used and enjoyed by users.