“I don’t want a drill, I want a quarter inch hole.”
If you’ve worked in product long, you’ve probably heard that phrase talking about Jobs to Be Done (JTBD). The goal of the framework is to help you think deeper about why your customers buy or use your product. Often, it goes much deeper than you’d expect, and are even more significant than wanting a “quarter inch hole.”
Over the years, I’ve found learning the Jobs to Be Done for your product to be incredibly helpful not just for product teams, but also to inform sales and marketing materials. When you know the true, full buyer’s journey for your customers, you can attract more of them faster, and know how to better meet their needs.
Yet, most PMs are terrible at Jobs to Be Done, even if they claim to know what it is.
They pay lip service to the phrase, kind of like how some people think they’re a “lean startup” because they keep a tight budget. 🤦‍♂️
That’s why ever since I learned how to properly do a JTBD interview from the creators Clayton Christensen and Bob Moesta at a seminar in 2012, I’ve taught many friends, colleagues, and clients how to do Jobs to Be Done interviews, too.
In my experience, doing a live example is the best way to learn it, which is why I’ve typically taught people by doing an interview of them with a recent purchase.
While that works, it doesn’t scale well.
That’s why this week’s episode of Practical Product is a live recording of doing one of these interviews.
How to do a Jobs to Be Done interview: Why it matters, how to use it, and a live example for you to follow along to
On this episode we sit down with my former client, Ryan Findley, to go through the buyer’s journey and Jobs to Be Done for Ryan buying a new mattress.
Ryan, who is the Chief Learning Officer at Learn to Win and has spent his career working at startups and scaleups. He’s a builder who helped launch his current company, Learn to Win, and served as the company’s founding Head of Product (which is when we worked together).
In this episode, we show you:
How to do a JTBD interview
How to map what you learn to the buyer’s journey
What to do with what you learn in an interview
Common pitfalls to avoid and key moments to recognize
Highlights of the episode include discussing:
(0:35) – Introducing JTBD: What is Jobs to be done?
(3:03) – Setting the stage with the product Ryan recently bought
(3:45)- When did you first start thinking it was time for a new mattress?
(4:34) – Who was involved in the purchasing decision?
(7:51) – How did budget play a role here?
(9:14) – Where did you go to get ratings and reviews?
(13:45) – Zooming out: Black Friday & Forcing Functions
(21:36) – The purchase moment
(33:37) – How did this purchase differ from other things you buy?
(47:17) – Did you visit any third party locations when you were in the process?
(48:39) – Digging into Ryan’s experience using what he purchased
(49:59) – Advice for marketers applying JTBD
(54:53) – Ryan’s thoughts on this experiment
Key Show Notes & Further Reading:
We covered a lot of ground in this episode, so we have a ton of links for you to check out.
Mapping the Buyer’s Journey
The image above is the timeline we discuss in the episode. As you do a JTBD interview, you will learn what the various steps were in your buyer’s journey from “First Thought” all the way to “Buying” and “Consuming.”
If you want to follow along more closely in the interview, open up this companion post on how to do the jobs to be done interview. I use this post and the questions listed there every time I do an interview.
Unfortunately, the product management interview process at most companies is poor. Navigating the interview process, or creating a good one at your company is a tall task.
In this wide-ranging interview we cover both perspectives to help you think about both the perspective of the interviewer and the interviewee. You’ll learn how to prepare to run a great interview process, when a project is appropriate and how to make it effective, as well as tips for your resume, and how to handle imperfect interviews for your next job.
This episode is with Willis Jackson, a long time friend of mine who has been the first PM at recently IPO’d Grove Collaborative, as well as VP of Product at Apto. He’s now hard at work on his own startup, but he took some time to share a lot of hard earned knowledge on the interview process in this episode of Practical Product.
The Product Management Hiring Process: How to thrive as the interviewer or interviewee
On this episode, we cover terrible PM interview practices, the key fundamentals of hiring you need to follow, how to ask behavioral questions the right way, making good PM assignments, and how to build your resume like a pro.
Highlights of the episode include discussing:
(0:44) – Introducing Willis JacksonÂ
(2:18) – The different types of Product Management and how they affect interviews
(8:09) – Recommended resources to learn to be great at hiring.
(17:15) – Handling ridiculous hypothetical questions and what to do instead.
(26:51) – The importance of networking, reputation and interviewing stories
(38:33) – How to make good, fair PM assignments for your interview process
(52:43) – Whether you should include company problems in your interview process
(59:13) – Resume crafting do’s and don’ts for PMs
(1:22:45) – Finding the right type of PM roles and filtering opportunities to save all sides tim
Key Show Notes & Further Reading:
We covered a lot of ground for both the interviewer and those seeking their next job, so some key takeaways are grouped below for each.
For the interviewer:
If you know you’ll be hiring down the road, start planning now. Think about the skills you want, the values you want, and the process you’ll follow.
Interviewing is a skill. Spend time reading and learning how to do it well.
It’s much easier to create your interview plan in small, incremental steps leading up to when you need them than being buried, desperately needing help and spread too thin.
Avoid puzzles, brain teasers, and hypothetical situations that are nothing like the job they’d have. Research shows it has no bearing on evaluating candidates effectively.
If you’re going to make an assignment, make it:
A reasonable time request (a few hours, not days worth of effort)
Consistently applied to everyone (don’t give one person a day and someone else 2 weeks)
Involves what the job would really include. (Willis’s example is a plan after an experiment / launch fails)
Extremely clear what you’ll evaluate them on and what you will not. (Like whether you care about design or format)
Be proactive in communicating with your recruiting team. Enlist their help and expertise to find & close great candidates.
Remember that hiring the wrong person is extremely expensive in time wasted by your team, cost on your budget, and setbacks on your projects.
For the interviewee:
Make your resume succinct and include data & numbers as much as covering skills and actions
If you do not have numbers now, start working on it now. Get in the habit to look up numbers and see what work you did has moved the needle.
Your resume becomes talking points and great questions in the interview.
Prepare good questions to ask an interviewee to make sure the company does the kind of product management you like doing.
Reflect on your current job regularly. Willis recommends weekly journaling on subjects like:
What wins have you had recently? What happened?
What did you learn from a project that recently didn’t go well?
What do you enjoy about your work and want future jobs to also offer you?
What’s changed over time in my notes?
Helpful links mentioned in this episode:
BOOK: Work Rules by Laszlo Bock is about Google’s learning about HR and People responsibilities, including interview tactics.
Are your product specs high quality? Do they succinctly and clearly convey what you’re working on, why you chose them, and what your engineering and design partners need to do their jobs well?
Or are they kind of random, with each one different than the last?
I’ve helped dozens of PMs improve their product specs, and I’ve been lucky to learn from one of the best how to make a great product spec. Which is why I knew I needed to do an episode on the subject to help everyone improve their product specs.
Today, we cover:
The most common mistakes PMs make in their product specs
How I learned the right way to make a spec
The key, fundamental concepts underlying good product specs
and most importantly: Exactly what goes into a great product spec (aka- Product Thesis)
How to Write Product Specs Your Team Actually Wants to Read (AKA – The Product Thesis)
Everyone writes product specs regularly in their job as a PM, but few do a great job with them. These poorly constructured specs then cause all kinds of problems on product teams including:
Engineers and designers confused and uninspired about what they’re making
Delays in shipping due to misunderstandings and miscommunication about priorities
Disappointed execs who don’t get what they expect
And a lot more. Yet, it keeps happening because PMs don’t realize that the root cause in their specs that:
Do not cover the right topics
Are wayyyyy too long, and filled with fluff
Tend to be overly prescriptive on the solution instead of collaborating with your team on it
Lack data to back up your decision
Fail to share an inspiring WHY to motivate your and convince your team
Are inconsistent spec to spec making it harder to read and digest
That’s why we need to hit the reset button and reshape how you make product specs with something called The Product Thesis. Listen in to learn more about it:
Highlights of the episode include discussing:
(0:49) – Mistakes made on the average Product Spec
(3:17) – Introducing you to The Product Thesis
(10:06) – What goes into a Product Thesis?
(12:05) – Section 1: Why are we working on this next?
(14:57) – Section 2: When and how do people use this feature? (Aka – what are the use cases?)
(18:24) – Section 3: What problems do we need to solve, and in what priority?
(24:19) – Section 4: How much time is budgeted for this project? When does this need to be completed by?
(25:56) – Section 5: What are the future considerations that must be accounted for?
(27:28) – Section 6: What is our KPI or metric for this thesis?
(29:59) – Optional: For larger companies: Who are the stakeholders and how/when do they need to be involved?
(31:14) – Optional: What kind of launch or marketing/sales efforts go with this feature?
Have you ever thought about building a free tool for your company? Do you want to build more buzz, get a ton more inbound SEO links, or drive signups and leads for your core business?
Or maybe you are a free tool skeptic, worried it will distract your team, take to much time, or not pay off?
I’ve always been curious about free tools, but haven’t been directly involved in many myself. So when I met Michael Novotny, who has become an expert in creating free tools, I knew I had to have him on the Practical Product podcast.
Michael is a product manager turned founder, who has helped build and launch dozens of free tools / side products now and studied hundreds of others with his company, Product and Build Co.
In this episode we go deep on this topic covering everything including keys to success, pitfalls to avoid, tons of examples, and how to convince yourself or your boss to take a shot at making some free tools or side products.
How to Use Free Tools & Side Products to Grow Your Business
Today we talked about how building free tools (aka – side projects) for your company can help drive major growth for your company.
Building these tools helps you a few ways:
People who use your free tool may directly sign up for your paid product when they see you made the free tool.
People using your free tool may give you their email address, which you can market to later.
Others will link to your free tool, boosting your SEO through improved backlinks.
Michael shares a lot wisdom and experience doing these, and the most important tips are:
Build a portfolio: You need to launch many tools (ideally 4-5 or more) so that some will hit, and others won’t. If you only launch one, the odds work against you on the moon and stars aligning for you.
Build in public/test with your community: To increase your success rate, validate and test the ideas you have for tools to see if they resonate and what are the most important things it needs to do to provide value.
Use low and no-code tools: You can build and launch a lot faster using these tools, and since it doesn’t touch your core product, it doesn’t need the perfect architecture.
There’s a lot more to this episode, so I encourage you to give it a listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(2:04) – How Michael discovered the power of free tools to drive sign-ups for another product
(11:46) – What are a couple of your favorite examples of these tools?
(16:31) – Cases where free tools didn’t work out.
(21:55) – Are there businesses that shouldn’t be creating free tools?
(29:05) – What is Michael’s Side-Product Framework?
(34:56) – How should PM’s think about budgeting for Side-Products?
(42:08) – How do you come up with good ideas?
(47:55) – How can you start to validate some ideas for tools to see if you’re on the right track?
(54:09) – What should people do to make these free tools successful?
(58:05) – What are the best ways to tie a free tool to your product?
(1:03:32) – How much ongoing maintenance should you expect?
(1:09:18) – What are your favorite tools that help you piece this process together?
(1:13:58) – Keys to convincing your boss or peers to try free tools.
“Sales is just a bunch of sleazy, coin-operated machines”
“These bugs never get fixed. Product doesn’t care about CS…”
At the companies I’ve worked at, and those where I’ve coached PMs, relationships between departments have not always been great. In fact, they have sometimes been down right toxic, like the quotes above.
As much as it may feel good to point fingers, it doesn’t really help in such situations, and it’s the responsibility of product managers like you to improve them.
Yet, to fix them requires real change, new habits, and a lot communication. It’s absolutely possible (and common) to be well-liked as an individual human at your company, while the reputation of your product team or the product org as a whole is poor.
Today, we dig into those common issues, and how to hit the reset button so you can have great relationships with other departments and especially your key stakeholders within them.
How to Reset Your Stakeholder Relationships to Improve How You Work with Other Departments
Before we dive into how to fix this, let’s look at where things go wrong. There are a few common mistakes that lead to stakeholders and other departments being at odds with product teams. If any of these resonate with you, then read on:
Sales sells features that don’t exist yet without consulting product.
Sales and/or marketing complain about ship dates slipping often.
Customer Success keeps trying to come up with new ways to get the attention of product to fix things they see daily.
An internal feature request board filed by customer success, support, and/or account management has become a bloated graveyard rarely reviewed or followed up on.
Executives keep asking for new ways to be updated on product.
Product managers feel misunderstood, or overwhelmed by demands and requests.
New feature launches are extremely stressful, and rarely well coordinated with needs from other teams like marketing promotion, sales training, or help doc creations and updates by support.
And there’s likely others you’ve experienced. The underlying theme of all of them is that you have a stakeholder relationship issue one or both ways:
PM -> Outward: You’re having trouble getting what you need from other departments for launches, customer insights and needs, sales demands, etc.
PM <- Inward: Other departments are complaining that product isn’t informing them effectively and delivering on what they need to be at their best in their role.
As a product manager, your job is to be a coalition builder. A large portion of your job is about listening and learning. You’re also challenged with building buy in and support for the things that you believe need done. Fortunately, that makes you perfectly suited to reset your relationships with other departments and stakeholders, regardless of who is to blame for past issues.
One of the phrases you hear commonly that PMs need to do is “Stakeholder Management”, which I think is a misnomer.
Your job is not to manage them. Your job is also not to keep them happy.
Instead, you should treat them like a Partner.
That means:
You share your goals with them and listen to theirs, so you can see where you’re aligned and work through areas where there may be conflicts.
You let them know what you need and what you’re working on so they can help you.
You treat them as a valued source of information, and share what information you have that could help or impact them.
You bring structure to your partnerships with them by thinking ahead, asking good questions, and communicating the information they must know based on their needs and role.
When they make requests, you genuinely listen and then explain your priorities so they understand how their requests fit in, or why you have to say “not yet.”
This is all instead of “Management”, which often means:
Fielding their requests
Trying to keep them happy, or avoiding conflict
Dealing with their frustrations or outbursts
Selling them on your product decisions
So the question becomes: How do you build stakeholder partnerships?
How to build Stakeholder Partnerships
There are 3 key ingredients that underpin all of the recommendations in the remainder of this post:
Empathy: Understand your stakeholders, and help them understand you.
Transparency: When both sides understand clearly the other’s goals, it gets easier to resolve conflicts.
Structure: Product managers should lead these discussions, and in doing so, there will be better discussions, and you will be less likely to have significant conflict.
If you’re looking to hit the reset button to stop managing stakeholders and start making them partners, here’s the key things to do:
1. Understand the needs and motives of your stakeholders
The first thing to do is to consider who your stakeholders are. Based on that, you’ll be able to think about what you need to get to know about them.
For example, if someone is in the sales org, we know:
Quota: They have a number they have to hit that will always be top of mind.
Closer’s mindset: When you tell them something, they’ll be thinking about it through the lens of how it will help them close more deals.
Successful customers: No one wants to sell a lemon, so they’ll be interested in being sure they’re selling something that will work for the leads they work to close.
Also keep in mind that depending on their level in the organization, they’ll be thinking differently:
VP: Is thinking about the high level number the entire organization has to hit, and how changes impact the entire organization. They’ll also likely be thinking more long term as they consider head count, and multiple future quarters numbers they have to build towards.
Director: Will be thinking about the sales team that reports to them. If that’s a specific vertical, territory, or other type, recognize it will change what they’re interested in and what they’ll be lobbying for.
Individual Contributor in Sales: They’ll be focused on their specific leads for their territory or vertical and their number to hit, and are less likely to be aware of things going on outside of their team. They’ll be the most short term thinking of all.
As you prepare for what stakeholders you’re going to engage, keep in mind what level they are in the organization and how that may impact what they need from you, what they may lobby you for, and how they can help you most.
If you’re unsure, the best thing you can do is ask a few questions to really learn what matters to them like:
What’s your biggest priority this quarter? (or next quarter if approaching EOQ)
How do you fit into your organization?
Can you help me understand how your responsibilities are part of your department’s larger goals?
Based on what I’ve shared we’re working on, who else should I talk to? Why did you choose them?
While the first few questions give you the foundation for your relationship with the stakeholder you’re talking to, the last one is really underrated; they can help you navigate the other departments more effectively as they’ll know who else to talk to who could be helpful, has been talking about things you want to learn about, or that complement what they share.
Most importantly: Don’t assume. It’s always better to ask and be sure, than make a guess and then jump to the wrong conclusions.
2. Consider them one of many inputs you have
You should be sourcing data, input, feedback, and information from all over. Just a few of an endless number of examples would include:
Data and analytics from Looker, SQL queries, your analytics tools, Full Story, heat maps, etc.
Support ticket patterns, bugs, and biggest pains from the Customer Success team.
Top reasons you’re losing deals from the Sales team and Salesforce reports.
Key requests from big and important customers from your Account Managers.
Market research and analysis as well as surveys and other data from Marketing.
Financial impacts to changes in pricing, payouts, and onboarding experiments from Finance and Ops.
Error and bug reports, site and specific page speeds, and overall health of your product from the Engineering team.
Usability issues and customer-product interaction problems from the Design team.
Insights from your own direct customer interviews, surveys, and feedback mechanisms.
A key skill of being a great PM is turning requests from these many teams into actionable, and prioritizable insights.
To do that, you need to develop the skill of asking them the right questions when they come to you with a request. Some simple questions that can tell you a lot include:
How often does this happen?
What is the root problem or cause you think that’s leading to this?
How does this impact customers? (What kinds of deals are we losing because of this? Are people churning or rage tweeting about it?)
How can you help me quantify the potential impact of the change you’re suggesting?
My priorities right now are to focus on [X]. Do you see a way this would help with that goal? How?
What you’re doing here is teaching them how to take their requests and put them into a format you can act on one way or the other (either address it, or have good reason not to). It also gives you a way to easily push back, because something is far outside your focus right now.
A Sales Example…
For example, if an Account Executive comes to you and says, “We really need to build X! I just lost a deal because of it!”
If you then ask, “How often does this happen?” and they say, “Well, it’s the first time,” you can easily then tell them:
“Okay. I understand it’s not fun to lose deals like this. If it happens 5 more times, I’ll sit down with you and we’ll go over all 5 deals to look for patterns and figure out what we can do to help.”
What’s particularly important here is you’re teaching them how you work. You’re not only letting them know the information you need, but also the threshold (“5 more times”) for it to matter to you.
I used such an approach with a past Customer Success team I worked with. That led them to only raise concerns for issues they had to address 10 or more times in a single month. This took me from getting dozens of requests every time we met to an organized list of 2-3 asks per month.
This proved to be a huge win-win:
We fixed their most important problems, reducing their time spent working around the same issues over and over.
Because they knew I was listening, they put in more work to organize the information I needed so I could quickly and easily take back the bug information to the engineering team to fix.
Your other department stakeholders can be a wealth of information, and even help you prioritize problems when you bring the right questions to the table, and teach them how you think like in the examples above.
Remember: “Not yet”, instead of “No.”
One thing to keep in mind is that constantly hearing “No” from the product team can be really frustrating, especially if they don’t feel like other things are coming fast enough.
That’s why a key phrase for you to remember is to say, “Not Yet” often.
When you say that, you can then explain your current priorities and reasoning to them. That will often help them understand why they have to wait for what they asked for. It may even help them remember something else they need that *is* related to your current goals.
3. Bring the structure to your relationship and every meeting
Every meeting you have with a stakeholder should have a purpose (or multiple).
Prepare an agenda and bring it with you to the meeting. Let them know so they can add things as well, and plan ahead for any questions you ask (especially if it involves asking for numbers or other data).
Most importantly, keep in mind you should be consciously driving the relationship.
By bringing an agenda, questions to ask them, and a plan for what you want to get from the relationship you will effectively make the switch from stakeholder management to building stakeholder partnerships.
Just like the Product Thesis challenges you to make sure you’ve thought through everything you need to kickoff a major project, following the approach outlined here in this post will help you think through everything you need to do with your stakeholders.
Take time to plan ahead, and the meetings with your stakeholders will go much better.
4. Iterate on the relationship as you work more with them
Stakeholder management is not one-size-fits all. You will need to adapt to their work styles, personalities, how helpful they are, and how relevant their work is to yours.
This is all likely to change over time, so be prepared to make changes accordingly. A few examples that you should keep in mind:
Frequency: Meet with stakeholders that are key to your project more often, and as they become less critical, meet less often. These recurring meetings are sometimes called Peer 1 on 1s.
Helpfulness: If someone is difficult to work with, and doesn’t add a lot of value to your efforts, consider if someone else is better to meet with in that department.
Triangulation: If another team is critical to your work, a single point of contact may not be enough, so consider getting multiple perspectives varying by seniority, focus, or other vectors that give you the best view.
Your Needs: When you’re doing exploratory research, someone who can introduce you to the perfect fit is most helpful. Meanwhile, when thinking strategically, someone more senior may be a better fit. Adjust and adapt accordingly
Over time, you’ll develop instincts around this, which will help you know who to reach out to and how often will be ideal to talk to them. You’ll also start to recognize what questions are best to ask each person you speak with.
If you’re new to this, or hitting the reset button in a big way, keep in mind this is a process. It will take time.
The goal of this post is to help you re-frame your relationships around this new approach, and you’ll work with them and your other stakeholders over time to perfect these partnerships.
Recap: Remember these 3 things
There’s been a lot in this post, so here is a reminder of the most important things for you to do to turn stakeholder management into stakeholder partnerships:
1) Set the rules and manage their expectations
Teach them to fish by setting thresholds for escalating to you vs. sending everything. Communicate why you choose that and be open to tweaking it with their feedback.
Frame the relationship by bringing an agenda every time and asking good questions of them. Over time they’re likely to start doing the same.
2) Show your thinking and priorities:
When they understand what you’re working towards, they can share ways to help you with insights, data, and introductions to key customers.
They’ll also understand why you may need to say “Not yet” to some of their requests.
But that only happens if you share it with them, so work to provide a concise overview of your work and thinking.
3) Get to know them and iterate:
When you build rapport with them, and listen to their needs, too, they’re more likely to have empathy for you as well.
You and their needs will change. Iterate on the frequency of meeting, topics you cover, how you explain your thinking, and questions you ask them to evolve the relationship effectively.
Tell them this is an iterative process as well, so they can help shape and improve them, too. You never know where a good idea or insight may come from!
Further Reading
Have questions? Leave a comment, or if you want hands on help for yourself or your product organization, you can learn more about my coaching and consulting here: BeCustomerDriven.com
To continue your learning to improve your stakeholder relationships, read these:
Communicate more clearly with your engineering and design peers and clarify you’re thinking with the rest of your organization by learning how to write a Product Thesis.
“Let’s see what the highest voted features were on our feature voting site.” – Said no great product team, ever.
Whether a company is using the new hotness of a Canny, or the old clunky of a UserVoice site, public feature voting systems are an example of terrible product management practices.
62/ Show me a product team that relies on data from feature voting, and I’ll show you a team that thinks they know their users a lot better than they actually do.
I’m a HUGE fan of founders and product managers talking to customers. In fact, I’ve written a variety of posts to specifically help more people confidently and effectively “get outside the building” to learn from their customers to build better products.
Unfortunately, feature voting apps are the kind of shortcut that make some people think they’re getting customer input, when really they’re making a mess.
Just looking at this page makes me 🤢
I’ve had a personal disdain for these tools for many years, as I’ve tweeted about issues a few times, and had many conversations with other founders and PMs about it. And today, I’m finally pulling together a comprehensive case for:
Why great product teams would never dream of using a Feature Voting tool
All the reasons feature voting leads to a worse products and bad decisions
What to do instead to be truly customer driven and deliver real customer value
With that in mind, let’s dive in…
Why Great Product Teams Avoid Feature Voting Tools like the Plague
There’s more than one way to build a great product, but there are a few traits that great product teams have in common:
Data Informed: They measure the results of their work and use analytics and data to help them focus their efforts and see where they need to ask questions.
Customer Driven: They think with the end user in mind, whether they understand it innately because they are it, or they deeply dig in to get to know and speak with end users of all types.
Detail Oriented: The details are what separate okay and good from great when it comes to products. One of my favorite sites is dedicated to them: LittleBigDetails.com
Product Sense: This obviously takes time to develop, but the best product teams include people who have and enforce having taste; they don’t fall for every fad, and bring a stamp to their work that people can see a bit of their fingerprints on.
Collaborative: The Holy Grail of great product teams is being able to operate with the Cauldron approach that Steve Jobs used; everyone brings their best ideas, no one cares whose idea was what, and everyone focuses on creating the best possible solution.
These are all hard to build and can take time to develop. If you’re trying to level up a product org, you likely can only improve one at a time, but that’s a post for another day.
I spent the week talking to customers on the phone.
I'll be honest. I haven't done this in awhile. Easy to think you're past the 'phone call stage'.
One of the best weeks of my Tinder career.
It doesn't matter what scale you operate at. Pick up the phone & talk to customers.
When it comes to feature voting, it works against all of these:
Data Informed: As we’ll dig into more below, the data from feature voting is trash. Bad data is worse than no data.
Customer Driven: It may seem like it brings some customer voice in, but feature voting is so distorted and warped, it represents a bastardized version of listening to and understanding your customer.
Detail Oriented: When people vote on a feature, what are they really saying? You don’t know. You just know they clicked an up arrow, not the nuance of their needs.
Product Sense: Feature voting tries to turn your customers into your product team. Don’t. do. that. You build a product team so your PM, designer, and engineers can create the best solution, which customers usually haven’t thought of.
Collaborative: There’s nothing collaborative about a wall of feature votes on a screen. And without the real context of the problems to be solved, there’s no way to talk tradeoffs and iterate to something great.
Yet, despite all these being true, these are minor issues compared to the biggest issues with feature voting: They are fatally flawed from the start.
Let’s talk about why.
How Feature Voting Fails
Let’s deconstruct all the failed parts of using a feature voting system. It starts with a faulty foundation, and falls completely apart from there.
1) You get *features* not problems.
If you look at the average results of feature voting sites, what you’ll see is a lot of people asking for a feature. Typically posts say things like:
Make a CSV export
Build an integration with X
Add tangential feature Y
Here’s the thing: Any of those requests should be the *start* of a conversation, not the answer by itself.
For instance, with a CSV export, all of these questions come to mind putting on my PM hat:
What specifically do you want to export?
Why do you need an export? How will you use the export?
How would you like the export formatted?
How often would you expect to need the export? Why that frequency?
All of these questions can lead you down a rabbit hole that realizes any of the following:
A new report in your product would be better, and more up to date, than an export.
The export is for a key weekly meeting for the customer, so automatically emailing the numbers would be even better.
The export is only needed once a year, and needs to cover multiple sections of your product to really meet their needs.
The only way to get these kinds of insights is to talk directly to customers, and a feature voting site does not allow you to have those 1 on 1 conversations effectively.
2) People get easily sidetracked…
You’re using a product. Suddenly you notice something annoying, confusing, or missing. You decide you’ll share the feedback that their stacked bar chart that only has two shades of blue is very difficult to read and you’d like more control and granularity.
You notice they have a feedback button, or a link to their feature site and eagerly head over.
When you get there, you’re greeted by a list of dozens, if not hundreds of other options.Without meaning to, you start reading the other options, maybe clicking on a few. “Oh that sounds interesting…” you think.
Without meaning to, you start reading the other options, maybe clicking on a few. “Oh that sounds interesting…” you think.
But then you forget why you came, and either never get around to sharing the feedback you meant to, or giving only a partial explanation of your original thought.
Either way, the product team loses, as the feedback that motivated you to come to the page is much more valuable than a random upvote or two.
3) …Too many votes for something discourages future posting
While distraction is one problem, the sibling of it is people flat out giving up. If you look and see the top upvoted item was posted in 2017 and has 400 upvotes, what makes you think your new idea will ever get any attention? And do you think that anyone at the company is even really listening?
When feature voting apps were first getting popular about 5-10 years ago, I used to dig into them to try to get an idea of how product teams used them.
It was depressingly rare how often I’d see someone from the company actually active.
Even worse, when they were active, it was usually trying to explain why they’re not going to build the most popular items.
Now, feature voting sites can try to help with this by building some kind of algorithm to show “trending” or “most recent” items, but that’s really lipstick on a pig; this is just one of many significant problems.
(Fun aside: At a past job, I looked at our competitor’s UserVoice and noticed a number of posts from people asking for features we had that they didn’t. I passed this to our VP of Sales who then figured out who these people were and got some of them to switch to us.
So your Feature Voting page not only hurts your product, but makes it easier for your more ambitious competitors to steal your frustrated customers.)
4) Nobody wants yet another log in
One of the most famous stories in e-commerce history is the discovery that you can make *millions* more, and have double-digit improvements in checkout conversion by allowing people to check out as guests:
No one wants yet another log in, yet in many feature voting tools, the first thing you have to do is create another account to upvote or leave a suggestion.
As anyone who has worked on growth teams or on e-commerce conversion rates knows, adding steps to a process will always lead to more drop-off.
So let’s think about it…which is easier:
Feature Voting:
Leave product you’re in to go to feature voting site
Land on the overall page filled with existing suggestions
Click on an item or to post your own feedback
Sign up for an account (or if you’re a masochist, sign in with your account from last time)
Find the way to add your suggestion and post it
Or, the direct way:
Click on Intercom, a Feedback button, or link
Send your message
If you’re measuring the rate of customers having feedback to actually sending, the latter option will far outperform the former.
But we’re getting ahead of ourselves on the solution, so let’s continue with the problems of Feature Voting.
5) Not all votes are equal.
Let’s look at two different Product Managers and see what they have:
PM 1: Talks to customers directly, gets feedback passed to them from other teams, and with help, organizes it all.
PM 2: Relies on the feature voting page, when convenient, to show how many people are asking for something like what they dreamed up.
—
PM 1 has 25 logged conversations where they or a colleague they trained asked some follow up questions for context, and understands this is “very important” not just a “nice to have.”
PM 2 has 50 upvotes for a feature that kinda sounds like what they’ve spec’d out.
Question: Who has more real data to back up their decision making?
Answer: PM 1 in a landslide.
Upvotes != real customer feedback
The number of upvotes a Feature Voting submission has does not mean all of those people want the same thing.
Let me repeat that: The number of upvotes does not mean every upvote wants the same thing.
Here are some of the reasons someone may upvote it:
“I want that feature exactly as described.”
“Well, this has 25 votes already, and it’s close enough, I’ll upvote that instead of post mine.”
“Oh that looks interesting, I wouldn’t mind that. Click.”
“I think my coworker wanted that…”
“I could have used that a few months ago” (and haven’t needed it since)
“That sounds cool.”
All those upvotes and you don’t really have a quantitative count of customer input. Something could have 250 upvotes, but it’s the least important item. Or they could want different functionality or features as part of it.
You don’t know though, because all you have is an upvote, not a conversation, or even a few sentences from each of those people.
QUICK PM QUIZ:
You’re a SaaS PM that has a mix of SMB and mid-market customers. Which feature should you build:
A) A feature that all 5 of your biggest customers say is critical to their workflow
B) Dark Mode, because it’s highly upvoted on your Feature Voting tool
If you choose B, please think about a career change
6) Customers forget what they wanted if you wait to reach out
Do you remember what you were thinking a year ago? How about a month ago? A week?
For the vast majority of people, ideas, and feedback, are fleeting. When you’re in the moment doing something is the time you’re most in tune with the situation.
If I come back to you a year later asking, “Hey – I saw you upvoted Feature X last year. We’re finally working on it. What were you looking for?” Unless you have continued regularly experiencing the issue that prompted the vote, you’re unlikely to remember the request well.
You might have also changed jobs and be unreachable, gone on vacation when I reach out, or not even remember voting for something.
That means following up with all those upvoters when you finally get around to a feature, you’re unlikely to get nearly as many useful insights as you would in the moment.
Feedback is like milk…it goes bad quickly when raw.
That’s why it’s so important to talk to customers regularly, and ask them in the moment what the underlying problem is and why it matters to them. That’s when they’ll remember the context you need to truly understand their request.
Just because you can’t build something right away does not mean you can’t talk to customers about their needs and save it for later. You do that by talking to them (in chat, email, calls, etc), not by collecting votes and checking your Feature Voting app once a quarter for ideas.
—
From distractions to lost feedback, and murky data to blurred meaning, Feature Voting is fundamentally flawed from the start, and only gets worse the longer you use it.
Now, let’s talk about what to do instead.
No founder ever regretted talking to their customers more
There are great sources of feedback available all around you:
Sales Teams: They know what deals are closing and what deals they’re losing. And the best sales people know the difference between good losses (not a great fit) and bad losses (could have won and the customer would be happy).
Customer Support: They deal with the angry, the frustrated, the annoyed, and the confused. Tap into their knowledge and fix their biggest problems…and you’ll fix your customers’ problems, too. They also will get feedback, so give them a way to pass it to you.
Account Management: They’re in charge of keeping customers and making them successful, so they see the gap between the promises your sales team made, and the reality of using your product. Another gold mine of feedback and insights, and even a potential source of future junior PMs.
UX Researchers: As they do usability testing and test new features, they likely hear customer gripes, questions, and feedback. Make sure that gets captured.
Data Teams: Ever wanted to ask a specific subsegment of your audience a question? Your data team is your best friend in helping create all kinds of great segments to analyze, survey, and reach out to for customer interviews.
You: If you’re a PM and not regularly talking to customers, what are you doing? Make the time, and build the habit both for features you’re actively thinking about and to generally get feedback.
Now, that sounds like a lot, and it is. Which is why you need to dig into one of the key, unheralded jobs of great product managers: Relationship Building.
Have Peer 1 on 1s with key people on other teams.
Choose some of the best people, or those most related to the part of your product you work on, and have peer 1 on 1s with those people in customer success, sales, and account management.
As you meet with them every 4-8 weeks or so, remember to teach them how to fish! What this means is that you will:
Explain to them your goals of gathering feedback and understanding customer needs they’re hearing, so they get what you’re trying to accomplish.
Teach them how to ask a good followup question or two (“How important is this to you? What is most important to you in this request? Why?”) before passing information to you.
Involve them in prioritization by telling them the threshold for passing it to you (i.e.- “Once you hear something 10 times, let me know” or “If it’s a customer >$N per year, pass immediately to me.”), thus keeping your signal to noise ratio strong.
You can also then share back with them how you’re listening and acting on what you hear from them.
Nothing puts a smile on the face of customer success like hearing “Yes, we’re finally fixing that bug you have been dealing with for months” or telling a sales person about a hot new feature you both know they can sell like crazy.
When you start sourcing information from all across your company, you’ll see that feature voting is so incredibly low quality compared to all the ways you can get detailed, context-filled, specific information from your peers.
2) Choose your focus
Feature Voting apps don’t know what your company’s priorities are this quarter, and neither do your customers. Yet, as far as a Feature Voting app knows, all requests are created equally.
That’s why it’s important for you to narrow your efforts as a PM by starting with a focus.
Some examples of proper focus would be:
Retention: You need to improve retention and resurrection of old accounts for your social app.
Churn: Your SaaS app is leaking too many customers, bringing a drag on growth.
Growth: You need to create more organic growth through an improved viral coefficient.
Conversion: Customers are adding to cart, but not buying. You need to find out why, because it is crushing your CAC.
Activation: Why are customers signing up, but not completing the setup process?
New Bookings: Your company is trying to go up market, and needs to identify the features that will allow for more medium sized business deals to close.
For each of these problems, a different segment of your customer base would be your target to talk to. Along with this, different problems and features would be most important to focus on.
By starting with your focus in mind, it narrows down your efforts significantly, and can help you ask the right questions of all your peers you’re now meeting with and talking to semi-regularly.
This context helps you make better decisions, and changes who you talk to and what you ask them.
3) Get Quantitative, too!
While ultimately the goal is to understand who your users are, how they use your product, the problems you solve (or need to solve in the future) and how you fit into their world, you must balance that qualitative information with quantitative data.
Being customer driven also means understanding the numerical side of your customer base. You likely have a few different personas and company types who use your product. You need to understand how that translates numerically to your business with answers to questions like:
What % of our customer base is each type of business? How much of our total revenue do they correspond to?
What customer types have the highest LTV?
How do our core metrics compare when we slice our customer base by various properties (like company size, business type, various demographics, plan type, device, location/region, etc):
Churn rate
Rate of expansion
Referral rate
Conversion rate
And I’m sure you can think of many more. This kind of quantitative work is a priceless exercise, especially if you haven’t done it before.
When I was at KISSmetrics we dove deep into these and discovered that company size didn’t really matter, but when it came to business model, SaaS and Ecommerce businesses converted 2X as well, churned half as much, and thus had a much higher LTV.
Do you think that impacted our future product decisions?
Surveys are your friend, too.
Now, ideally you’d have infinite data you could easily query across your product to answer every question. However, that’s neither feasible, nor really desirable (it would be too costly, hard to maintain, etc)
For snapshots in time, and to jump-start efforts, surveys then become your friend.
This allows you to then take input from your customers (especially those interested enough to take a survey) and segment it based on the questions you ask.
That’s why for instance with my startup, Lighthouse, we ask people what department they work in. Certain departments convert better than others, while one department has proven to be a massive time waste. We automatically filter out the latter’s input, because we know it’s not useful.
However, surveys are not a guaranteed silver bullet. In fact, most people make a ton of mistakes using surveys by making them too long, asking too many open ended questions, or using confusing language.
Make as many questions multiple choice as possible
Ask customers to mark the *most* and *least* important things instead of rating everything
Now, taking a step back, not only are you building an engine to gather all your feedback and to better understand your customers, but you should also be using your analytics and other quantitative data (sales & marketing numbers, conversions, custom queries from your data team, etc) to help prioritize what metrics you want to move.
And once again, this kind of data informed approach gives you much better information than the random, muddy data of feature votes. Here you’re understanding problems, not starting with features.
4) Make people feel heard!
I hinted at this above in the problems with Feature Voting section, and it bears repeating: your customers want to feel heard.
Posting or upvoting on a Feature Voting site is like the Suggestion Box in a Dilbert Comic:
The real way to make customers feel heard is for them to get a response from someone on the product team to things they ask for, and to occasionally see things they ask for fixed or added.
It could be its own post on how to do this, but for starters, here are 3 of my favorite approaches:
1) Tell your customers about new features launched
Any progress is good progress in the eyes of customers. It gives them hope you’ll get to some of their requests, and can really make their day when you finally build something they really wanted.
Doing so let’s them know you’re listening, gives you a place to thank those that gave feedback, and reduce churn as people recognize you’re improving the product regularly.
2) Make all your product emails have a real reply address so you can talk to people
I’m always stunned when companies send announcements and product emails and make them noreply@company.com. That’s a big missed opportunity.
Instead, make it a google group that sends to some of the product team. You’ll get fewer emails than you may be worried, but those that do really care. Your customers will appreciate being able to respond (often saying positive things and showing gratitude!) and with a simple, quick reply, you (or a coworker) can make them feel heard.
3) When you launch a feature based on feedback from a customer, email them personally.
How do you feel when you get personal notes from friends, family, or people you work with? Pretty good, right?
You can do the same for your customers simply by sending them a quick thank you note when their input is acted on.
If you’re a small startup, then this should be pretty easy. Sending 10 thank you’s to those that hopped on a call should take you 5 minutes.
As you scale, this can scale too. If need be, pull the names and emails of those that submitted feedback, had a flagged support ticket, did a usability test, etc and do a mail merge to send all of them a similar form note thanking them. Anything is better than nothing.
You can also enlist your coworkers, like for instance asking your Account Manager to reach out to their customers involved and let the AM share the good news.
This is win-win; it’s less work for you AND the Account Manager looks good to the customer, as it shows they can effectively pass along feedback that gets acted on by the product team.
Doing this not only makes people feel heard, but it also helps you build relationships that create power users and customer advisory boards. The more people feel heard, the more they’ll reach out and make your life easier as a product manager seeking out feedback, problems, and insights.
—
Isn’t this a lot of work?
Yes, this is a lot of work, but you’ll notice quite a bit of this is collaborative. That means you’re sharing the workload. And best of all, your hit rate on features built will go way up, so there’s less drama, more excitement, and you overall become more efficient.
All because you roll up your sleeves and do the work.
Take the time to be a product person who truly cares about their craft and builds processes and paths to directly learn from and speak with their customers. You’ll find that feature voting is then the last thing you’d want when you have all this direct, quality customer insight coming in.
Need help for you or your product team? I can be your coach.
I’m doing a limited number of engagements now helping with getting your first customers and early adopters, overcoming churn issues, and validating new features. You can sign up for a free intro call here, or learn more about what I do here.
For some, it’s shipping a massive feature that really struck a chord in the market. For others, it’s navigating a really complex challenge and finding an elegant solution. Or it could be any number of things like:
Amazing ROI on an opportunity you identified.
The moment you know you’d guided the product to product market fit.
Recognition from the CEO or a mentor you really respect.
After over a decade working in product, I have quite a few of those, and the story today definitely ranks way up there.
One of my proudest moments at KISSmetrics
Way back in 2012, I was the second, 1st PM at KISSmetrics. When I joined, it had been almost 4 months since the original, 1st PM had departed, and at that point, things had gotten pretty messy as no one was really doing what a good product manager does.
For instance, there wasn’t a lot of process, or commitment to talking to customers regularly, nor a way to channel feedback from those that were talking to customers into something actionable for the product team.
Over the course of my first 6 months there, with Hiten’s support, I slowly worked to turn the ship in a variety of ways to get us to be more customer driven. We were already product-led, well before “product-led” was a thing, but as an analytics company, we found it far more comfortable to rely on quantitative data in our KISSmetrics reports than qualitative data from our customers.
That’s why it was a really proud moment when the story you’ll read below describes when every single employee (over 30 at the time) talked to at least one customer that week. It led to one of the biggest morale boosts we had while I was there, and had a huge impact for our customers.
A big win for customers and us
When the KISSmetrics blog sold and some posts were no longer up, I had to rely on the Wayback Machine of the Internet Archive to reference the story of this moment when we got everyone in the entire company to talk to at least 1 customer in the same week.
To ensure this story is preserved going forward, I’m reposting this story as told by my coworker, Chuck Liu, back in November 2012. Everything between the lines is his writing.
Getting Things Done: How Moving Fast Doubled Our Feature Engagement
As a SaaS business, we regularly make improvements in our software product because we care about our customers. We also want to give our customers a competitive advantage with our customer data so they can make better business decisions.
When we started working on our new version of Live two weeks ago, we had a lot of discussion about whether we should rewrite the whole thing or just improve the visual designs. I’ll dive more into that a little later, but one of the big influencers for a rewrite was that we wanted to make a dramatic improvement in reliability and uptime — one that wouldn’t be possible with just a simple design upgrade. What’s a new design worth if it doesn’t work?
Funny thing is, when we finished building Live, our customers said it was fantastic…but still there was something missing. We were not getting the engagement or adoption levels we had hoped for.
What went wrong?
Instead of going back to the drawing board, we kept it simple. We figured we’d waste time making decisions and changing a lot of things. It was going to take too long to plan everything out again. We learned that, a lot of times, all it takes is small changes here and there to get that bump in engagement.
In our case at KISSmetrics, we increased our engagement by making small alterations in design thanks to our customer-driven data. Test quicker, faster, and get more things done. Here’s our story:
Building the New Version of Live
KISSmetrics Live lets you monitor top activity trends, filter for specific activity you’re looking for with a new launch or campaign, and see information for individual customers — all in real time.
When we set out to improve our Live tab (which provides people with a real-time data stream of customer activity), we first looked to our secret sauce — customer feedback.
Thanks to our awesome customers, we were able to define a list of requirements and use cases that our Live tool needed to help customers get their jobs done better and faster.
Some key requirements included:
Reliability*** — Flash was causing all sorts of trouble
A way to drill down on specific people, events, or properties
A better way to view your own activity AND monitor the live stream
Getting into individual customer profiles more obviously
Flash was a big offender. It caused loading problems. The different versions caused different errors. It crashed. Customers were not able to see it at all because of their device. Customers lost their whole session.
The old version of Live, complete with annotations, after customer feedback was summarized by Jason Evanish, our product manager. Oof.
Before we got to any visual design improvements, we started with the back end. If our customers couldn’t use our feature, there would be no point in updating the visuals or functionality. Our engineers did the hard part by building a robust back end that didn’t depend on Flash anymore. They were able to deliver the behind-the-scenes magic that powers our new Live tab now.
With reliability improved, we could confidently move forward and implement the rest of our improvements.
Getting to Customer Needs
What do customers actuallyneed? To help answer this, we started with sketches, mockups, and wireframes.
One of the earliest sketches in our design phase from Eric, our support engineer.
We wanted to work with something low fidelity to show customers’ rough user experiences so we could see if our ideas were actually helping them solve their problems. This allowed us to focus on the jobs customers were trying to get done without having colors and major layouts get in the way of the feedback. It allowed us to differentiate what they needed (ways to filter, search, etc.) from what they wanted (button colors, perfect alignment, etc.).
Another idea from one of our designers, Jason Caldwell, with UI notes.
As a company that helps other businesses get to know their people, it was obvious to us that we needed to keep in close contact with our customers. And we did just that. After several cycles of interviews and testing, we were able to get to a point where customers agreed that they would be able to do the jobs they wanted to accomplish with our new improved tool. So we started building.
Problem Solved! …or so we thought.
Final design that was made by our lead designer, Ian, and implemented. Huzzah!
A job well-done, everyone! Let’s move on to the next thing, we thought.
Not so fast.
When we launched the feature two weeks ago, our feedback box started filling up with messages.
Some feedback messages all about stream activity being too big. Yowza. Thanks to everyone who sent in feedback!
A lot of the initial negative feedback focused on how the stream items were so large that it was impossible to scan for customer activity. Some people even wanted to switch back because it was not valuable without the ability to scan easily!
Luckily, we received positive feedback with regard to reliability, search filters, and trend monitoring. All the jobs were accomplished (yeah!), but we had a design issue to solve.
Here’s How We Got The Crazy Boost In Engagement
Yes, this is the actual metric chart with the huge jump. Since our data is tracked on a per-person basis, we knew something great happened.
The small bump in the middle of the graph was when we originally launched the new version of Live. We saw about a 50% increase in that week alone after an email to our existing customers to check it out and use it over the course of the week where it leveled off.
After the feedback wave, we hustled. We didn’t waste any time trying to come up with a quick change that would alleviate the main problem: customers wanted to see more activity and data in the stream.
What we rolled out a week later as Version 2. We increased how much activity you could see, while maintaining some Version 1 design elements on hover.
In the old design, you could see two customer activities, maybe two and half activities, in the stream. In the new design we came up with, you can see ten activities in the same resolution.
Here’s how some of our customers responded:
Valuable feedback turned into fix. Thanks Pejman!
Happy customer with the new fixes and improvements. Thanks Evan!
Best part? We didn’t do any additional marketing or launch emails when we implemented the new version. Our customers organically started using the feature A LOT.
So What Did We Do?
1. We started with tracking customer data. We made sure we established tracking for our Live tab with KISSmetrics. Tracking on a per-person basis steers you away from dangerous vanity metrics and makes you start analyzing the behavior of real people. One event each from a million people is very different from a million events from just one person.
We also got customer feedback data and made sure their problems were solved by our solutions.
2. With customer data, we were able to look into the whole lifecycle of our engagement patterns, all the way back to the first occurrence, as well as drill down into specific customers, if necessary. We were able to benchmark our performance to measure against dips, or in this case, gains.
3. We made small design changes according to most common customer requests. And we did it fast. It’s hard for any business to get everything right the first time. Or the second time. And so on. If you iterate quicker, you’ll learn faster about what worked, what didn’t work, and how to prioritize what’s next.
What a great story!
Because the company had become really in tune with our customers across a variety of methods (as you can see above, it even included tweeting at Hiten), we were able to understand our customer’s frustrations and quickly engage the whole team in a fix.
As I’ve learned over and over again in my career, if you get engineers and designers hearing the words straight from customers, it motivates them deeply to do their best work that customers love.
And this situation was no different as we quickly fixed the feature to be exactly what customers needed.
With that win under our belt, it became commonplace for everyone to ask what was best for the customer, and to go talk to customers if we didn’t feel we knew the answers yet.
You can do this, too.
Wish your company was more product-led, or your product team was more customer focused? I can help you.
I’m doing a limited amount of product consulting helping product-minded founders and 1st product managers learn and apply all the best product skills I’ve learned from some of the greatest product people in Silicon Valley.
If you enjoy what I’ve written here on my blog, then you’ll love when I get into the specifics of your business to help you accelerate your learning and take the actions that have a big impact…without the years of painful trial-and-error.
How is churn at your company? How has COVID affected your churn rate?
If you’re like most of the companies and leaders I’ve been talking to *everyone* is feeling it. The only question is how much:
The great companies struck oil when COVID hit. Those that help companies transition to remote, support the fight vs. COVID, or do video conferencing are thriving. They’re not reading this post anyways.
The good companies are fortunate to be in healthy markets and they’re approaching 70-80% of their original sales targets. Churn is up a bit, but not life-threatening.
The struggling companies are in markets where some of their customers were crushed, while others continued along. They’ve seen a spike in churn, deals take longer to close, and pipelines are significantly reduced.
The dying companies are in markets that have been crippled by COVID/lockdown. Good luck selling software to sports leagues, travel, in-person entertainment, and hotel industries.
Unfortunately, if your entire customer base evaporated, because the industry no longer exists, there are no churn tactics that will save you. You either hold your breath, hoping to survive until recovery and reopening of the industry you serve, or you have to pivot your business in some major way.
For the rest of us in the middle feeling the sting of churn, and still with chips in the game, today’s post is to show you some of my favorite tactics I’ve learned over the last decade working on SaaS businesses. While there are no silver bullets, there are quite a few things you can do that together add up to make a difference.
5 Ways to Reduce Churn Better than an Exit Survey
A common behavior I see in SaaS products is to have a multiple choice survey when they cancel. This helps you quantify what was the straw that broke the camel’s back.
But does that tell the full story? No, it does not.
A lesson in the hidden truth of churn
When I ran product at KISSmetrics back in 2013, over a few months our churn started spiking, from the healthy, 3-5% range to suddenly approaching and exceeding 10%.
This was obviously alarming, so we put our attention on trying to figure out why.
The first place we looked was at our cancellation survey that popped up when you clicked to cancel inside our product’s account settings.
An example of a churn survey
Unfortunately, this information didn’t really tell us much. In fact, the data we had was pretty evenly distributed across a number of the many options we presented.
It helped us narrow down the causes, but it didn’t come close to giving us the full picture.
Unfortunately, people cancel long after the initial warning signs occur. Often, the survey answer you get is merely the straw that broke the camel’s back, or a quick rationalize after they’ve already decided to quit.
It wasn’t until I applied the below tactics that we found the real, root cause. I’ve also used these same lessons since to help my own startups and those of some of my friends and mentees significantly reduce churn.
1) Check with your Customer Support / Success Team (or help out!)
I am always amazed by the number of SaaS product managers and founders that don’t interact with their customer support teams or help out with support tickets.
As this great Tweetstorm from Podia founder, Spencer Fry, reminds us, it’s a HUGE part of retention and customer happiness.
Customer Success interactions and support tickets are a GOLD MINE for product teams. It can answer essential questions like:
Friction:Where are people getting stuck and confused in the product?
Bugs:What bugs keep happening and bothering customers most?
Requests: What are customers asking for either explicitly at the start of a support ticket, or during an ongoing conversation?
These are great any time, but especially if you’re fighting churn, you can work together to determine:
What support tickets were recently sent by customers who churned this week?
What tickets did they seem to push most urgently about or have a high degree of frustration regarding?
Did they make the same requests repeatedly? What were they?
This kind of information helps you see where there may have been points of frustration in the past that contributed to them leaving. If you really frustrated me, your support team is likely to take the brunt of that, too.
Their friendliness may win me over and resolve the problem, but if that issue made me look bad to my boss, made a report late, or caused me to start a work-around that makes me less dependent on your software…the clock is now ticking on churning from your product.
2) Do a set of Jobs to Be Done Interviews
Many people have learned about jobs to be done over the last few years. Whether you love the milk shake example from the Clayton Christensen’s talk above, or the proverbial “I want to hang a picture, not put a 3/4 inchhole in the wall” story, you realize that people hire products to accomplish something, not for “features.”
What many fewer people know is you can use this same process to fight churn.
Jobs to be done is packed with insights for product teams
The big insight of jobs to be done isn’t just what I’m hiring your product to help me do. It’s also the above timeline to help you understand their journey from “passively looking” to “deciding” to “finished.”
There’s a tremendous amount you can learn as a product manager or founder doing these interviews with new customers (paid you for the first time in the last 45 days).
This can inform your marketing, copywriting, onboarding, and positioning throughout.
It can also help you with churn.
Flip the script. Create a churn timeline.
Just like there is a timeline for buying, there’s a timeline for your customer deciding to cancel.
Mapping it to the above timeline, here’s how it looked when I did this for a KISSmetrics customer all those years ago:
First thought: Over lunch, a director of marketing tried to run a report to check a number. It took about 10 minutes for it to complete. It was annoying, but they brushed it off.
Actively looking: A month or so later, the marketer tried to run a report when they first got into the office in the morning. Again the report hung. They left the browser open hoping it would finish later. It was still not complete when they left work that day.
Deciding: Unable to get a report they needed, and complaining in the middle of the office, a coworker suggested they try another system that had always worked for them. The marketer listened and started trying another product to see if they could get the numbers they needed.
Consuming: The alternative product offered them a strong discount, which then made canceling a no-brainer. Meanwhile, our cancel survey for this user cited price, which was only part of the picture.
As it turned out, in this interview, and many others like it, the key cause for our churn was performance related. It’s little surprise that around that time Mixpanel started running brutal adwords against us:
Understanding the timeline of your user’s journey to canceling can make all the difference in preventing churn. Jobs to be done is the single best way I know to do it.
Great product managers know that to truly understand your product requires both qualitative and quantitative data. You need to understand the stories of your customers (qualitative data) and you need to understand the size and scope of things happening (quantitative data).
This of course applies to understanding churn as much as anything else. Look at your churned customers’ product usage and ask questions like:
What features were they using vs not, or stopped using?
What features are customers with a high retention rate using that those churning are not?
Are your customers making it past 90 days of successfully using your product, or are many of your churns happening shortly after subscribing?
Understanding what they couldn’t get done with your product, or never learned to use can be telling. Every company’s churn problems are a little different.
Personally, I would recommend you start with the Jobs To Be Done interviews, so you have a baseline of stories of what’s going wrong for your customers. From there, you can use analytics to tell you:
How big and common are the problems I heard in my interviews?
Which of the problems is likely to have the biggest impact?
Having a mix of qualitative and quantitative information about what’s happening with churn will help you not only better understand why it’s happening, but also prioritize the many solutions you think could help.
We made this addition to our help doc on how to cancel when COVID hit
4) Make COVID specific offers
These are unusual times and budgets are tough. Even the most loyal of customers have to cut products that are not life-or-death essential for them when they’re also having to cut staff.
The best thing you can do then is to think long term. Ask yourself how you can create win-win opportunities and build a long term relationship with your customers.
If you help them out in a tough time, they’ll be there for you for the long haul. Never underestimate the loyalty of a customer you went above and beyond for.
So how do you do that? Well, if you’re a product manager, you’ll likely need to get other departments and leadership involved to make any of these calls, but here’s a few for starters that many companies have already implemented:
A few months free: Especially if you’re a business that does “land + expand,” the last thing you want to do is lose your “land.” Give your struggling customers a brief reprieve, especially if they are high value or high potential.
Discounts for Case Studies: Case studies and testimonials give your company more credibility in a market. Use our present circumstances to ask more companies and customers for testimonials and case studies in exchange for flexibility on pricing and terms.
Pause accounts: Rather than immediately deleting data when people cancel, agree to pause their access and to check in at a pre-determined future date to reactivate them.
Whatever you offer, make sure you listen to your customers; they may have questions or concerns about some of your offers, which can help you either provide something different and better they prefer, or clarify your offers to avoid objections.
Remember: it’s easier to get an existing customer to spend more money in the future than it is to acquire a brand new customer. Anything you can do creatively to create win-win scenarios and keep your existing customers around is going to pay dividends for you and your company.
5) Think about Olsen’s Hierarchy of Product Needs
Dan Olsen is one of the original Silicon Valley Product Leaders. He was VP of Product at Facebook predecessor Friendster, and has since become a long time advisor and consultant on all things product management.
One of the great concepts I’ve heard him speak about is translating Maslow’s Hierarchy of Needs (see picture above) into a version for software products:
Much like Maslow’s hierarchy, Olsen’s hierarchy starts at the bottom and subsequent steps in the pyramid only matter if the ones below are taken care of.
Applying this to churn you can imagine:
Uptime: If your product is down (or a key API from a 3rd party), your customers cannot use your product and will churn because they can’t accomplish what they set out to.
Page Load Time: If your product is too slow, you’ll frustrate your customer as I learned the hard way at KISSmetrics.
Absence of Bugs: When things don’t work as expected, or inconsistently, again you’ll frustrate your customers, which makes them reduce how often they use your product, or stop using it altogether.
Features: Are your customers able to accomplish what they set out to do with your product? Whether they don’t know how, need advanced functionality, want a complimentary feature to justify the budget for you, or require a specific integration, listen carefully to them.
Usability: If people struggle to find the things they need to do in your product, or don’t understand how to use it, they won’t stick around long term.
If you’ve been doing the early tactics I’ve written today of interviewing customers, talking to customer success, and looking at your product analytics, you should start to see some patterns in where on the hierarchy your company’s biggest problems are.
Then, in addition to mapping and grouping your problems, look to the hierarchy as a guide to the priority of the fixes and improvements you will make.
If your product is bug-filled, slow, or has significant uptime issues, then no amount of usability improvements or feature additions will matter. It starts with a strong foundation.
BONUS: More lead bullets for churn
The 5 recommendations above are how to address big churn issues and make a real dent in the problem long term.
While you dig into the hard work of applying the above tactics, here are some quick hacks that can help you and your company with smaller needle movements on your churn rate:
Set up Good Dunning Resolution: Expired credit cards and failed charges are the bane of any SaaS business. Pro-actively reach out ahead of time when customer credit cards are expiring, and when a charge fails. Stripe has features you can turn on to automatically help with this.
Show Product Momentum: Especially for early stage companies, sending regular product updates help customers feel like you’re continuing to get better, even if you don’t always fix or add what they specifically want.
Apologize for Big Mistakes: Your customers know if you messed up. Hiding from it only hurts your credibility, so if you have a major outage or downtime, be transparent about it. You may be surprised how customers may even offer to help! Learn how to send a great product crisis email here.
Push for Annual deals: Fun fact – If you pay up front for 12 months, you can’t churn for 12 months ;) Make it a win-win for you and your customers by offering a discount versus paying monthly.
Add a Slipping Away Message: One of the first great innovations Intercom did was to allow you to easily trigger a message after N days to try to recover lost customers. Try setting one up after 25 days of inactivity and tell them about your 3 most popular features.
Each of these tactics alone will not solve your underlying churn issues, but they will help reduce the number bit by bit. Also, as you learn more about your customer base and their motivations, you’ll see smarter ways to apply your insights to engage them and fight churn.
What are your favorite tactics to fight churn? Leave a comment to share what you’ve learned with others.
It’s hard for me to believe, but I’ve been working in the software tech industry for 10 years now. For the vast majority of that time, I’ve either been a product manager, or a founder with a heavy focus on product.
With the trend on Twitter of 1 like = 1 insight or spicy take, I decided to jump on board the trend and do one on product management. It appears to have resonated:
Should I get in on the 1 like = 1 take (max 100) train and tweet about product management?
10 Likes and I'll start a thread of product tips and 🌶️takes.
The trick to tell if there’s a reply to a tweet is to look at the speech bubble in the bottom left corner of each tweet:
If the tweet says 1 in that area (like Tweet 2/), then the only reply is my subsequent tweet in the thread. If it’s more (like Tweet1/) then there are replies to click on and see.
Anyways, let’s get onto the takes:
1/Â Being a PM is a job of influence. The best PMs are the mayor of their area of work. You need to be able to build coalitions, and get buy in from a wide group of people.
That doesn’t happen by accident. It takes work.
2/ The best PMs are autodidacts. They’re constantly curious and always learning.If you don’t like learning lots of new skills from sales, to marketing, to negotiation, to EQ, to design, don’t be a PM.
3/Â PMs are also like a point guard playing basketball. Done right, they set up many others to look great.A strong collaboration makes your designers create better designs, and the engineers ship a better product faster. Those assists don’t show in the score sheet but matter.
4/Â PMs also are limited by their team. If you are missing key players or have weak players at other positions, it will often look like the PM is weak, because they have to cover or fill in gaps.Two of the toughest are PMs w/o good design help or lacking a good tech lead partner
5/Â There are many ways to become a PM. You cannot major in product management, so everyone gets their start different ways.If you think you want to be a PM, look into how people you follow did it. You may be surprised how varied it is.
6/Â The best ways to become a PM:
A) Excel at a growing company & ask to transition (seen it work great for marketers, customer success, design, & engineers)
B) Do a side project or startup to show you can PM (this eliminates the chicken or egg problem of having never been a PM)
7/ Getting an MBA won’t help you become a good PM.It won’t make you a better PM if you already are one, either.If you want to become a GM at a company, an MBA makes sense, but it doesn’t help product managers.
8/ I’m sure the previous tweet is going to get some replies from a Sloanie, HBS grad, or Stanford MBA.As is always the case on Twitter, exceptions always get mentioned, but do not disprove the general statement. Save $200k if you love PM and don’t get an MBA.
9/Â Most of the worst PMs I know or have heard about are either former engineers or MBAs.
– MBAs often bring ego + don’t want to do the real work (talking to customers, iterating, etc)
– Engineers can struggle with the interpersonal & relationship building side of PM’ing.
10/Â If the sales team is at war with your product team, or people try to go straight to your engineers for pet requests, those are your fault.The #1 mistake that good PMs make is not building relationships across departments. Fix it with peer 1 on 1s: https://jasonevanish.com/2015/09/24/product-managers-peer-one-on-ones/
11/ The #1 mistake mediocre & bad PMs make is not talking to customers.It’s scary getting outside the building, and they instead choose to be master BS artists.If this is you, change your ways in 2020. I wrote how-to’s I wish I had when I started: https://jasonevanish.com/product/
12/Â There are 31 flavors of product managers. An A+ PM at one company would be terrible for another company.If you’re hiring, recognize this could explain a short stint on a resume, and if you’re job hunting, don’t apply to PM jobs that don’t match your skills & strengths.
13/Â PMs fit differently based on a variety of factors such as:
– The business model (Ecommerce vs. SaaS vs. Ad tech are dramatically different jobs)
– Company stage (Think public company vs. Series B vs. Seed)
– Company culture (How are decisions made? What do they value?)
14/Â The interview process for product management is completely broken.Â
15/ There would be no need for a whole market for products to “Master the PM Interview” if the interview process was actually good at most companies.
16/ The best interviews see if you can do the work *you’ll be hired to actually do.*Unfortunately, most PM interviews are veiled in hypotheticals that have nothing to do with the job, and are basically trick questions.Mastering trick ?s has nothing to do w/ being a good PM.
17/ Most product teams don’t check their applicant tracking system nor respond to applicants who apply cold.This is ironic given the trend of calling PMs “Mini-CEOs”, and recruiting is one of a CEO’s most important jobs… 🙄
18/ If you want to get a response on an application, get an intro into someone on the team.Don’t have a network? Search LinkedIn for lower level PMs. No one asks them for help, so they’re more likely to respond & have a call/coffee to discuss the culture, then refer you in.
19/Â The first PM hire at startups is almost always a sacrificial lamb at the altar of learning for the founder.Read more why and what to do about it here: https://jasonevanish.com/2019/04/28/second-1st-pm/
20/ The best job if you love startups is to be the *2nd* first PM hire, as you get all the opportunity, equity, and influence…all thanks to the PM that came before you.They died on hills, and helped the company learn what they actually wanted.
21/ Most customers don’t report bugs or give feedback.They just quietly suffer, or churn and then maybe tell you.Â
22/ I follow the “Rule of 10:” If 1 customer has an issue, there are probably 10 more that didn’t say anything.Â
23/ If you have an issue, get in the habit of sending a note to those affected. It’s good service AND it helps you quantify issues.I’ve had many engineers be surprised when they see that 2-3 tickets is actually affected TONS of users. Getting a list to email helps quantify it.
24/ Customers don’t care how hard (or easy) a feature was.All they care about is if you solve their problem or make it possible for them to do what they want to do.
25/Â Quick Wins (aka – simple things you can do to make the product better for your customers) is a great way to let your team recharge and build some momentum after shipping a big feature.Sometimes customers are more excited by this than your big feature.
26/Â Product/Market Fit exists for both buyers and end users.You can have one and not the other, and it will cause your business to sputter.
27/ Never become a PM at a company where the founders don’t understand what a PM does. You’ll get no credit for wins + all the blame for any problems.Fateful last words include “that feature went really well, but I have no idea how you contributed” & “Why can’t you just…” 🤦‍♂️
28/Â Jeff Bezos was right when he said this:
“The thing I have noticed is when the anecdotes and the data disagree, the anecdotes are usually right. There’s something wrong with the way you are measuring it.”
The problem is most PMs don’t talk to enough customers to tell this is the case.
29/ There’s nothing like doing product management in Silicon Valley. There, PMs are mostly considered vital and valuable parts of the company. This changes who does the job, and how they work.
30/Â If you want to be world class at product management, you need to work a few years in Silicon Valley for this reason, and many more.Being around that many product obsessed, super smart people, will level you up rapidly.
31/ A long time product consultant in NYC told me, “NYC product is 20 years behind the Valley.” That feels directionally accurate.I think there are *many* smart, great PMs in town, but it’s structural/cultural issues that undervalue product here: https://medium.com/@Bosefina/how-to-be-a-product-driven-company-in-nyc-342fd689877e
32/ The mascot of NYC PMs would be Eeyore.The amount of self deprecation I’ve seen/heard that really feels like “haha, it’s funny, but I’m actually sad about it” has been one of my biggest surprises.Product is undervalued in many cases here!
33/ One of the hardest remote jobs is being a PM.Collaboration and innovation are where the magic happens, and that’s the greatest weakness of remote work.There are ways around some of it, but it takes a lot of conscious effort.Â
34/ If you’re a remote PM, use any flights or face time you get to try to solve your biggest challenges.Nothing remote can compare to the energy of being in the room at a white board with your designer and engineer(s) working on a problem.Â
35/Â Also document, document, document, and share, share, share.You can’t walk by your pod and tell them about a great customer interview, so you need to find other ways to share what everyone needs to know…in a light weight way they’ll actually read/see.
36/Â On the flip side, remote can help bring out some of the best work of your designers and engineers as they can more easily get into deep work and focus.Try doing that in an open office…
37/Â The #1 skill to develop to be a better PM is to become a better writer.
38/Â Writing touches everything you do as a PM:
– Product specs
– Updates to customers
– Updates to stakeholders
– Note taking in meetings
– Notes and takeaways from customer interviews
– Writing good survey questions
– Communicating to your team
39/Â To become a better writer as a PM, write more:
– Blog posts
– Internal documents
– Tweets + Tweetstorms ;)
– Personal notes to collect and organize your thoughts.
– Emails and experiment with templates you use.
40/ The other way to become a better writer is to read more. Read regularly, and you’ll find your vocabulary gets stronger and you always learn.
41/ My favorite books to help you write #1: Tested Advertising Methods amzn.to/2sHa6OH
– Copywriting goes everywhere from the marketing site, to help docs, to inside your product
– You probably have to write some of that
– The lessons apply beyond that
H/t @LarsLofgren
42/ My fav books to help you write #2: Never Split the Difference amzn.to/2Ff5HoL
– You do a lot of negotiating as a PM. This teaches you a better approach whether working with an angry customer, negotiating with another team for resources, or deftly handling your boss.
43/ My favorite books to help you write #3: How to Win Friends & Influence People amzn.to/2ZJOLQG
– PMs are in the people business and this is the gold standard to working well with other people. This applies as much to what you write as what you say.
44/ The best way to earn respect from an engineer is to have data to back up what you tell them. Show them the customer interviews & quotes, or the analytics/data and you’ll engage them much more in what they’re building.This wins many more people over than a batle of opinions.
45/Â The easiest trap to fall into as a PM is to ship things and never check the results of your work.Set a reminder for yourself 2 weeks or 2 months (depending on your company stage) later to go back and see what worked or didn’t.Â
48/ I follow the “Estimation Rule of 2X:” Any project’s estimate is always off by 2X.
– When it’s 2 vs 1 day, or 2 instead of 1 hour, it’s not a big deal. However, the bigger the project, the more brutal this becomes (4 weeks vs 2 weeks, 4 months vs 2 months is a problem).
49/Â PMs should be tool agnostic. Whatever your engineers will actually use and keep up to date is the project management tool you want to use.The tool you love for the burn down and gannt charts is not the hill to die on if all your engineers hate it.
50/Â “Your startup either dies, or lives long enough to end up using Jira.”
This saying I used to hear 5 years ago still seems true.Â
51/ PMs should be infinitely curious. If you see something you don’t understand you should want to investigate.
– Look into the analytics, ask the engineer to explain why, ask what motivated your designer to go that direction. You’ll learn, and it often sharpens their thinking.Â
52/ If you’re a Senior PM or higher, you should be mentoring people inside and out of your company.It’s great to give back AND it will make you a better PM.
53/Â Every time I help someone as a mentor, I walk away with a few new ideas and usually a reminder of a few things I know I should do that are slipping.
54/ It’s never been easier to get a mentor. A few ways people have reached me, and I’ve gained help:
– DMs on Twitter
– Well crafted Linkedin messages
– Cold emails after they read my blog and found my email address on there.
– Replies to blog post emails from subscribers.
55/ Creating a bonus structure for PMs is a very risky move*. If your company’s needs to change, you want PMs to be flexible, but that’s hard to convince them if their bonus says otherwise.* Exception = E-commerce it can work since it’s easier to have a consistent target.
56/Â Being pedantic is a terrible trait for a PM.Care about the details, but in a tactful way. Know what hills to die on, and how to have both strong opinions, *and* loosely hold them.
58/Â Being a founder, even if your startup fails, makes you a much better PM.
– You appreciate other roles more as you likely wore their hats
– You learn to ruthlessly focus on the metric that matters most
– You learn to deal with extreme constraints & the creativity that breeds
59/Â A good PM is like glue & grease:
– Glue to hold things together and fill in gaps
– Grease to make things run more smoothly and adapt to changes
60/Â Feature voting tools are for mediocre PMs.
61/ Show me a feature voting site for a product and I’ll show you a graveyard of unanswered customer requests and a lot of noise.
62/ Show me a product team that relies on data from feature voting, and I’ll show you a team that thinks they know their users a lot better than they actually do.Some day I’ll finally turn this into a blog post it deserves:
Cool to be able to better track and organize what comes in via Intercom for PMs, but feature voting is terrible product management.
63/ Companies that struggle with endless debates about their products and roadmap typically are arguing opinions, which ends up creating lots of politics and the most important person in the room making calls.
64/ Companies focused on their customers settle their debates one of two ways: 1) They ask “What’s best for the customer?” 2) They plan an experiment or table the discussion until they get some data/evidence
65/Â Disagree & commit is an essential skill for any PM.You need to do it sometimes, and so does everyone else on your team.The key to avoiding resentment is to measure the results of the decision. Everyone is wrong sometimes, and that’s okay as long as you fix it later.
66/ Great product leaders are unsung heroes: Their teams get all the credit if it works, and if it doesn’t, they are the ones to have to answer.
67/Â Getting customers to talk to is hard and interviewing them is time consuming, which is why so many PMs rarely do it.
68/Â Getting customers to talk to you is a team effort:
– Get customer success to forward you customers with issues in areas you’re fixing
– Reach out yourself (email, @intercom, etc)
– Partner with marketing on surveys & reach out to interesting answers.
– Talk to sales leads
69/ Joining a company to change their product culture is like signing up to climb Everest in shorts.It may be possible, but there’s a good chance you’ll die trying.
70/Â Product managers pre-product/market fit have a 10X harder job than those post-product/market fit.
71/Â The stronger the product/market fit, the easier it is for any product manager to look smart and deliver wins.A lot will be obvious, and in many cases, anything you build will work.
72/Â Being hired as a PM to help a startup with a solution looking for a problem always leads to failure.The power dynamics and negative inertia are too great. Also, the founders should have been figuring it out, not a hired gun with 0.5-2% of the company.
73/Â Some PM jobs are really project management jobs with a power struggle left off of the job description.
74/ Sharing wins and happy customer quotes are great ways to give your team a jolt of energy.We have a Slack channel dedicated to it at Lighthouse called #HappyManagers specifically because of this. Anyone can scroll through to read stories, quotes, and testimonials.
75/ When something is broken, the best way I’ve found to motivate a designer or engineer is to share the customer’s words directly.It’s one thing when you say it, but when they hear a customer say it, it hits their ego differently in a good way so they want to fix.
Side note: My favorite story of exactly this happening was also one of my proudest moments as the PM at KISSmetrics: web.archive.org/web/2012112303…
76/ Beautiful designs aren’t always usable or accessible designs.
77/ The #1 thing I’ve always had to remind designers I’ve work with is “Do you think a 50 year old with bifocals can read that”?
78/ McDonald’s theory is a great way to get your team unstuck:Suggest something you know will be rejected to get you back on the track of what you all do want. medium.com/@jonbell/mcdon…
79/ Harsh truth: The best products don’t always win.Sales & Marketing machines can be just as dominant, if not more so.
80/Â In some markets, adding more features to demo & put on your pricing checklist is more valuable and important than any of the features being particularly good or useful.
81/ Tech debt doesn’t matter right until it might kill you.
82/ Adding another feature won’t help your company win if the ones you already have are broken.
83/Â Tech debt is rarely talked about publicly, but many well known startups (both successes and failures) have faced major reckonings because of it.
For example:
Mute me for a bit if you don’t like long diatribes about startup debacles but this reminds me of a story (1/n) https://t.co/lHuAF0ruOK
85/Â My favorite way to pay down tech debt is to revisit/iterate on old features. This way you squeeze in a few quick wins (remember tweet #25?) along with fixing a troubled, decaying part of the product.It also helps keep the engineer(s) working on it thinking about customers.
86/ I knew @SlackHQ Channels could help with customer bugs and issues, but I was pleasantly surprised how well it also works to source customer development & product feedback fast.This is an amazing post on the topic from founder/CEO @stewart: https://slackhq.com/shared-channels-growth-innovation
88/Â The best way to iterate on your process is to make it a habit:
– Post Mortems (even when things go well)
– Peer 1 on 1s to get individual/private perspectives
– Ask for feedback after a ticket is closed (What can I do differently to make that easier/better next time?)
89/ The best way to scale being a customer driven company is to get everyone involved.You can’t be everywhere, but you can teach bits and pieces to others. Teach them how to ask a good followup question over email, or to do some of their own interviews.
90/ You need thick skin as a PM. You will fail and need to find another way. You will take more blame than you probably deserve.I’ve interviewed and been rejected by more companies than you’d ever guess. Lost many deals. Been flaked on by customers over and over. It happens 🤷‍♂️
91/Â Focus groups are a disaster. Customer development is *one* customer at a time.You need to hear their individual stories and situations, not group think.
92/ Remember what Steve Jobs said on simplicity:“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end”The best solution is usually not the first idea. Keep pushing to get it right to unlock magic.
93/Â Sometimes the best move is to kill a feature, not add another.
94/ My favorite way to learn is to read based on the biggest challenge I’m currently facing.This insures you immediately apply it to your work…and I find also motivates you to finish reading faster.I’ll share some good places to start after #100
95/ The product tours industry feels universally overpriced.None of them show you how to calculate ROI for what they charge, and typically it’s a small part of successful onboarding + educating users.
96/ Onboarding is really hard.- Customers don’t read.
– They skip overviews and tours.
– They quickly get bored of videos…then complain they “don’t get it.”And it’s still your job to help them get to the AHA! moment.
97/ The best way I’ve learned to make onboarding work is to use a lot of “lead bullets” mixed with experimentation.A little bit of everything makes it so there’s something for everyone.Ideally, you’ll simplify & help them focus on 1 thing, but that can be resource intensive.
98/ @intercom is the best product category for startup PMs since the development of modern analytics changed how we measure and made data accessible to everyone.
99/ Some mistakes you can learn from others and avoid. Others end up being learned the hard way.Be nice. What’s obvious to you may be a difficult lesson for others, and vice versa.This is especially true in product given how varied all our backgrounds are.
100/Â Time management is a crucial skill as a PM; know where all your hours go every day & make sure you get the important stuff done.This video is a great way to conceptualize that:
Further Reading:
Want to learn more PM skills, my reply here gives a few people to start with:
– Read lots of books. My favorites by category here: https://jasonevanish.com/bookshelf
– Rafael Balbi: Who are some great PMs you regard from the west coast? I’ve been interested to learn more about these differences.
Search for their blogs and you’ll find gold mines.
I’d also add that part of it is company structure / culture, not a difference in skills. It sets you free to do things that in a different structure and valuing of product that wouldn’t allow or would be serious upstream swimming.
I’ve dedicated the last 5 years of my life to helping people be better managers.
If you have a big team to manage, sign up for a trial to make your 1 on 1s organized, motivating, and accountable, or tell your eng. manager to check us out:Â getlighthouse.com
Learn something? Give this tweetstorm a Retweet or a Share:
Should I get in on the 1 like = 1 take (max 100) train and tweet about product management?
10 Likes and I'll start a thread of product tips and 🌶️takes.
What does your sales team think of you? Does customer success enjoy their conversations with you? Or do you feel animosity and tension with them?
And what about with customers?
How about the squeaky wheel who sends in feature requests regularly, or the enterprise customer with contractual promises?
Product management is about relationships.
One of the biggest mistakes I see otherwise good product managers make is not managing internal and external stakeholders well.
Rather than building collaborative relationships, where everyone feels like they’re on the same team heading in the same direction, they sow seeds of tension.
As a product manager, any communication issues fall on you. It’s your job to build bridges, even on challenging terrain.
You can do that through a variety of tactics:
Product advisory boards, and regular check ins with key customers.
Peer 1 on 1s with key sales, customer success, account management, and other department leaders.
Regular updates, training, and collaboration on collateral creation for new and updated features.
Throughout those conversations, both internally and externally, there are two words to always remember: “Not yet.”
Let’s dive into the nuance of how 4 letters can make such a big difference…
“Not Yet”: The Two Most Important Words for Product Managers to Use
Remember when you were a little kid and you wanted something and you asked your mom or dad? How did you feel when they said “no”?
Chances are you were pretty unhappy.
We’re not so different when we grow up.
Just say no…to saying, “No.”
As a product manager, when you tell customers and colleagues, “no”, it creates problems for you now and in the future.
No is denying what they want.
No makes them feel unheard.
No is a wall between you and them.
And most importantly, no is the end of a conversation.
Where do you go after you say, “no, we’re not doing that”? You can possibly explain why, but the other person is likely already thinking about how they can either convince you to change your mind or tuning you out in frustration.
The Power of “Not Yet”
Four letters. That’s all that separates “No” and “Not yet”, but in reality it makes all the difference.
Not yet is, “we might do that down the line…”
Not yet is, “I hear you, but…”
Not yet is hope.
And most importantly, not yet is the start of a conversation.
“Not yet” builds empathy
If you’ve ever learned about the power of using “and” instead of “but” in conversation, you know that a simple change in word choice actually leads to a larger transformation.
By changing the word you use, you change the entire nature of your discussion the rest of the way.
When you say, “not yet,” it lends itself to explaining why. This is powerful because it helps them understand the choices you’ve made.
When it’s an internal stakeholder, explaining why can help them see the other priorities. I’ve lost count of the number of times that once I’ve explained what we’re doing right now already they suddenly are willing to wait on their request; you may even be working on something important to them.
Meanwhile, with customers, it’s an opportunity to build excitement and engagement. Maybe you can’t give them what they asked for right away, but you can tell them about some other things in the pipeline.
Often, a couple of the things you’re doing are also important to the customer. You can then offer them the opportunity to provide feedback on the feature as it’s developing, or early access. Either way, it ends up feeling like they’re coming away with something, even if it’s not what they originally asked.
Show your work.
A key part of all of this is that you’re showing your work to others. You don’t need to explain the whole roadmap, but even a small snippet can help people see there’s a solid foundation to the decisions you’ve made. It also demonstrates the hard work and rigor of the product team:
Data driven: Good PMs know their numbers, so you can explain to them how the feature they asked for may have a much smaller impact than the current features you’re working on.
Customer focused: Whether you have an enterprise contract with deadlines due in 30 days, or are finally delivering on the #1 most requested feature, showing that what you’re doing is backed by real customer insights shows you’re a PM that listens to customers.
Strategic: Great PMs see the big picture, and help others see it, too. Concisely explaining strategy comes with practice, so use these “not yet” conversations to practice clearly explaining how the new API opens up thousands of leads a month, or how the onboarding improvements will drive more revenue to hit key company goals.
When you show some of your cards to your colleagues and customers, you help them understand your decision making process. While they may not always agree, they’ll often respect the decisions you’ve made a lot more than when all they heard was, “No.”
In my experience, when you show you have data, strategy, and customer insights backing up your decisions and bets, your colleagues and customers will trust you. Just like they expect you to trust them to do their jobs well, they’ll see plenty of evidence to believe in you as well.
Save your relationships!
This may seem like a small thing, but I can tell you from experience, it matters a lot. No may feel like the expedient way to handle requests, but it comes with a long term cost.
Over time, saying “no” leads to resentment and may sour relationships. People you want to partner with to make launches successful and for everyone to hit their numbers suddenly avoid you, except when they want to demand and override your No’s. They may even try to go around you and talk straight to a designer or engineer to get what they want.
And since you represent the product team, it can even lead to inter-departmental drama and rivalries. Rather than engineering and sales being partners, they become enemies, with each side criticizing the other. I’ve seen and heard it too many times, and it’s really the fault of product managers on those teams for it becoming like that.
You can avoid being that kind of cautionary tale by taking the time to regularly communicate with other teams, stakeholders, and key customers. When you meet and talk with them, remember to use “not yet” so those relationships flourish and they understand your decisions.
Never underestimate the power of using the right words.
5 Ways to Reduce Churn Better than an Exit Survey
