Have you ever thought about building a free tool for your company? Do you want to build more buzz, get a ton more inbound SEO links, or drive signups and leads for your core business?
Or maybe you are a free tool skeptic, worried it will distract your team, take to much time, or not pay off?
I’ve always been curious about free tools, but haven’t been directly involved in many myself. So when I met Michael Novotny, who has become an expert in creating free tools, I knew I had to have him on the Practical Product podcast.
Michael is a product manager turned founder, who has helped build and launch dozens of free tools / side products now and studied hundreds of others with his company, Product and Build Co.
In this episode we go deep on this topic covering everything including keys to success, pitfalls to avoid, tons of examples, and how to convince yourself or your boss to take a shot at making some free tools or side products.
How to Use Free Tools & Side Products to Grow Your Business
Today we talked about how building free tools (aka – side projects) for your company can help drive major growth for your company.
Building these tools helps you a few ways:
People who use your free tool may directly sign up for your paid product when they see you made the free tool.
People using your free tool may give you their email address, which you can market to later.
Others will link to your free tool, boosting your SEO through improved backlinks.
Michael shares a lot wisdom and experience doing these, and the most important tips are:
Build a portfolio: You need to launch many tools (ideally 4-5 or more) so that some will hit, and others won’t. If you only launch one, the odds work against you on the moon and stars aligning for you.
Build in public/test with your community: To increase your success rate, validate and test the ideas you have for tools to see if they resonate and what are the most important things it needs to do to provide value.
Use low and no-code tools: You can build and launch a lot faster using these tools, and since it doesn’t touch your core product, it doesn’t need the perfect architecture.
There’s a lot more to this episode, so I encourage you to give it a listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(2:04) – How Michael discovered the power of free tools to drive sign-ups for another product
(11:46) – What are a couple of your favorite examples of these tools?
(16:31) – Cases where free tools didn’t work out.
(21:55) – Are there businesses that shouldn’t be creating free tools?
(29:05) – What is Michael’s Side-Product Framework?
(34:56) – How should PM’s think about budgeting for Side-Products?
(42:08) – How do you come up with good ideas?
(47:55) – How can you start to validate some ideas for tools to see if you’re on the right track?
(54:09) – What should people do to make these free tools successful?
(58:05) – What are the best ways to tie a free tool to your product?
(1:03:32) – How much ongoing maintenance should you expect?
(1:09:18) – What are your favorite tools that help you piece this process together?
(1:13:58) – Keys to convincing your boss or peers to try free tools.
We had an amazing, 95-minute conversation covering a wide range of topics that any manager leading a fully or partially remote team needs to hear.
And if you’re thinking about changing jobs and joining a remote organization, you’ll want to listen in too, because we specifically talked about the transition you’ll have to make as well.
How to Succeed as a Remote Product Leader (even if you’re new to it)
Some jobs are not that different doing them remote versus in person. For example, a sales rep may have to sit and make the same calls, send the same emails, and generally have identical tasks that if anything, might be easier in a quiet environment remotely.
For a highly collaborative role like product management, that’s not the case. A LOT changes.
What works in person, doesn’t always work remotely, and often, the solutions aren’t even a 1 to 1 trade. Instead, you have to reinvent entire workflows and processes to fit the different way of working remotely.
Today’s discussion with Valentina Thörner goes deep on exactly these things.
You can listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
A deep dive on remote vs. in person communication advice, and great team construction:
(1:43) – What are some of the biggest changes when someone shifts to a remote PM role?
(11:38) – How can a Remote PM be successful?
(14:55) – How can Remote PMs understand how their team is feeling and reacting to their work and communication in an asynchronous environment?
(24:00) – Do you think the ideal product team size is different for remote vs. in-person?
(26:54) – How do you avoid meeting & Zoom fatigue / overload?
(42:16) – How do you create the collaborative juices from a whiteboarding session for a remote team?
(48:48) – How often do Remote product teams need to be together in person?
(51:53) – How much would you think about geolocation when it comes to constructing pods?
If you’re thinking about working as a remote PM or want to find a great remote company:
(58:49) – What are ways PM’s can prepare themselves for the shift to a remote-first organization?
(1:04:54)- What questions would you recommend asking when sussing out if a remote company is the right fit?
(1:14:15) – What skills would you recommend developing for folks looking to become remote PM’s?
(1:20:32) – What are good ways for folks to build their writing and communication skills?
(1:27:10) – Are there any more skills people need to develop to be great Remote PM’s?
Key Show Notes & Further Reading:
– Books and other helpful links from today’s episode:
Many books and great blog posts were mentioned in this episode. Here’s a rundown of the books:
What are the consequences of AI making our lives easier and better? What jobs will be lost and what happens when they are gone? And how should product managers think about the new, bundling phase we’ve entered?
In this week’s episode of the Practical Product podcast, you’ll hear my thoughts, and some quotes from others related to a few key topics that have been top of mind lately:
What it means to now be in a bundling phase for tech and how PMs should adjust their strategies.
A problematic mindset I see and hear in too many PMs.
The truth about AI and the future of work. Will we really see jobs disappear?
Practical Rants: Why intellectuals are wrong about AI, what PMs must do as we enter the Bundling Phase, and a key mindset PMs must avoid
This episode is a collection of my thoughts on some trending topics I am seeing in the world of tech and product management relevant to PMs:
1. We are in a Bundling Phase: How can we as Product Managers bundle our offerings for consumers who are concerned about economic instability? We need to establish our products as absolute must have’s in the eyes of our customers and recognize the new market dynamics to survive and thrive .
2. Let’s stop the Self-Deprecation in Product Managers: Don’t be the “this is fine” dog meme, be part of the solution when you see negative trends within the culture or product at your organization.
3. The Truth about AI & the Future of Work: I break down a clip from Yuval Noah Harai and his horrendous take on the “Useless Class” of folks he predicts will grow as technology continues to advance. We must shut push back on this rhetoric and build tools for an abundant AI future.
You can listen on your favorite platform or in the player below:
Highlights of the episode include discussing:
(1:27) – Bundling within companies amidst economic uncertainty
(6:34) – What to do as a PM when you see customer churn due to bundling
(10:23) – Understand your secret sauce
(12:37) – Self-Deprecation in Product Managers
(17:29) – Yuval Noah Harari on the “Useless Class” & The future of work with AI
(29:22) – Product Managers can be part of the solution
(32:04) – Final Thoughts & Recap
Key Show Notes & Further Reading:
1) Now entering the Bundling Phase…
I saw a tweet from my old boss and mentor, Hiten Shah, that really hit home:
That got me thinking…why now?
Now you have the combined argument of:
We had too many tools to manage. IT hated this. It was a security and info management nightmare.
Budget cuts. You’d rather cut a tool than an employee. And there’s an easy case to make to decision makers that, “hey, this big system does all these things. Let’s cancel all the other tools and consolidate on this.”
And for PMs, this means you need to consider a few key tactics to navigate this reality:
Look for breadth over depth in feature building. In a consolidation phase especially, you’ll be competing against a lengthy feature checklist, where one system that does everything gets the purchase, and there’s no second place.
Take advantage of integrations and APIs. If you integrate with tools they use, it helps keep you sticky. And if you have an API and others build on top of what you’re doing that’s also a great, viable strategy to expand your functionality faster than your own team can build.
Build for the right ecosystems. Microsoft and Salesforce are two of the biggest heavy hitters. They’re exactly what people are going to consolidate on because it’s so easy to. Be prepared for push back though…both are miserable to build on.
Tighten your relationship with Sales and CS. You need to know how you’re winning and losing deals. Find out how account management is doing trying to retain key accounts and what they’re saying they’re thinking about.
Understand your secret sauce and champions. What’s unique about your company? What do you do better than most? What critical thing do you deliver that will have someone with influence at a customer banging the table to keep you? If you don’t have it you better get it. If you do, make sure that feature stays great. Don’t let the goose that lays the golden eggs get hurt.
2) The problem of self-deprecation for product managers.
While this meme can be funny, it shouldn’t be your main identity as a product manager:
It sends a bad message to everyone around you if you’re constantly self deprecating about your job:
It makes you sound like a victim, and potentially setting you up to welcome more abuse
It creates a self-fulfilling prophecy where you look for confirmation of this negative way of living as a product manager. Build for and focus on the positive direction.
It sends a bad external message to other PMs that “this is the job.”
And maybe in some cases “this is the job” but ask yourself if that’s what you really want?
3) Why AI is NOT going to cause massive unemployment.
The ignorance of Harari is staggering. He oversimplifies things and has such an out of touch view of reality.
These changes always happen. Every time there’s talk of this concern.
There used to be tons of jobs for horses before cars: Poop shovelers, veterinarians, horse feed, etc.
And cars of course created jobs: car dealers, mechanics, all the many parts needing manufactured, car washes, windshield repair, gas stations and the entire oil industry, etc.
There were floors and floors of accountants and bookkeepers, and then the spreadsheet came along…and with the rise of computers, I think we can all see the many jobs they created, and how information and services were democratized.
There are plenty of jobs to fill
In today’s world, it’s crazy for someone to argue there are no jobs. There are tons of opportunity all around us:
We have organizations like Bloomtechhappily training people, many coming from “low skill” jobs.
Most tech jobs are self taught, too! Can you major in sales or product management?
This means that even if some jobs are displaced by AI, there’s no reason to believe there won’t be work for these people.
AI makes jobs more efficient, not eliminated.
Not one reply to this great question about copywriting AI mentions *anyone* losing their jobs:
And similarly, Github’s AI is making engineers faster, not taking their jobs:
When you free up a worker’s time, they can do more and different things.
Product Managers can be part of the solution.
If you’re working on a product that uses AI, think about how you can help make a better future for workers:
Build your tools to make their jobs faster and better, not replace them. You’ll get less adoption resistance and they’ll become your loyal fans.
Make your interfaces more accessible and easy to use. This will allow newcomers to use your product, and speed up adoption.
Harari is a monster and a terrible human being.
Harari is an example of an intellectual monster. He is giving speeches like the video embedded above to world leaders at places like the World Economic Forum. He has a large platform and the ears of people that make his ideas very dangerous.
Did you know that part of Nazi eugenics called some people, “useless eaters”? To use phrases like the “Useless Class”, is the first step to genocide and should be condemned fully, especially in intellectual conversations as we all develop technology people will be using every day.
Do not fall for those false pity ideas from false intellectuals. There will always be jobs. And every new technology creates new jobs and opportunities as much as it may eliminate a few old ones.
We as product managers have the opportunity to be a part of the solution and create the future that helps everyone, and does not consider anyone “useless.
Want to be the first to hear about new episodes of the Practical Product podcast, and other blog posts I write about Product Management? Subscribe here:
Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of a product leader who has done this before? How can you avoid being a casualty of the 1st PM curse?
Today, we answer those questions and a lot more.
A chance meeting…
Back in 2019, I was living in New York City. I was meeting other PMs in town, and by chance was connected to Hostos Monegro. As it turns out, we had a lot in common, as we’d both been a 1st PM multiple times at startups.
As the conversation continued, we realized there was *a lot* in common between our experiences. It helped me realize that the situations I experienced were possibly less about me, and more about the nature of the job. It ultimately led to the inspiration for the now oft-discussed post, “Why you want to be the second 1st PM.”
Knowing how much credit Hostos deserved for inspiring and helping craft the ideas of that post, I knew there was no one better to talk about the product manager perspective than him. When I started planning this podcast, he was one of the first people I asked to come on the show, and this week’s episode is the product of that discussion.
The Curse of the 1st PM – Part 2 w/ Hostos Monegro, 4-time 1st PM
Today’s discussion with Hostos dives into lessons learned on having made the majority of his career being either the 1st PM, or as our original post called it, the *second* 1st PM (who comes after the first one didn’t work out).
If you’ve ever thought you wanted to try being a 1st PM, or already are one, this is a great episode for you. We cover key topics like how to screen for the right founders to work with, why this role can be awesome and fulfilling, and how to avoid some of the common pitfalls that come with the curse of the 1st PM.
Highlights of the episode include discussing:
(2:14) – What is it like being a 1st PM the 4th time around?
(5:53) – How did you think about filtering the Founder when looking for a 1st PM role?
(9:14) – What are the awesome parts of this kind of role?
(15:07) – What are some of the hardest lessons you’ve learned as a 1st PM?
(25:17) – Advice for someone interested in taking on the 1st-PM role
(38:40) – What should potential PM’s look for in a company to determine if it’s a good fit?
(46:52) – Recommendations if you think some of these 1st PM pitfalls apply to your situation
(48:11) – Advice for founders thinking about hiring their First-PM
Why is it such a struggle for 1st PM hires to succeed? What are the challenges from the perspective of the CEO who hires them? What do founders learn in the experience when seemingly inevitably, the 1st PM they hired with the best of intentions didn’t work out?
And knowing he had just gone through this, I knew we had to talk about it on the Practical Product podcast. That’s why this week’s episode is all about it.
The Curse of the 1st PM – Part 1 w/ Pulkit Agrawal, CEO of Chameleon
If you haven’t read it yet, the best place to start is reading my 2019 post, “Why you want to be the Second 1st PM” to get context on this unique role that comes with special challenges, and sometimes a lot of baggage.
Today’s discussion with Pulkit helps answer the question you may have from the post, “How does this happen?” Pulkit read my blog post, new the risks, and yet it still happened.
Are all 1st PMs doomed? Probably not, but the challenges and unique factors of being an early stage startup do make for an ever-changing set of circumstances that can make someone who was the right choice when hired no longer the right person 6-18 months later.
Pulkit and I have a really candid conversation about what happened, what he learned, and most importantly what he’ll do differently with the second 1st PM (who he just hired).
Highlights of the episode include discussing:
(5:35) – How has your approach changed for hiring PM #2?
(6:27) – What got you excited about the person you ultimately hired for the #1 role?
(13:52) – When did you start to realize things may not be working out?
(18:28) – How did you handle the transition of a PM leaving the team?
(25:13) – Is it inevitable that the first PM will never be a perfect fit?
(34:02) – How are you thinking about changing your hiring process the second time around?
(35:44) – What advice would you give a founder who’s considering hiring their first PM?
(43:17) – How can the founder set the PM up for success?
(45:03) – What advice would you have for PM’s interviewing for a first PM role?
(48:52) – What are some red flags candidates need to look out for?
“A great product manager is… 🧵 ” <- You’ve probably seen more than a few threads like this on Twitter. The challenge is that the whole list is impossible to be in one person; even if you did somehow manage all the skills needed, you’d still end up with not enough hours in the day to do it all.
Reading it resonated a ton as I’ve seen in my career and coaching other PMs, so I knew I had to reach out to Jason to talk more about it on the Practical Product podcast.
The “Impossible” Product Manager w/ Jason Cohen of A Smart Bear + WP Engine
The demands of a product manager can be overwhelming. You can often be expected to be more things to more people than any one person can truly master. And even if you can do those things, there’s not nearly enough hours in the day nor the week to do all of them.
Read Jason’s full post here. Today’s podcast discussion is focused on the consequences of the post and what to do about it.
As a quick summary, there are 4 key areas of responsibility that can fall under product managers that Jason outlines:
Scrum Product Owner
The key to those for is that as Jason puts it, “a “Great PM” is excellent in one area, good in at least one other, and doesn’t have time for more than two.”
So today we’re diving into what that means for product managers.
Listen in the player above, or you can find all your favorite podcast platforms with links to them by clicking the “Subscribe” text in the player.
And as you search for that balance of the right areas to focus on, keep in mind this great visual from Jason on finding your ideal situation:
When you find this intersection, you’ll maximize your happiness *and* thrive in your career.
You can read Jason’s expanded post on this topic, which he wrote after the recording of this episode here: “Finding Fulfillment”
Want to hear about every episode of the Practical Product podcast as soon as it drops, and other blog posts I write about Product Management? Subscribe here:
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.