Customers 🗣 ≠ markets 📣
Where cultures and policies stem from, a humanistic approach for product prioritization, and how customer problems might not carry all the clues to decoding markets.
Welcome to the forty-fourth edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay and the interwebz. So, stay tuned!
In this edition, you’ll find instructive and inspiring pickings from the brains of Sora’s Laura Del Beccaro, Scribe’s Jennifer Smith, and Mode’s Benn Stancil.
Recently on Relay:
AMAs: Boomerang’s co-founder and CEO, Aye Moah, on creating deliberately calm team routines, instituting giving back in the company’s founding charter, price testing with voluntary subscriptions, and more!
#1: The “admittedly blurry” line between policies and culture — Sora’s co-founder and CEO, Laura Del Beccaro, reflects on the mosaic of “not necessarily scheduled behaviours” and structured practices that together shape teams. (Source: Elpha)
There’s an interesting distinction (with an admittedly blurred line) between an HR process/practice/policy and culture. Practices or policies are usually created with culture and fairness in mind, but often aren’t needed until questions arise about those areas.
For example, we still don’t really have an expense policy, because the things we spend money on are relatively straightforward. We didn’t have an official parental leave policy until we first hired a parent. (There are WAY too many things to do, as much as I would have loved to have come up with all the thoughtful policies we’d need from day one.)
One of Sora’s advisors (Jess Yuen, former Head of People at Gusto) helped me define culture as “the set of words, actions, and behaviors of a group of people.”
The words you use with each other, what you decide to share with each other (how vulnerable you are), the way you make decisions and who you include, the norms you create — these are all starting to form at the very beginning, and are definitely worth thinking about now (without spending all the time in the world on them).
Thinking about the way you want your company to operate when it’s 100 people can help you work backwards. Do you want to make sure people take PTO? Better start taking vacations when you have your first few employees, or they will never take vacations, and the people they hire won’t take them, and it will be really hard to reverse course.
Do you want to make sure everyone feels like they have a voice and can contribute to important decisions? Even when you’re 5-10 people, the newest person will naturally feel less empowered than your first teammate. How will you make sure to include her, so that she in turn empowers those that come after her?
One important note is that you can’t possibly be perfect in every way, the same way you could never be a perfect parent.
I think about culture incessantly, and yet at the beginning I unknowingly created a culture where people were afraid to share bad news with me, because oftentimes I would react negatively out of fear.
Luckily, I had at least created a culture where people shared feedback often, so I heard from my team that this was happening and was able to fix it pretty quickly. :)
…
I always struggle to give tactical answers to this type of question. I think the reason is that a lot of what (I think) makes Sora a great place to work is the behaviors that aren’t necessarily scheduled, or considered activities — they’re things like:
1. Actively addressing and normalizing the fact that mental health is hard at startups. We’re extra vulnerable with each other about this, and sometimes someone will announce to the company that they’re feeling extremely burnt out and need to take the rest of the day. No one flinches — rather, everyone is extremely supportive, helps cover things that person needs to do, and totally understands that it’s natural.
2. Taking PTO! Relevant to the above, I think taking PTO is so so huge. I take it all the time — and I think it’s the only reason I survive. Everyone at Sora should a) know that taking PTO is actively encouraged and b) take it all the time, and if they don’t it means I’m doing a bad job.
3. Speaking to each other super honestly when tensions are high. We have all kinds of stress all the time, and humans are humans, but when things get heated, our employees have the tools to talk about it. We talk about why we feel triggered at the moment and explain the current state of our brains. Everyone listening empathizes and has more information to move forward in a productive and supportive way.
We also do fun activities, like schedule a week each quarter where we travel to one city and work together, since we’re fully remote most of the time.
And have a fun “prompt” in our all-team meeting each week that every single employee answers, ranging from fun (“what ice cream flavor would you invent”) to deep (“what’s your greatest fear”), that really help us get to know each other.
I think the biggest thing is just caring. Every single person at Sora cares about culture and knows it’s key to our success :) and all the goodness stems from that!
#2: “In our perspective, numbers should follow rather than lead” — Scribe’s co-founder and CEO, Jennifer Smith, on choosing the Kano model over the RICE framework for prioritizing what to build and “building for user love.” (Source: Relay)
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.
…
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.
…
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.
#3: Knowing the customer ≠ knowing the market — Mode’s co-founder, Benn Stancil, retells how despite having lived the problem as practitioners, having done extensive customer development, they remained in the dark about a fundamental market lesson. (Source: SaaS Club)
We understood the customer very well. We knew analysts. We knew data scientists. We knew the problems that we had really well, because we had been solving them for quite a few years between the three of us [co-founders] at Yammer. And we’d talked to a bunch of people while we were there. We had lived that life.
Still, I think we under-invested in understanding the dynamics of the market. And I think it’s easy to do that when you’re excited about a company excited about an idea, it’s easy to think ‘I’ve got this great idea and I just want to go out and do it.’
Then market research feels like a grind. Frankly, we should have done more of it. We should’ve had a little better sense of exactly where we thought we would be positioned in the market. Exactly what other tools people were out there working on, what problems they were solving with those tools, where were there gaps in that set of tools?
We had some intuitive sense of this. We’d do some customer development to help validate it or prove it wrong.
But if I were to do it all over again, you can do this for a fairly long amount of time and just learn a ton about [the market], and the more of that foundation that you have, the better the decisions you’ll make around building a product and figuring out how to sell it. We did some of this. But you can almost never do enough.
…
Mode was a product that fell to some extent between existing products. These were BI tools [used for static reporting] and…deep-dive analytics products…
And we knew we could talk to some customers and describe that and they would see it and they would get it. One of the things though, I don’t think we did enough of was figuring out exactly what to call that.
The industry had defined terms for the dashboarding stuff. They had defined terms for the analytics and data science products. Mode fit into a thing that wasn’t really defined yet.
In some ways I think we were like, ‘well, the product will work, we don’t need to worry about it, we don’t need to figure out exactly how to talk about it. That’ll be fine.’
And for some customers that was the case. But for other customers, they needed to know what they were buying. They just needed a noun for it.
When we talked to those folks and we didn’t have an answer, it made it a much harder sell and it was much harder in the early days just to get them to try it…
Had we done more kind of upfront research and things like that, we would have had a lot better language to talk to those folks a lot easier time describing what exactly we were building.
…
Not like it’s easy for any company when you start out to be like, ‘we’re going to define our own category.’ That’s a really steep hill to climb. Mode has over the course of eight years, carved out a category in some senses, but it’s difficult to say we are a new category of tool.
People are going to come to you with a lot of preexisting sort of notions of how things work and they’re going to very strongly want to put you in one of those boxes.
Until next time,