Posts with strategies and tactics on building great products and how to be a better leader
Author Archives: Jason Evanish
I'm the CEO of Get Lighthouse, software that helps you be a great manager.
A few of the right habits can make all the difference to have a great relationship with your team and get the best performance out of everyone. That's why we built software to help you do those things (GetLighthouse.com) and to measure how you're doing with your team (GetLighthouse.com/managerscore)
In addition to building Lighthouse with an awesome team, I'm an avid reader, active athlete (soccer & ultimate frisbee), scotch drinker, and enjoyer of all that the beautiful city of San Francisco has to offer.
Being a product manager is tough. No one majors in it, every company seems to want something different, and most learning comes by a combination of on the job trial & error, and reading blog posts.
Over the years, I’ve tried to share the most practical, actionable lessons I’ve learned from mentors and my own experiences. I hope a few of them have helped you along the way.
It’s also why I’m excited to share I’m starting a podcast with the same mission: teach others how to be great product managers.
The Practical Product Podcast
In the coming weeks and months, you’ll be hearing from many of the experts that helped me learn some of the most important skills I’ve written about here and tweeted. You’ll also hear from guests I’ve coached and gotten to know.
Each episode we’ll focus on a key challenge product managers face, or a skill they must master including topics like:
How to write a product spec your team members actually want to read.
What it’s like being a 1st Product Manager and pitfalls to avoid both as a CEO hiring them, and the Product Manager considering such a role.
How do you get your first 10 customers for a new product?
The broken hiring process for product management
Why feature voting apps are terrible and what to do instead.
…and much more.
Most importantly, we’re going to help you know exactly what to do, because what would “Practical Product” be if not all about putting what you hear into practice?
You can listen to our first, teaser episode here, and click the Subscribe button to find us on your favorite podcast platform so you never miss an episode:
Hear every episode as soon as they drop when you subscribe to the show on your favorite podcast platform here:
“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.
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!
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:
As a product person, it can be hard to use software. While you understand how things work (and can be great tech support for your family), you also see all the flaws (and potential) in the software you use.
That means it’s more common to use software and think, “I wish they’d just…” instead of enjoying it.
Yet, every once in a while, an app comes along that really gets it…
Years ago, I had a tribute post drafted to my favorite calendar app ever, Sunrise.
With this in mind, today, I’m writing about an app that’s great now, so we can all enjoy and recognize what makes it great while it’s here (and at its best).
Thankfully, I think Superhuman is here for the long haul given their major fundraising, and the fact that unlike Sunrise, they’re charging for their product, so have revenue to keep going long after VC money runs out.
Yet, a good survey would mean nothing without action to go with it, which they nail as well.
2) Awesome Onboarding
One of the challenges of SaaS is understanding your audience. Some people *really* want to talk to someone before buying, while others just want to get into a product and explore.
Superhuman is targeting busy, email-heavy users, so time is precious. They had the foresight to realize that by onboarding everyone with calls, they save a ton of questions, headaches, and missed opportunities later.
Now, I’ve seen some companies try to emulate this, but throwing someone on a call is far from enough to make this a worthwhile use of time.
In the 30 minute onboarding, the person on the call did the following which really made a big difference by doing all of these in this *exact order*:
Reviewed my survey answers beforehand so that they didn’t have to re-ask those questions
Asked me a variety of followup questions about what email tools I use, my biggest pains and frustrations around email, and how I thought I might use Superhuman
Showed me the most important features to me, then some general power ups they thought I might like
They had me try out the features, because they had already asked me to install before the call
This had an immediate huge impact on me:
I felt heard, not sold to.
I was immediately ready to cancel a few other tools I was individually paying for (like Yesware), because I knew how to do it in Superhuman
I knew how to use the product for the most important features to me, not just what they assumed I’d like
Their onboarding person was super friendly, which gave me a positive opinion of Superhuman as a whole, while putting a name and face to the company
All of this made the “put your credit card in” a no-brainer, and I was tweeting how great Superhuman was within a few weeks.
If you want to have similar results, you need to start by asking if your product fits an audience who wants to talk to someone. Then, be very careful to create similar steps around the prep, questions, and how you demo the product.
Your demo will absolutely fail if you start with jamming features down your potential customers’ throats with little or no considering for what your customers want.
3) They take referral programs to another level
Now, many products will let you invite a friend. All bottoms up (aka- product led) SaaS, and any network-effects driven consumer app will ask you to invite your friends. Some will even be outright predatory asking to grab your whole list of phone contacts.
Fortunately, Superhuman is a breath of fresh air in this regard.
Now, as the tweet above explains, they started with a simple email you cc to the CEO, but now have a nice, simple, and fast workflow (just like so many other things in Superhuman):
Here the referral flow lets me start typing anyone in my contacts I want to invite, and then it also recommends people they think would be most interested:
Friends and contacts that are on the waitlist
People on my team and in my company
Those suggestions are a great bonus, which led me to not only invite the person I had in mind, but also to add a few people on the waitlist I was happy to help get off the list.
But it doesn’t stop there. With the referral, it generates an email they both get, which allowed me to give their onboarding specialist more helpful info:
As I’ve been a customer for a couple years, I’ve seen how they iterated to this. It started with just the email to the CEO, but now they automate big parts of it, while still keeping some of the personal touch available. Paul Graham and his “Do things that don’t scale” post would be proud.
4) Feedback done the right way
One of the key things about everything that Superhuman does is that it personalizes. While some of their onboarding survey asks multiple choice questions about devices and operating systems, much of it is open ended.
The same is true for their Feedback.
All you have to do is click a little button in the bottom right corner and shoot them an email:
Now, if you read my recent post, you know I hate feature voting apps. The key takeaway from it is you don’t really get the voice of the customer that way, and you frustrate your customers in a variety of ways.
What Superhuman does here is so much better:
It gets my feedback in a clear fashion in my own words.
Because they actually reply to every message, as a customer, I feel heard.
Their replies often ask for more context, bringing further understanding and information.
Now, you may be thinking, “Jason, that’s sooo much work! We can’t do that.”
And you’d be wrong.
All product feedback on Lighthouse gets passed to me, and through a simple tagging system, I’m able to keep it all organized despite spending less than an hour per day on all support requests for our small team.
And at scale, Superhuman has managed to stay organized, as recently tweeted by their CEO when they had a new GPT-3 application analyze all the feedback they’ve received:
It’s initially a bit more work to set up this process, but as you can see in the quality of the Superhuman product, it’s well worth it in building better features, and having more passionate, engaged customers.
5) Teaching you as you use the product
Before Superhuman, I was not a keyboard shortcut guy at all. The only things I knew were CMD+TAB and CMD+` which allow you to change windows on your laptop.
With Superhuman I now daily use:
e – to archive an email
c – to compose a new email
esc – to leave a window I was composing an email in
cmd + enter – to send an email
cmd + k – to do a million magical things
And what I like most about Superhuman is how they keep teaching me more keyboard shortcuts. Basically any time I hover, or do something manually, they’re letting me know, “hey – there’s a shortcut for that!”
This is really clever product development, and it permeates all over…including in their catch-all CMD+K:
This is the definition of product craftsmanship.
Building new habits is hard, but this approach makes it easier as you get reminded over and over what the correct name of the command is and what the shortcut is.
And since Superhuman is a native app on my computer, they know what I’m typing there, which likely means they were able to analyze mistaken/frustrated entries in CMD+K and figure out what misspellings and alternate words to support.
Now, not all products lend themselves to this kind of hotkey-driven approach, but it’s a very healthy exercise to ask you and your product teams:
Where are our customers getting confused or lost? How can we help them arrive at the right place anyways?
When do people need our deeper features most, and how can we present each deep feature at just the right time?
What shortcuts, integrations, and special actions does our product have, and how could we teach our customers about them when they need them?
6) Awesome, simple product emails
Product updates are the kinds of things many companies either don’t do, or shortchange the effort.
Or they may outsource it to marketing, who then trumpet it off to non-customers who often care a lot less than your current ones.
You’re leaving so much opportunity on the table by doing that.
Superhuman gets a lot of things right in their updates:
Frequent: It feels like they’re always launching new, interesting things. This builds brand affinity.
Brief: Because they send them often, none feel overwhelmingly long, so you’re more likely to read them.
Reply-able: You can react and reply to the updates, which is great for understanding customer questions, hearing what people love and hate, and seeing
Interactive: They make these awesome Gifs that show how features work like this recent one below:
It was a sad day when Rapportive stopped working. That alone was incredibly valuable.
Whether confirming you have the right email address for a customer or getting helpful context quickly as you write an email, this sidebar is a massive value add. I was interested in trying out Superhuman for it alone.
At first glance it may seem pretty simple, but there’s huge depth and valuable information in that sidebar:
You can see the last 4-5 emails you exchanged with someone with their subject line listed
You can click on the “Mail” icon to see all emails between you and that person
All the links you could need to find their internet paper trail are right there, no need for searching
And that’s just the default.
Automagically, if you start typing a date, it will change to a calendar view, which makes it easy to make sure you suggest times or days that actually work for you:
And you can see in their most recent update in my previous point, they now also let you schedule meetings in that sidebar as well.
It toggles seamlessly and rapidly to whatever you need that sidebar area to be.
Any one of these sidebar details alone would probably be “nice to have”, but there’s a reason that when I timed myself before and after starting using Superhuman, I found I was getting through email 30% faster. The fact is all that convenience and friction removing adds up to a “must have.”
This sidebar is a great example of the key product lessons to find your points of magic for your customer and double down on them.
8. So many awesome little big details
Building products can feel like an assembly line sometimes, especially if you’re building things like Settings or Admin panels. Yet, true craftsmanship can show in a variety of ways when a team is truly committed to delighting their customers, and has the resources to perfect that last 10%, or add a little touch of joy.
As pictured above, when you hit Inbox Zero, they show you a gorgeous, random picture to celebrate with you
You can also see that along with the picture, they’re teaching me the keyboard shortcuts again, and give a convenient way to undo an action.
If you hover over an email you sent, they show you when it was opened:
And if they haven’t opened the email, only one of the checkmarks is checked, so after you learn the indicator, you don’t need to hover to see if it was opened:
While I love their updates email, they also keep those tucked away in case you want to review it:
And when you reveal the updates, you see they denote if it’s for your phone or desktop app, and use emojis to differentiate updates:
If you have a person’s name and email showing in the right sidebar, when you hover on one of the emails listed that they have sent, you can see when it was sent:
And they add all these little, helpful details and tiny delights while delivering on their promise of speed and convenience. Because no one cares about your witty quotes you show on your load screen if it takes 2 minutes for the page to load.
What little delights can you add to your product to bring joy and timely information to your customers*? (* assuming you have the fundamentals of a fast, functional product covered)
9) Their mobile app is truly mobile first
Too often, products make a decision of whether their primary use case is for mobile or desktop. They then double, and triple down on one or the other, and make a half-hearted effort to have something useful for the other platform.
Superhuman has not only built a great app that covers most of the functionality of the desktop, they took a mobile first approach to the design and use cases.
A few of the helpful tweaks:
Rather than tabs like on the desktop, it’s one tap on an icon to switch between your different inboxes. Conveniently that icon is in the bottom right corner of the screen so it’s easy to tap with your thumb while holding your phone, which is right next to how to switch sections of your inbox (like “News” and “Other”, below).
Pulling down when looking at your inbox reveals Search, which they put the cursor in the Search field, call up your keyboard, and give you a variety of hotkeys and recent contacts to one-tap choose from to make it faster/easier.
Replacing the contact information sidebar, which there’s not enough room for, a summary version is at the top of the screen
Once you tap on the summary version of the person you’re emailing, Superhuman brings up the additional information that would normally be the sidebar, while optimizing for the screen space:
Once again, these are small things, but they add up. It’s clear their team has put a lot of thought into everything.
As I was writing this, for instance, I noticed that each email in my inbox view was almost perfectly the width of my thumb. That makes a lot of sense given that swiping with your thumb is exactly how you clear out your inbox with one hand. With that sizing, it’s also less likely you’ll hit the wrong email or action.
It’s all these little things that make it so that Superhuman feels both desktop first and mobile first. They treat both devices as priorities to be great, and create an experience that rivals most apps that are only one or the other.
10) They’re teaching all of us how to do it
When you do something exceptionally well, it can be tempting to keep it as a secret. Just look at Apple.
It took a decade for anyone to share much about how the iPhone was built. (Note: I highly recommend Creative Selection for that reason). And this post on how Steve Jobs liked to do product is so little known, I’ve yet to meet anyone else that knows it exists besides those I send it to.
Yet, Superhuman is sharing their insights along the way, helping a whole wave of product-led, customer focused startups.
I’ve lost count of how many times I’ve sent those links to others, because they’re such good and helpful posts. And there’s more like it if you look at their Dribbble or blog.
They’re just as thoughtful in their posts and public persona as they are in their product, which is an awesome value add to the startup world.
There’s a lot we can all learn from Superhuman and how they approach building products. Whether borrowing inspiration for a user interaction, trying to create a similar workflow, or treating them as the aspiration of the kind of product you want to build, they’re a great shining light for other SaaS products.
Of course, all of this comes with a caveat: Superhuman comes with *massive* funding. They’ve raised over $33 million, which you may not have.
However, did you know that Superhuman has been working on this since *2014*?
They built very quietly and in private beta for *years*. They worked painstakingly to add all of those things I shared in this post, and many more like them.
Even with infinite resources, you can’t turn your product or idea into a great product like Superhuman overnight. However, if you’re like them and spend a lot of time getting to know your users through surveys, interviews, concierge onboarding, and truly listening to feedback, you can start bringing more delight to your customers.
Building customer driven products is hard, and rewarding work, and there’s nothing quite like the feeling of building something your customers truly *love*. If you want help doing that, I’ve done it before, and would love to help you do it, too.
“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.
Feature Voting is not talking to customers
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.
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.
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:
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.
What to do instead of Feature Voting:
By now you understand why it’s a terrible idea to add feature voting to your product, but that’s only half the battle.
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):
Rate of expansion
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 email@example.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.
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
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.
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.
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.).
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.
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.
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
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.
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:
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.
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:
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.
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.
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.
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
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.
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.
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:
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.
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.
If you launch a feature and you don’t tell anyone, did you really launch it?
Okay, maybe the “tree falls in a forest” analogy isn’t perfect, but you probably get the point: you need to tell your customers when you make improvements.
But how do you do it in a way that customers will care?
I’ve seen dozens of ways for people to do product updates over the years, including these common ones:
Popping up in app to tell them (think Intercom-style, or a product tour)
Posting on your company blog
Emailing to everyone who has an account
Passing it to sales or account management to tell customers
Updating a change log that lists all updates over time
Praying they stumble upon the changes
Of all of those, my favorite is the semi-regular email to customers.
I like it for a few reasons:
Flexible medium: I can write and include images and gifs to clearly show what’s new.
Non-interruptive: Unlike pop ups in app, they can read this when they have time, instead of dismissing it when they’re in the middle of something in your product.
Reminder we exist: People get busy. You are not the center of their universe. An email about product improvements can get people back into your product they haven’t logged into in a while because they see you in their inbox.
For the past nearly 10 years, I’ve been sending product updates at the SaaS companies I’ve worked at and founded. Because of the structure I follow, I’ve seen it help build stronger relationships with customers, reduce churn, and help everyone feel more product momentum.
Today, I’ll show you my process so you can experience those benefits with your customers, too.
How to Write Product Updates that Delight Customers & Reduce Churn
1/ Say your product has a new feature or change and you want to tell everyone about it with a blog post or some tweets. Here are a few things to think about when communicating change to a tech customer base. tl;dr saying what you did and that customers asked for it isn’t enough. pic.twitter.com/iWwrJFaeHI
Okay, so now that you read his 20 tweets, you understand why this is important, and the pitfalls to avoid. Now, let’s talk about how to actually write one.
A few assumptions:
You talk to customers: If you talk to customers, all of this is easy to do. If you don’t, not only is this very hard to do, but you are a disgrace to product managers everywhere. Worst of all, your designers and engineers are rolling their eyes at you. Jump here on my blog to reform your ways if you need to start doing so.
You’re data informed: Quantitative numbers are not everything, but they’re very important. They help you understand how many people are affected by a problem, the total addressable audience for a feature, and measure the impact of a change. Having these numbers is key for both internal buy in and explaining things to your customers.
You have buy-in: The bigger your company, the more stakeholders you need to manage. It’s good to get things done, and it’s also good to keep people in the loop who also interact with customers or care about this. Use your best judgment on who may want to see what you’re doing. If you get resistance, try to get support for an experiment of doing them.
If you’ve done those 3 things, you’re ready to apply these tactics to make an awesome product / feature update.
1) Start with a “Thank You”
Every product update I take the time to write out a list of thank yous to customers that took time to report bugs, share feedback, answer questions, or do customer development interviews.
This costs you *nothing*, but can mean a lot.
First, you’re letting people know you were really listening. It reminds them that their input matters and the time they took out of their day to email you, hop on a call, or beta test a feature was worth it.
It also creates a reinforcing loop:
You thank someone for feedback.
Others see that you thanked people for feedback and it gets them thinking about giving feedback.
Coworkers see their colleague’s name and talk about it, think about using the product more, and consider giving feedback as well.
Next month, the list grows, and you have more people to thank.
Immediately after I give thank you shout outs, I also then remind people just how easy it is to give us feedback, so I teach more customers what to do:
Remember: You want a product people LOVE or HATE.
Silence is your enemy.
Make more people care by letting them know you’re listening. The feedback and problems they share help you build a better product, and improve adoption throughout a company or network.
2) Tell your story
Every product has a mission and vision. As a product manager, you need to understand and lead that vision. It should impact everything you do, including what you write in your product updates.
4/ Dissatisfaction with change happens when there is a mismatch between expectations and reality. That gap can be closed if expectations have a chance to get set or leveled with context and communication.
The best way to manage expectations with customers is to guide them on the journey of your product.
Ask yourself questions like:
Where is our product heading? What is the big picture?
Why are we heading in that direction?
How does our direction help our customers be more awesome?
What won’t we be doing? Why not those things?
As you explain each update and change, you should keep those questions in mind. Make sure what you tell people aligns with that goal.
For example, with Lighthouse, our focus is on making managers great. We know they’re busy, so things like speed and performance in our product is as important as a new, shiny feature. We need to work reliably for them.
That meant that when we had a product outage due to Mandrill failing, we decide to switch providers to Postmark. Here’s how we framed that:
Obviously, this is a very simple version of a story. For new, big features, there’s *a lot* more I would speak to explaining how we think it fits their workflow, why it matters, and how it fits into everything they do.
3) Explain your reasoning
While telling your story is important, it’s also helpful to have a rational side to it. What was the motivation for this decision?
If you’re doing product management right, you already wrote a product spec or product thesis that explains to your internal team why you’re choosing to work on this feature next. You should translate that same quantitative and qualitative data to a version that makes sense to share with your customers.
17/ If you don’t have data then supporting changes with a strategy, point of view, or related business case can be useful.
Making changes that might be unpopular is part of the job but if you don’t offer anything the internet will make up a reason and you won’t like it.
As Sinofsky points out, if you don’t give people a reason, they’ll make one up. So plan to give them a good one.
A feature can be commonly requested, but you don’t build it because it doesn’t fit your vision and mission. A feature can also be less commonly requested, but only because people can’t use your product until you build an integration they would need.
Either way, you would want to explain your decision. Tell people why you chose this of all the things you could do.
Maybe you have a Slack integration, and with all the hype and press around Microsoft Teams, you realize it makes sense to allow MS Teams users to do what you already allow in Slack.
Or maybe your company is moving up market and that means building some permissioning, and security is now more important. Your SMB customers may not be as excited, but if you can help paint the picture that, “one day your business may grow and you’ll want to use these, too” can give them a better feeling about it. Explaining the upmarket move can then also signal to your handful of current, big customers that you are investing more in what matters to them.
If you just say, “We built some new security features” with a list of bullets, you give your customers no idea why. Do better than that.
4) Paint a picture of the future
Your product update is a snapshot in time. It’s one step in an endless journey towards (or keeping) product-market fit.
As important as it is to explain what you built and launched this time, you also should paint a picture for the future. Help people understand and anticipate what is coming.
The key here is to strike a balance. You do *not* want to publish your whole roadmap; it can change too much, and you want to give yourself some flexibility.
At the same time, if people know how you’re thinking and what you’re working towards, they can help you in a variety of ways:
Volunteer to give feedback: If they know you’re building things they’d like, they’re more likely to reach out.
Good customers stay: Most people hate switching products. If they feel like you’re heading in the right direction, they’ll give you time to fix problems and get there.
Tell their friends/colleagues: When a product “just gets me”, you’re much more likely to rave to friends about it. By telling your story for features and where you’re heading, it builds excitement and anticipation for your best fit customers.
Strike the right balance on what you share
Giving just the right amount of detail on the future is definitely a learned skill. However, as a starting point, I like to do the following:
Talk about things under construction: If you’re already committed to and building something it’s pretty safe to hint at it by showing a small snippet, or explaining what it will do.
Focus on themes: Rather than listing the 27 things you hope to do (and could change), tell them thematically about your goal or vision. This could be like saying we’re going to “allow you to do key activities on your phone you told us are important when on the go” instead of listing mobile app features.
5) Seek feedback and input
You should never send something product related that is “no reply”, and this is especially the case for product updates. If people have something to say about what you built, make it as easy as possible for them to share their thoughts.
You can then use this to also recruit people for future customer development based on the upcoming features you’re going to launch, or to get people to take a survey.
The more you show you’re listening and acting in their interest, the more engaged your customer base becomes.
Creating a virtuous feedback cycle
When I joined KISSmetrics, they were getting about 10 pieces of customer feedback a week from our feedback box in the product. Unfortunately, no one on the team was replying to those for a variety of reasons.
Through being more customer driven, replying to those messages, and sending notes like I’m outlining today, we were able to boost that to getting over 50 pieces of feedback (5X) a week while the customer base grew about 2.5X. This helped us catch and fix bugs faster, and more easily get insights from our customers.
The easier you make it to give feedback, and the more you respond and act on what you receive, the more feedback you’ll get from customers.
Before long, you’ll find it’s really easy to find and recruit customers for new feature feedback and customer development.
Adapt this to fit your business and audience.
With my startup, Lighthouse, we sell to managers. They’re generally in an office and live in email. This makes an email update great.
Once a month is a good cadence for us to send an update out as it’s a couple sprints, and usually enough to fill up a good update. It also is a frequency that resonates with our audience as they do a lot of their projects in monthly increments.
Your business may be different, so consider changes to what I’ve outlined here like:
Message on another platform: Can you tell them in Slack, via a small text, or somewhere else they’re most likely to check?
Tweak the frequency: Update your customers as often as you think fits your update cadence and your customers want them. More, shorter updates, or fewer, longer may make sense.
Use another format: If you’re a video platform, then video updates probably are better. If your business includes a really popular podcast, maybe a quick audio clip.
Show your personality: This is a huge opportunity to build your brand, so put some of your company’s personality into it. If your company is nerdy, be nerdy, if it’s playful or irreverent, be irreverent, and if you’re really formal, then your update should be, too.
Involve the right people: Who has the strongest relationship with your customers? They should be in the loop on this. For example, if you have account managers it may be best to have them get the word out, at which point you could draft something they can copy/paste and adapt.
The best way to get to the right format and approach for your customer is to listen and iterate. Get the right people involved in your company and start trying things.
As you build the habit of doing this, you’ll see more of what works and doesn’t so you can work towards getting messages like this from your customers:
How do you update your customers about changes and improvements to your product? Share your favorite tactic in the comments so everyone can learn.
So you have a crisis. Your product went down. Your site or reports froze.
Emails weren’t sent…or maybe they did…100 times instead of once.
Whatever it is, your product didn’t do the job your customers hired it for.
When disaster strikes, you have two choices: Hide from it, or face it down.
Hiding will cost you.
How you react will directly affect your customer churn or renewal rates, what your customers will do (do they tweet about it? Do the offer to help?), and the morale of your team.
That’s why, if you’re the product manager, and there’s an issue with the product you’re in charge of, you need to take the lead to help communicate with your customers about it.
You can’t often do much to help engineering do their jobs, so helping with communication internally and externally can be really valuable to reduce distractions for them and show you’re doing your part.
You also then build a culture of facing problems down directly.
My team knows that if anyone finds a bug or problem, the first question will be, “who is affected?” followed by, “can you get me a list of their names and emails?” (More on this shortly).
Today, I’ll share how you can lessen the long term damage, and even earn some good will in a tough situation with your product.
What PMs should do first in a Product Crisis
Ever had a wave of upset customers mad about your product? I’ve been there.
I first learned about dealing with such issues when I was at KISSmetrics. We ran into some serious tech debt / scaling issues that led to angry tweets, lots of support tickets, and even AdWords run against us by our cutthroat competitor, MixPanel:
While there’s nothing you can say or do that will save you if the problem continues, the right message at the right time can buy you time to address it, and relieve a great deal of tension.
Here’s how to approach it:
1) Communicate internally
This is one of those times all those soft skills of being a product manager come into play:
Your customers are stressed: They can’t use your product as intended for the reason(s) they pay you for it.
Your product team is stressed: They’re scrambling to understand and resolve the issue.
Your company is stressed: Everyone from sales to customer success to executives will hear about a big issue. And they often won’t be able to do anything about except add more pressure to the situation.
As a product manager, you need to step up your game and work to communicate with everyone calmly and effectively.
Be a source of calm…
The first thing you need to do is relax. As leader, it’s important to be calm and under control. Understanding the problem and having a plan should give you reason to be confident when communicating internally, then later externally, about the problem.
Don’t understand the problem? Then, that’s priority one.
Ask the basics:
Who is affected?
Why did it happen? (If you can get to the root cause)
Is it ongoing or are things back up and running?
What is the estimate to a fix?
If you know those basics, you can help your team by starting to communicate with those that need to be in the loop. Those can be people like the sales and customer success teams you interface with, and of course any other key stakeholders.
From there, you can start looking at how to communicate with customers.
2) Use the right level response for the size of the problem, and the size of your company
This advice applies most to small startups and businesses (1-50 employees). As you grow, you’ll likely have a more resilient product, a full marketing team to support you, and set policies to follow.
However, regardless of your company’s size, it’s very beneficial to understand what your plans would be in the event of a crisis. By the time something happens, it’s a lot harder and more stressful to come up with it on the fly.
You also want to scale your response to the size of the problem.
Find out who is affected. Only send a response to them, especially if it’s a small group
I like to send personal emails (or work with account managers/customer reps) for small groups affected. Then, for bigger groups, I’ll ask an engineer for a list of every customer affected with their name and email in CSV. That makes it easy to quickly import that list into your favorite email marketing tool to fire off such a note.
3) Always keep your boss in the loop
Finally, use your best judgment and run any plan like this by your boss.
Whether that’s the CEO, a product leader, or a founder, they’re going to have opinions, thoughts, and concerns as your product crisis unfolds. And if you’re not updating them, they’re going to ask you, or go bug your team for updates.
While we’re focusing today on communicating with your customers, many of these same approaches can also help in managing up with your boss.
As important as it is to update them, it’s also a good idea to get their approval for sending the kind of note we suggest. They can help with a quick proof read of your email before sending, so it fits the desired tone, and make them feel a part of the solution, too.
How to Communicate with Customers During a Product Crisis
When reports started getting slow at KISSmetrics, at first we hid from the issue. We assumed it was just some edge cases, and maybe it would go away. (It didn’t.)
Instead, it got worse.
Finally, we decided we needed to say something, so our VP of Product and Engineering wrote an email we sent to customers.
And then we braced.
We didn’t know how customers would react, and so we hoped for the best and prepared for the worst.
Fortunately, the immediate response was incredibly supportive. Suddenly, the elephant in the room was gone, and we could focus on improving things for customers without fear of how they’d react.
Since then I’ve used the same approach, and learned a few key additions that have helped me with products I’ve worked on and a number of my friends do the same.
Here’s a few keys when you need to write the note:
1) Show empathy
If your product matters, which if people buy it, it must be important to them, then showing you appreciate its importance can help a lot.
Speak to the use cases you know the problem impacts like “your ability to have those numbers for your weekly marketing meeting” or “your ability to properly prepare for your 1 on 1s with your team members.”
If you don’t know how your customers use your product, then it’s time to figure it out. Pay attention to what people are quite possibly screaming to support about that they really need, and speak their language.
When people feel heard and understood, they are more likely to be calm and understanding. When you show empathy to them, they’re more likely to show empathy for you.
Put this early in your note to customers.
2) Call yourself every name in the book
This isn’t a joke. You’re showing that you know it’s bad, and you need to do better.
By bravely standing up and admitting a mistake or error happened, you show leadership.
“Say about yourself all the derogatory things you know the other person is thinking or wants to say or intends to say – and say them before that person has a chance to say them.
The chances are a hundred to one that a generous, forgiving attitude will be taken and your mistakes will be minimized.”
It may seem counter-intuitive at first, but if you try it, you will be amazed at how well it works.
Caution: You win and lose as a team
Do not throw any team members under the bus. Stick to we’s and group/company wide acceptance of responsibility. Emotions will be running high as your engineering team works hard to fix it, so the last thing you want to do is to pile on more stress or frustration by calling them out.
And even if say a now-fired engineer deleted a database, or someone made a big error, your company still bears the responsibility; your company hired the wrong person, or failed to have effective safeguards to prevent such an incident. Finger pointing gets you nowhere.
Importantly, by calling yourself out, you save your customers from having to. This can prevent many angry tweets, or a large, public outcry.
Best of all, when you do self-deprecate over an issue, as Dale Carnegie teaches, there’s really only one thing left for them to do: be magnanimous and forgive you.“Oh it wasn’t *that* bad. I’ll live.”
3) Talk about what you’re doing about it
This is a great excuse to work with your engineering team to understand the technical side of your product better. When they’re not in full crisis mode, or they take a break, sit down with someone on the team to get a layman’s term explanation of what happened.
From there, you convey however much you and the team are comfortable stating about what happened, and then most importantly, you look to the future on what you’re doing about it.
You see this a lot in the world of engineering products. They’ll actively tweet out about an issue and then even share the post mortem publicly for other engineers to see what they learned.
While that may be overkill or not relevant to your market, explaining what you’re doing to prevent the issue going forward definitely is important. Doing so builds confidence that this will be an isolated incident, or you can warn them, “We’re making this fix now, and a broader fix will take X weeks, so let us know if you experience issues in the coming days.”
This is the best way to end your note to customers about your product crisis.
Putting it all together.
Here’s an example note I sent to customers in 2017 when we accidentally emailed people 7 prep emails in the morning for each of their 1 on 1s that day. For some people that meant a busy day of 1 on 1s caused them to be sent 50+ emails in just a few minutes.
Now, this isn’t the biggest failure ever, but it was an opportunity to set the standard we own up to mistakes they’ll certainly notice.
And the response was exactly as we hoped:
Our response looked personal, but with a little planning, it was all automated and totally scalable to the size of that issue and others like it.
The bigger the issue, the more the detail you’d put in the note, and the more you’d be self-deprecating. Use your best judgement and fit the culture of your company for how to specifically frame it.
Update! Buffer has a fantastic example of this with a recent issue:
I also like a couple things extra they did here:
In addition to covering the basics we outlined in this post, there’s a couple extra things that the note does that are worth calling out:
It’s from the CTO: Showing this issue was given attention all the way to the top of the organization.
They thanked their customers: When someone helps out, it’s always good to thank them for their contribution.
Reinforce behavior you want: By continually setting an example and stating how they like their customers to act, it helps reinforce customers should behave that way. This is why it’s better to say, “Thanks for your patience” instead of “Sorry for bugging you.”
Note: This is not a silver bullet.
In the end, this approach will buy you time and earn some good will. It helps you be a part of the solution with your team and sets a good precedent for communicating with your customer transparently about issues.
However, much like in baseball, “3 strikes you’re out.”
If this happens too often, no amount of well crafted apologies will save you.
You have to fix the issue and do better going forward, and then it will be a distant memory in your customers mind, and you can get back to making more awesome stuff.
How has your product team handle crises? Would love to hear your stories of what’s worked in the comments.
>>> Are you passionate about building great products & live in New York City?
I just moved to NY and am looking to connect with other people that love building great products to share tactics, fresh ideas, and cool products.