How important is it for a product manager to truly believe the product that he is handling?
Example: product manager finds that the product is complex and personally prefers not to use it. Will that affect his ability to perform his job?
I actually get this question quite often, usually from product managers that are actively working on something that they either don’t believe in or don’t use in their day-to-day lives. Although I am sure there are some situations where the product manager can’t physically use their product, I feel it is IMPERATIVE that they try.
You have probably heard the saying “eating your own dog food” (https://en.wikipedia.org/wiki/Eating_your_own_dog_food) used by Google, Facebook, Microsoft and others either in passing or through their own product managers. This practice is vital to overcome what I refer to as the “why” of your product.
To be a successful product manager you need to not only embody the skills of your team, understand what each person does (and sometimes be able to step into some roles if needed), understand the market and your users, understand and be able to process the data and metrics of your tests and iterations, you also must understand the product itself and why people use it. Through working on the product with your team and users, you will be able to see how it is being used and optimize on that to make your product better with time. The problem is, that misses a substantial part of what you could do with your product by understanding it’s why. The “why” isn’t just the problem you are solving or the barrier you are removing, it is the essence of your product. I feel that unless you use it at the same pace as your power users, you won’t truly understand how the product fits in your daily life, why it is important and more importantly, what it doesn’t do that it should or what it does do that it shouldn’t.
I also think the product needs to be used and understood by the entire product team to be really successful. To make sure this is the case, I commonly introduce an exercise used in each sprint to focus finding and destroying bugs before a release. This practice is set up using real data, real accounts in real situations. At ShopIgniter, I made sure that engineers, designers, and even sales reps had active store-fronts that could take real orders on real merchandise for testing. At Target, with Cartwheel, we made sure every team member had their own active account and shopped at a Target with real offers to make sure their experience was as quick and painless as possible. Through that work, we quickly found ways to make the application better, faster and more responsive to the “why” people were using it. A great example of this was the barcode scanner idea coming directly from the team before our users even had access to the app (it is not the most praised feature).
