As PMs, our brains are always so packed with different things that we need to learn and stay on top of. Well, here’s one more important idea, I am going to ask you to fit in and not forget:
You may be tempted to think that YOU are your customer. But you aren’t. You can be the voice of the customer, that is something very different. The sooner that you learn this the better. It will avoid a lot of grief for you, and well for your customers.
In this article, we’ll talk about why feeling like you are your customer and making decisions based on that is an issue. We’ll also discuss strategies to help you step away from this fallacy.
I get it, believe me, I do.
If you are the customer, then your job is so much easier! The hard task of building a roadmap is well, not hard. You know exactly what needs to be built, as you know yourself. When support issues come in, it’s easy to prioritize which ones you need to focus on. You just have to ask yourself “does this affect me?”
More times than not, the answer will be no and you are done. Life is easy, right?
User experience? That’s also an easy one. You know the kind of experience you need, so the team just needs to build that. If you are the customer, you are always the hero. Right?
I am being a little extreme for effect, but the reality is that many product people do think this way, including at some of the largest tech companies in the world. Yes, it is a problem.
If you see yourself as the customer, then you will make decisions based on what you deem as necessary or beneficial. The problem is that your customers may not agree. You will likely invest in the wrong things — things your customers don’t need.
Don’t be fooled by the fact that this strategy worked for a time. You may well have enough of a good sense for an MVP, but that will change quickly. Though oftentimes, even this strategy doesn’t work. As more customers onboard your product, especially paying customers, their needs will differ. If you keep down the path of just building what you think is best, you will likely pay a heavy price that will be very costly to undo.
Multiple products lay at the bottom of the failure ocean due to this approach.
I worked at Microsoft on a very large project that was set to revolutionize cloud computing. It was a classic case of a solution looking for a customer. For several years, the product development was driven by a belief from leadership that this was right for the market.
After about 18 months of development, the company started to talk to prospective customers and flew a bunch (as in 50–100) in for a private event. After showing the product, the response was not what the company had hoped to receive. Customers did not get why this product was necessary and felt the company was investing in something that was just not a problem they cared about. It was a huge rude awakening.
Afterwards, I talked to one of our execs about the feedback. He said, “these are the wrong customers, they are not the right audience.” I was literally shocked at this response. I said, “if they are not the right customers, then why are we meeting with them in the first place?” Crickets.
Flash forward, the project got completely canceled. Tens of millions of dollars down the drain.
All of this could have been avoided had more energy been spent learning what customers really wanted and validating that need.
“I know what they want and the data supports it!”
This is a common justification for you being the customer. Here’s the thing, our brains are tricky. When we strongly believe something is true, we can and do interpret the data in a way that supports those beliefs. That’s exactly what confirmation bias is all about.
In the previous example I mentioned, I am pretty confident this played a big part. The team had done the research, but the analysis was skewed based on the desire they had to deliver a specific type of solution. I have personally also been affected by this in the efforts I’ve led. It is something product managers all need to be very careful of.
Being the voice of the customer means that you are their representative. You will advocate for their concerns and make sure that the product will adequately address their needs. You need to be able to compartmentalize your own desires and beliefs about the product in favor of what your customers have expressed they need.
To represent your customers, you first need to hear and understand them. I can’t over-emphasize how important it is for you to invest your time here.
There are many different qualitative and quantitative ways to hear your customers, here are a few that have yielded the most success for me:
There is no replacement for being able to talk directly with your customers. I believe that product managers should be talking to their customers at least weekly, if not daily. I have found that they are willing to talk about products especially if they know that their sharing can help shape the product. This can be through many different mediums such as calls, messaging, online meetings, or in person at events.
When speaking with customers, try hard to practice talking less and listening more. Channel curiosity and seek to understand what problems they are trying to achieve, how your product fits in, and their experience. Validate whether or not your assumptions are true. Listening here is so important because customers love to be heard and feel valued when listened to.
In addition to learning about their why, listening will help you to uncover other areas to probe further to gain more understanding, or to uncover opportunities.
Include developer advocates if that is relevant to your organization. These teams can be an excellent proxy for what your customers are saying. They can tell you about the key problems that your customers face, both from the standpoint of the capabilities and the experience.
Sales (including sales engineers and solution architects) can inform you of the things customers love and the major gaps that stand in the way of closing deals. Customer success will give you great insight into the problems customers face as they try to onboard the product. Support can help you see where people are commonly getting stuck and the workarounds.
For a platform product, developer advocates will be a great resource for understanding what is holding devs back from adopting or where they are running into trouble.
Surveys can be a great way to collect data and learn about patterns of usage across your different customer segments. With surveys, less is even more. Try to distill down your questions to 10 questions or less, as data shows that customers will be more likely to answer.
Once I see the survey results, I’ll then pick out some customers to talk to so I can further understand their answers and try to avoid drawing the wrong conclusions.
Product analytics are a great tool to understand how customers are using your product. If you don’t have product analytics, you should! You’ll learn which features are getting the most and least usage, how users flow through the product, and where they get stuck. You may be really surprised at what you learn and discover that customers are using the product in ways you didn’t imagine.
Similar to surveys, it is important to follow up directly with customers to understand why you’re seeing what you’re seeing.
These can be amazing resources for learning about your product experience. Forums in particular can be goldmines for where people are getting stuck. One warning here is that these resources can have a high signal-to-noise ratio. It may initially be overwhelming navigating to find the signal. Over time and with practice, this gets easier and easier.
Don’t be afraid to look at your competitors. This will help you understand both their strengths and weaknesses. You may learn about the capabilities of their products, which would be valuable to add to yours. You may also learn about pain points their customers are experiencing, which you can gain a competitive edge on and even win over some of their customers if you address them
You’ve spent the necessary time gathering data and you may have collected a large amount. How can you use it? You need to distill it down and synthesize it. That means aggregating common themes from all your sources and summarizing what you are seeing and why. This is a skill that will take time to gain mastery, but it is critical. You will likely get a lot of pushback if you come to your leaders with a bunch of numbers and without an explanation of the WHY.
As you can see, this is a non-trivial amount of work. How do you fit this in with the never-ending barrage of day-to-day and last-minute tasks? Prioritization.
First, you have to find a way. You may have to put things lower on the priority stack to make room. Second, the work is ongoing. It’s not like you just sit for a day and are done — no, it’s continually integrating these habits into everything else.
It might be two hours one day, 30 minutes another, and five on the third. As long as you are doing something, you will see a benefit, do the best you can. Applying these practices of data gathering, distilling, and synthesis will help you to adequately represent the voice of the customer and ensure that the product is built to meet their needs. Your customers deserve that!
In summary, it is problematic regardless of how attractive it may seem, for you to assume you are your customer. Learn about your customers, become their voice, and echo their needs.
One great book that I highly recommend is Lean Customer Development by Cindy Alvarez. In it, you’ll learn a comprehensive approach to engaging with and understanding your customers’ needs and how to involve them in product development.
Done right, this will have an enormously positive effect on how your product does in the market.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn how to use Fibonacci story points for Agile estimation, avoid pitfalls, and explore alternatives like T-shirt sizing and #NoEstimates.
Randolph D’Souza talks about how he works to align different teams together, such as product, OEM engineering, and sales.
Understanding the root causes of project bloat is essential for aiming to improve productivity and streamline workflows.
Mahesh Guruswamy shares experiences learning from and coaching others on how to have tough conversations and how this inspired his book.
Learn more →
