The bucket going down the quantitative well almost always comes up full. But what’s worth asking, though, as Scribe’s co-founder and CEO, Jennifer Smith (@Scribeceo) does: is it always valuable?
As they searched for a system of product prioritization, they learned that the popular, “formulaic” RICE framework fell considerably short. And “product development became an estimation exercise that felt distant from the users.”
In the following exchange, Jennifer writes about adopting the more “humanistic” Kano model, which has become a markedly better gauge for what users really care for.
— The org-wide, user-obsessed mindset shift that the Kano model brought about
— What that shift has meant in practice
— Why this model isn’t for everyone
“In our perspective, numbers should follow rather than lead”
At Scribe we use the Kano model to guide our product direction. Essentially, we ask ourselves “what would surprise and delight our customers the most?” It’s a balance between including the “must have” features necessary for functionality and identifying those delighters. We want our customers to be as excited about Scribe as we are.
We have to be very mindful and particular about the decisions we make, many of which are based on intuition as much as research. We call it “Building for User Love.”
We started getting a lot of feature requests. In some ways it was great — it showed our customers were invested — but it ventured beyond what we could feasibly build all at once. The team realized we needed a prioritization framework.
Before we settled on Kano, we actually tried a model called RICE (Reach, Impact, Confidence, Effort), which is much more quantitative. It’s an excellent framework, but wasn’t quite the fit for us.
We wanted something inspiring and generative so that we could continue delivering meaningful features to our users. In our research we saw that Kano has led product-led businesses to success before, and so we gave it a shot.
With RICE, product development became an estimation exercise that felt distant from the users. At Scribe, we’re much better versed to talk in terms of user stories.
In our perspective, numbers should follow rather than lead.
Unlike RICE, the Kano model has a fundamentally humanistic view. We shifted our mindset from “this is the number of people we can reach” to “What do we all share? What can this project be a part of?”
We had to reconcile that we were now looking at completely different metrics. RICE is formulaic. When you say “reach,” or demand, you’re thinking, how many people will I reach in this time frame.
With Kano, reach really mostly pertains to the “must have” and “little more, little better.” That reach is implied because you have a target audience in mind. With “surprise and delight,” you’re dealing with emotions, and for the most part, that’s universal.
Of course we have targets, of course we celebrate growth, but we are primarily focused on our ability to generate that thrilling experience for as many people as possible.
As far as “impact,” there was always room for that to be qualitative. It just depends on what you prioritize. ‘Am I monitoring conversions, or am I monitoring delight?’ We chose the latter, and while it can be tough to track in hard numbers, it’s often clear in how users respond to our teams or spread the word about what Scribe can do.
We always expected user feedback, but another real “win” for us was to hear teams across the company talking in terms of “surprise and delight.” We’ve seen the framework really resonate and enable us to have more productive conversations about what we’re going to build.
Notes on implementing the Kano model
-
We started by defining what updates fall into which category. With Kano, features are slated into “must haves,” “little more, little better,” and of course, “surprise and delight.”
-
In order to define what features made sense where, we had to understand our users. We met with customers and asked about their “aha” moments, which is really the core of surprise and delight. It’s an emotional response. Usually, users were able to state the exact moment that they felt that way with Scribe. We held these interviews across our user base to get a better idea of our core audience. For the big wins, those aha moments, we want them to be as universal as possible.
-
Then, we began to prioritize our features accordingly. Here’s an example of a “surprise in delight” feature in practice. With Scribe, you click a Record button and then conduct your activity. When that recording stops, you might expect to see a video pop up, or some screenshots. But Scribe instantly gives you a complete guide with step-by-step descriptions of what you did. That in itself is surprising — it’s unprecedented. We have to keep asking ourselves, what else can we do? What would make this experience even more engaging or even fun?
-
We also have to measure the other two categories. For “must haves,” we’re mindful of our core audience. Inherently, anyone can use Scribe. But different businesses might have different “must haves,” and so we keep in mind the user base we already have and what is working for them.
-
The “little more, little better” features improve a product in small increments. We slot those changes in by weighing the amount of time and effort it would take, and then selecting those features sparingly.
Finding what works for you
I will say that the Kano model is not for everyone. It’s less quantitative and relies heavily on team intuition. So we try to be iterative, to experiment, and not let things sit for too long.
This isn’t the right model particularly if you’re building a vertical SaaS solution. At Scribe we’re forging a new horizontal category. However, if you’re operating in an established space, you’ll likely want to look through a different lens.
Another principle we follow is to always deliver more value than you’re asking users to pay. In the case of productivity tools, users have to estimate the value they get on their own, and their experience is so important. If you focus solely on the money value analysis, you might miss an opportunity to become a premium player in your category.
Free tiers are also pretty crucial. A core part of product-led efforts is to deliver before capturing value. We wanted our users to experience the value upfront, so we have a generous free tier.
Don’t be afraid to experiment. It’ll likely take time to find what really works for your company. And of course: listen to your users and listen to your team.
Related reading from the Relay archives:
— Pipedrive’s co-founder, Timo Rein, on keeping core user problems front and center
— Trello’s co-founder, Michael Pryor, on two things that are relevant for any product creator