Join thousands of managers learning how to become great product leaders by signing up to receive the weekly Practical Product newsletter as well as long form blog posts by Jason Evanish.
Share
Practical Product #5: A lesson from Reddit, Notion, and Meta, Disengaged Engineers, Sharing Insights, and Fixing Flaking
Published about 1 month agoΒ β’Β 11 min read
Practical Product Volume V
Hi Reader-
What do Reddit, Notion, and Meta have in common? Turns out, former PMs from those places share a key belief in how to handle customer support in the early days to maximize your learnings.
This and how to handle engineers who don't want to help with solution ideating, how to reduce flake rates, and more in this week's edition of Practical Product.
Letβs dive inβ¦
Table of contents:
π₯ Food for Thought on the Power of Listening
βοΈ What Grinds my Gears on Engineers who don't engage
β Practical Q&A on Improving your Flake rate
π€« Secrets of Product Pros on Sharing Insights with Your Team
π Poll of the Week on How much should Engineers talk to Customers?
Did a friend share this with you? Get this newsletter straight to your inbox every Friday by signing up here.
π₯ Food for Thought
"...@NotionHQ did this with a 24hr SLA (even for free users) from very early on and it was a big part of product development and a key driver of high user satisfaction. β βOne thing we did that users loved: tag feature requests in Intercom and follow up with users when you build the feature." - Jamie Quint, former Head of Growth at Notion and Reddit
I saw this tweet last week, and knew we needed to talk about it:
Early on, one of the best things you can do is to take support really seriously. It's a powerful way to build a connection with your customers.
As Paul Graham's/YC's saying goes, "Build something people want." To do that, you need to understand what they want, and deliver it.
Yet, your first guess or first thing you build is rarely 100% right. That's why you need to make it as easy as possible for your customers to tell you what you got wrong, so you and your team can fix it.
This is true whether you just launched an MVP or are adding your 2nd, 3rd, or 4th product line.
By following Nikita and Jamie's advice and listening careful to what comes through support, you will:
Smooth out rough interfaces and workflows: You know that pesky customer that sends in tons of support tickets for the tiniest thing? They are your best friend! They help you identify rough edges to fix that often many other customers experience, but don't bother to write in about. β
Get new ideas and feature requests: You can't build everything all at once, but you can listen to people's suggestions. The key is to use approaches like asking followup What and How questions, or 5 Why's to really understand what they want and the underlying problem(s) their request is rooted in. (Just remember a feature voting tool is a terrible idea!) β
Find your passionate early adopters: Some people are passionate early adopters and will send you tons of feedback, share their hacks, and hop on many calls with you. Others just want your product to work and say little or nothing. The people who send in lots of support tickets are literally raising their hand π to tell you they're an early adopter for you. β
Tag and source information for later: If you tag your conversations in Intercom, your email, or whatever system you use, you can then go back and see how many people over the years have Tag X, to help decide if you should finally build something. This is particularly helpful if a skeptical engineer or executive doesn't think something is important. Now you can show how many, or how valuable, the customers are that asked for X. β
Source customer development interviews easily: With those tags you can also now reach back out to people who have already specifically told you they're interested in the problem or new feature you're now building next. Get them scheduled for interviews, usability testing calls, and early feature flag access. They're most likely to *want* to give feedback; I regularly get 2-3X better response rate than asking our general customer lists doing this. β
Delight customers by personally telling them you launched: While all of the above help, this one is my favorite. It's so much fun to get to tell customers that those questions I asked (sometimes years ago) about the problem they were telling us about finally led to a launched solution in our product. It's common to get awesome responses like this:
β βAnd 1 day later:
β
This is the kind of relationships you can build with your customers. Following this approach can bring crazy amounts of passion, support, and customer delight.
It can also provide one other powerful signal I didn't mention:
Churn and Customer Intent:
When you make these tags, sometimes when you go back 6, 12, 18 months later and a bunch of your customers who asked for something are gone.
While that may make it harder to reach them, and they may be using something else they're happy with, it is a signal to you.
There's a strong possibility that if most of the people tagged in a feature request/problem have churned, then that thing they requested was a deal breaker for them.
That can be strong evidence you should build the feature, especially if you have other data to support it.
The bottom line: Customer requests for features whether they come in via support or email are a HUGE source of value for you as a PM. Respond, followup, tag, and save them.
β
β‘οΈ What are your biggest questions or concerns in setting something like this up at your company?
Reply with your questions and I'll answer them in a future newsletter.
βοΈ What Grinds My Gears
This section is for rants, complaints, and hard critiques I have about the product management industry.
If you remember Family Guy, this is inspired by Peter Griffin's rants:
β
Today's Grind: Engineers that don't want to help create solutions
I've been reading Marty Cagan's new book, Transformed. It's been great to get a tune up on his tactics and processes that help you build great products.
At the core of this book is how to transform product orgs from "feature teams" where a few executives or stakeholders give orders, to "product teams" that are engaged, creative, and come up with the best solutions to the problems assigned to them.
There is a HUGE difference between "Go build feature X" and "We need to increase user retention for the first 90 days after sign up," which is why Cagan has a whole book about how to make the transformation.
It takes a Product TEAM.
Important to the message of the book (and what I've seen in practice) is that the best products come from teams. You empower the people closest to your customers and those actually building the product to determine what's best. Then, you hold them accountable to the results.
Yet, one of the major challenges in this, and that Grinds My Gears, is that sometimes you don't have the team that can do that. Sometimes, especially engineers have no interest in this and just want to code in the corner and be left alone.
Unfortunately (for them), that's not how building great products work.
As Cagan puts it, you need at least one engineer on your team (ideally the tech lead) who will engage in solution exploration and debate.
Because the best solutions come from the 3 of you: design, product, and engineering.
This is shown quite vividly in this great video (~3 min) of Steve Jobs that went viral this week:
And this isn't just talk. It's how Jobs really worked, as this amazing blog post I share regularly shows. Cauldrons, as he called them, were a key part of Apple making great products, and they were a team effort.
This sounds great, but what do I do if I don't have that!??!
So yes, it's very frustrating if you have engineers who just want to punch a clock, and aren't interested in innovating with you.
Here's what you can try if that's the case:
Ask for one to be transferred to your team: This is the easiest and fastest solution. Often, there can be imbalances on teams, so a simple swap of one of your engineers for a more product-oriented one can solve this without hurting the other team (because the transferred engineer is still good at their job, they just don't want to ideate). β
Prioritize this with your next hire: If your team is growing, then they next best thing is to focus on this as a key thing you screen for when you meet engineering candidates. In that case, make sure you discuss this with the hiring manager, so they know you're looking for that. It may lead to changes to the job description and their early screening process. β
Try to convert one of your engineers: Sometimes the innovation gets beat out of someone; they get so used to being told what to do they give up on trying to contribute ideas. If you're new(ish) to a team or a process like this, look for someone giving small hints of ideas and nurture that. You may be able to bring that back out of them if you show them you value their ideas and input and want more of it.
The bottom line: The best products are built when engineering, design, and product all work in tandem to find the BEST solution, not any single person's preferred solution.
Sometimes you have to help cultivate more input and collaboration from your design and engineering partners. It's worth the effort, because you'll build better products. β
β Practical Q&A: How to Improve Your Flake Rate
"I'm bought into the idea of interviewing customers, but I'm getting a lot of customers flaking. How much is normal, and how can I get more people to show up?"
One of the most common questions I get with people just starting to talk to customers is about customer no-shows and flake rates.
First, it's important to note a few things:
Consumer apps will have higher flake rates than B2B apps: People get busy, forget, get distracted, go see movie and all kinds of things that can cause them to drop.
Rule of Thumb: In an easy to reach, engaged audience in B2B, 10% is a good flake rate (meaning 1 in 10 calls scheduled is a no-show), while in B2C and other difficult industries, a 40% flake rate is not unusual.
It takes time to get customers used to interviews: If your company hasn't interviewed customers much (if at all), your first requests will have a lower response rate. As you start shipping more, thanking customers for feedback, and asking again and again for interviews, your response rate will improve.
Knowing all if this, if you're not getting the responses you'd like, what can you do about it?
I have a detailed post with a wide variety of tactics you can read here:
π€« Secrets of Product Pros on Sharing Insights with Your Team
Talking to customers is a great, and important habit, but it's really only a part of the puzzle.
All those things you learn don't really matter if you don't put them to good use.
You need to integrate them in your work, your product specs/thesis, and share them with your team.
And that's this week's "Secrets of Product Pros".
Share your insights, repeatedly!
One of the best ways to build credibility with your team, and get everyone aligned on doing what is *really* best for your customers is to build great habits around sharing the best insights you learn with your team.
Here's a few of my favorite ways I help my clients master taking insights back to their team and stakeholders:
Share key takeaways from customer interviews in Slack: This is a great way to show your team you're having conversations and give them something they can skim at a time they choose. Here's an example:
This is similar to the notes I talked about last week to put at the top of your customer interview notes, too β
Send a weekly Product Update/Recap: A great way to set a narrative in your company and let them know what you and your team is doing is to send a weekly product email (or biweekly if your pace is a bit slower). Within these emails you can include the biggest couple of customer insights you're hearing repeatedly. β
Include customer quotes in your product thesis/spec: Saying X is a problem is good. Including a customer quote or two, or a list of key customers who lobbied is even better and more persuasive.
β
Link to your customer interview notes: When you quote a customer or make a claim, linking to your source, or putting that in the appendix/further reading of things like your thesis/spec is a pro move. It demonstrates your expertise to everyone, and makes it easy for someone curious to go deeper. This is also why last week we talked about organizing your notes. That way others can make sense of your notes, too. β
Know your data well enough you can regularly speak to it: If you do the above, plus last week's tip about organizing your notes, you really start to deeply understand your customers. That means that in many conversations it will be easy to recall specific stories and data points. Sharing those gives you another way to reinforce that doesn't take much time nor effort.
As you can see, there are many ways you can start bringing the voice of the customer to your coworkers and team members. In doing so, you will show both your deep expertise and understanding of customers, and help your colleagues understand them better, too.
These are the kinds of habits that make you a trusted resource, a valued partner, and the kind of PM that gets recognized and promoted.
β‘οΈ What is your favorite tactic for sharing customer insights? Reply and I'll share the best ones either anonymously or with credit (your choice!)
π Poll of the Week on Engineers talking to Customers
Practical, tactical insights for SaaS Product Managers
Join thousands of managers learning how to become great product leaders by signing up to receive the weekly Practical Product newsletter as well as long form blog posts by Jason Evanish.
Practical Product Volume IV Hi Reader- What have you been learning from lately? I've been reading Marty Cagan's new book "Transformed" and really enjoyed the refresher on essential product management tactics, as well as how it breaks down common problems in organizations that discount the value of product management. This week we take a look at insights from a product leader who worked at both Atlassian and Shopify, the problem with many PM's specs, and some Pro Tips you can apply to your...
Practical Product Volume III Hi Reader- What did you build this week? How did your world view change, because of something you learned from customers? If you love product, those are the kinds of questions you should be thinking about. For instance, just this week, I was learning why customers were coming to buy a course from Lighthouse after a rather long dry spell; it turned out, you can only hold back on some budget cuts so long before you decide it's time to do something again. This...
Practical Product Volume II Hi Reader- As the old saying goes, βIn theory there is no difference between theory and practice. In practice there is.β My goal with this newsletter is to dive into the nuance of product management and give you practical help, so you can actually go apply what I write about to your job. If you enjoy this newsletter, or think I can improve it, reply and let me know! This week, we pick up where we left off last week, with a medley of product tactics and ideas to...
