Before my time in product management, I spent my days on the phones in customer support. It was a great experience and allowed me to truly learn and understand our customers. I heard first hand about their challenges with our product as well as in their businesses. I remember thinking to myself, “Why did the company choose to build that new thing instead of fixing this long running defect?” or "Man, if I had designed this it would’ve been a lot different. They missed the user needs completely.” Eventually I started working more closely with the product managers, running weekly meetings where I escalated defects and experience problems. Because of this exposure, an opportunity to move into Product Management presented itself and I jumped on it. I soon learned things aren’t as simple as they seem from the outside.
You’ll have more time on your hands, at least at first. Take advantage of it.
When I was in Support, managers trained us to be as productive as possible. Whether it was calls, chats, or tickets, we were constantly measured to see how many we could resolve each day. We were paid bonuses based on where we fell compared to other support team members. Being broke and newly married, I tried to maintain a dizzying pace, moving from one call to the next as quickly as I could. At least 7.5 hours of non-stop customer interaction per day. And then it all stopped.
During my first few days in Product it felt like time was standing still. You mean I have three hours to focus on a single thing, uninterrupted? Even if the site goes down?
Use this time wisely. Get to know your fellow product managers. Befriend the development team. Learn their personalities. Bring the donuts.
The interruptions will ramp up as you get involved in more projects and take on added responsibility. It will be more difficult then to find time for building relationships.
Once those projects start, use your “extra” time wisely. You’ll need it to fully unpack a problem, gain alignment, and build well-designed solutions. Your first instinct will be to move as fast as possible, but don’t give in.
Speed is not priority no. 1. Action for action’s sake is not your goal either. Gathering the right information to identify the customer’s need and to design the right solution is far more important, though the pace feels comparatively slow.
The takeaway: Measure twice (or three or four times), cut once.
The customer is not always right.
Back in Support, it was rare for me to tell a user we couldn’t help them. If my customer needed something, I would do everything in my power to accommodate them. If they wanted a feature, I told them—sincerely—that I wished we had it too.
I was also impatient: I’d wonder why things took so long to build. Or why a defect I reported a year ago was still around.
Once I transitioned to Product, I learned the importance of saying “No.” Des Traynor from Intercom gave a great talk at the 2014 Business of Software conference called Product Strategy Is About Saying “No”. I had the pleasure of seeing it in person and I always recommend it to new PMs.
Des touches on a few things that I struggled with initially.
First, your loudest customers are often your worst guides. A request may come up several times through Sales or user community feedback channels, but that request may not be representative of your larger user base. I learned this one the hard way. I was working on an editing program, and added an option that was never used by more than 5% of users. It is still in that product today. It’s embarrassing.
Just because you’ve heard a request a few times this week, doesn’t make it a priority. Every new feature comes with a lasting cost of maintenance and experience complications, never mind the opportunity cost of not improving your core product.
In short: Always be sure to research customer requests to fully understand the underlying needs. As Jason Fried put it: “Act not on the requests of your customers…but act on their behalf.”
Second, if you blindly follow customer requests and continue to add feature after feature, you lack a product vision. You will wind up with a bloated, unusable product that is not particularly good at any one thing.
I have seen and experienced this firsthand, and the result is never pretty. The endless cycle of chasing the next feature while neglecting the one that just shipped is tough to escape, but the results are grim. Your user base is angry you’re adding features (that they don’t care about) instead of fixing the ones they pay you to use. The features themselves aren’t even that good because they are rarely fine-tuned, since you’re too busy moving on to the next thing. And to add insult to injury, they have no measurable impact on your paid conversion numbers.
It is our job as product managers to determine what underlying need is hidden within user requests. We need to look for trends. If someone is asking for a calendar integration, what’s their reason? Do they want to know when people are on vacation? Or to understand team members’ capacity? Or to coordinate team outings?
Dig deeper than the surface of the request and you will find the common “jobs” a user has. Once you know these, you’ll be 10x more valuable to your users and company since you’ll be able to design and build the right features and products.
The takeaway: Don’t act simply on requests of users. Understand their “jobs” and build solutions that help accomplish them better than existing options. The rest will fall into place.
You will prioritize new enhancements over that defect you submitted while in Support. And you’ll be right.
Not all defects will or should be fixed. I came to realize that just because one user had an issue bad enough to call us, that doesn’t mean we should stop development on improvements in more heavily used areas.
In fact, if you have access to the entire backlog of defects, you’ll realize that there are a lot. More than you imagined. And a lot of them don’t impact many people. When I first gained access to the defect backlog I was shocked to see there were hundreds of open defects. My role in Support was to serve as a liaison between Support and Engineering and highlight impactful defects, so I thought I knew every issue. But I knew just a fraction. I quickly understood that most of these defects don’t impact users in any meaningful way, and it’s OK to have certain defects go unfixed.
Prioritization is an art and a science, but I follow one basic rule: Focus on areas frequently used by a majority of customers. Improvements to a core workflow or page will always have a better ROI than a fix to an edge-case defect. Strategic priorities and broad user problems should drive your discovery and prioritization. Neglecting to fix a defect, even one that generated a few calls, will make the inner Support rep in you cringe, but it’s the right move and you’ll get over it quickly.
You will piss people off.
You will ship your first major feature or update. You will be excited to see how it’s used and how people react. If you’re brave enough to alter a core piece of the workflow, you’ll be hoping everyone will love it.
Then you’ll see the first upset user. The first angry tweet. Your friends in Support will tell you how pissed people are. How that weird hack that used to work for a few people doesn’t work anymore! I was shipping major changes to the core experience of a product used by half a million users in my first few years in Product and I experienced this first hand. When you have that many users, any change is going to generate some backlash.
But that’s OK. Shipping many features and updates over my career has taught me that many people just don’t like change. Someone will have memorized the way it worked before, and having to learn a new way or alter their behavior is jarring. No matter how well thought-out the change is, it’s different. It stresses people out.
Now, if you experience a tidal wave of negative feedback, you have a different issue on your hands. You probably missed a core user flow. If that’s the case, stop your rollout, turn the feature off, or quickly get a fix out.
The important thing is to know the difference between something being fundamentally broken and something just being different. Beware of knee-jerk reactions. Expect some negative feedback to any big change and be ready for it. Keep a cool head and wait for it to die down.
In the case of risky or very major changes, consider rolling the feature out to beta users or a/b testing it against the current experience to minimize risk.
The takeaway: You’ll make the biggest impact by improving what is used most frequently, by most users. But be prepared to piss some people off, no matter how great your change is.
Don’t lose touch with your colleagues.
Just because you escaped life on the phones, doesn’t mean you can’t swing back by for a visit. Continue to spend time with your old colleagues and keep those relationships healthy. They will be an invaluable resource. Bounce ideas off your old cubemates, have them beta test, ask for feedback on designs or how your new feature is being received.
Remember when you said, “I wish they had run this by me first, I could’ve made this so much better”? Don’t make the same mistake. Don’t get cocky. Don’t assume you have all the answers.
I like to hold a weekly meeting with our Support team to learn what they are hearing from users and collect feedback on new ideas. In these meetings, it’s critical that everyone feels safe enough to be candid and knows they are being listened to. If they don’t feel heard, they’ll stop speaking up—and you’ll lose out on a wealth of customer knowledge. Don’t get defensive. Don’t shoot down ideas. Listen and ask for clarification as needed.
I worked with someone in the past who would get very defensive and aggressively interrogate Support team members that raised complaints about her product area. It got to a point where people were afraid to give critical feedback and instead opted to tell us (the other product managers) outside of the meeting. Don’t do that. It can be hard, but don’t take feedback personally. Check your ego.
Having a strong relationship with the Support organization will help you make smarter product decisions. The feedback can also lead to new product innovations. But remember, it’s your job to distill that feedback and uncover the underlying problems and trends. Don’t blindly follow the requests.
Don’t lose touch with the customers either.
This is critical. Your foundational knowledge of the customer will be a huge asset in your new career in Product. Don’t ever lose it. Ever. This means that you talk with customers. In person, on the phone, via email, however you like. Just make sure you continue the dialogue.
Don’t assume that what you learned on the phones two years ago is still relevant. Users change. Markets change. Products change. Stay tapped in to your customer base or you will struggle—and wind up building products that people don’t care about. Guaranteed.
Once you leave your company for a new gig, spend as much time as possible getting to know your new users. No longer having your customer knowledge to fall back on will be scary, even overwhelming, but put in the time and effort or you’ll feel lost when you’re asked to make decisions on the spot.
Believe me, your new team will respect you much more if you do this.
You’ll know more about the product than most people.
How little some people on the product side actually understand about how your product functions can be shocking. But unless you’re at a startup, you have more direct experience with the product than 90% of the people you’re working with.
As with your customer knowledge, your product knowledge will be an advantage and something to leverage often. You’ll never know more than the QA person who has been at the company for 5+ years, so make sure to bounce ideas off them, too. I used to run my user stories by our head QA person before anyone else and she’d usually send me a list of additional items that I needed to investigate or account for. She knew every partner customization and legacy workflow we needed to support and she saved me from embarrassment more than once. I owe a great deal of my initial success to her.
The takeaway: Relationships matter. Whether it’s with your old colleagues in Support, your customers, or your new team, make sure to build and maintain relationships. They will be the foundation of your success in Product.
