Originally published on Medium on Jan 18 2020
Bad products are everywhere. Products that simply aren’t useful, don’t work right, are too difficult to learn, or that take forever to sell. Most of them suffer the common pitfalls of product management.
Being a product manager takes you through a fast-paced viewpoint changes. One moment you are viewing a problem from 10,000 feet and the next moment, a tough design decision drags you to 50 feet. Every day, you experience this movement a thousand times. It is tough to stick to your fundamentals and you do end up making mistakes. There are, however, some pitfalls that occur so frequently and are so damaging that I believe they are at the root of the vast majority of bad products. Over the years, I’ve been able to build & keep these 5 pitfalls (honestly, a few more, but 5 for this article!) to avoid when building products.
Note — These pitfalls are not to be taken at face value. Keep them with you as a yardstick to measure your decisions.
1. Customer requirements are not product requirements
If I had asked people what they wanted, they would have said faster horses.
– Henry Ford (allegedly)
As product managers, we’ve to be wary of the customer requirements we get from sales/marketing teams. There are 3 main reasons why a customer requirement could be wrong:
a. They may not know what they want
And it’s not because they aren’t smart! Remember, it is very difficult to proscribe a specific solution and predict its effectiveness without actually building it, or at least building a prototype. Meaning that they know they have a problem, and are prescribing a solution that they deem fit. It is always better to know the ‘customer problem’ than the requirement.
b. They may not know what is possible
Simply because it’s not their job! Again, requirements tend to be solutions — it is safe to say you know more about the solution possibilities than the customer.
c. They may be solving ‘their’ problem
It would be impossible for a customer to know the array of problems and opportunities their problem provides. By prescribing a solution, they’re simply eliminating their problem. You, on the other hand, have a bigger view of the problems facing the customers — sure they’re prescribing that a particular KPI set be displayed in their dashboard, but wouldn’t it be easier to provide a custom dashboard option?
How do you use this?
Whenever you get requirements from the customer-facing teams, always look for the problem they’re solving. Finding out the problem is half the battle won!
2. You are not the customer
It’s tough to separate yourself from the customers. Empathizing is trying to understand the customers’ pain-points and worries. However, once that is done, a product manager must be objective with their decisions.
To keep us honest and on track, you must constantly put your products in front of customers directly from the target market, and consider carefully their response. Strive to keep their perspective in mind and not your own understandably skewed viewpoint.
How do you use this?
I try to avoid anecdotal evidence when it comes to requirements or arguments on requirements. Ask yourself, do you have sufficient evidence (from either data or user testing) to justify the requirement? If yes, proceed. If not, find the evidence. You’ll be surprised how many times an obvious (to you) concept is shattered by data!
Remember, you come with confirmation bias — you’ve lived the products’ entire journey, you’re already aware of its points of failure. Your customers are trying the product for the first time — they’ll have no experience with your product. Keep things objective and always test!
3. Are you looking at a customer or a user?
Ecommerce product managers know their on-site statistics on the tip of their tongues. But ask them about the difference in behavior between a transacting and a non-transacting user? Boom! They’ll struggle!
Here are the reasons why we should differentiate between a customer and a user:
a. Customer experience is vital to your decision making
More often than not, customers are those who see value in your product — enough value to ensure that they’re investing in it. You should treat their behavior, their requirements separately. Studying their behavior helps in converting a user to a customer.
b. User behavior is general — Customer behavior is specific & determined
Returning transacting customers to a site will always display determined and specific behavior. There won’t be any looking around or searching for features. They already are aware! They skew some of the metrics associated with feature KPIs, so it helps to separate it. Understand your user behavior, separate from customer behavior.
How do you use it?
Personas. Use personas to determine who is the primary beneficiary of the feature/improvement you’re undertaking. Ensure you’re keeping the stats separate, and tracking them. Coincidentally, I’ve found that at the start, both the customer & user behavior align — but after a while, there is a definite shift.
4. Features are not necessarily benefits
It is very easy to get absorbed with the specifics of the features that make up your product, rather than the benefits that those features may provide.
The product’s value proposition speaks to the benefits, not the features.
Your feature must have a clear, simple and compelling value
proposition. Your target market must be understood, and the users in that market must perceive that your feature solves a real problem.
There are several possible reasons for poor value propositions:
a. The most common one is that the product is not solving a significant problem.
b. The feature is an interesting technology still looking for the right application.
c. The feature is valuable and useful, just not to the people in the target market.
d. The feature is simply too expensive relative to the benefits.
e. The feature is ideal for the target market and very economically priced, but the messaging is so complicated that the value is lost in the haze.
How do you use it?
If you can’t go up to someone in your target market and less than a minute explain what the product is all about and why the product is relevant to them, then you have a significant problem, either with the value of your product, or your messaging.
Try to create a small tweet describing your feature — is it compelling to the customers? Will your customers pay a pound for the feature — only from a tweet? Test it out!
5. Adding features for ‘product improvement’
It’s a business myth that adding more features will somehow make the product ‘better’. Sure, it’ll add more features to it, giving the sales/marketing teams another point to sell the product, but are you solving the problem?
Sadly, adding features will rarely improve your product. Sales team will tell you “the customer likes the product but needs it to do X” or the marketing folks are saying “we simply have to add y and z immediately because our competition has those features” Or worse, you find the business dictating the shotgun approach of “we’ve tried a and b, so it must be c and d that we’re missing.”
While admittedly, you are lacking some crucial functionality, you must dig deeper and understand how it was missed earlier. More likely, your product has one or more of the other issues in this list of common problems, and rather than addressing the underlying issue, such as usability or value. You’re merely looking at features as a short-term solution. More likely, adding those features will only add to your problems in the long run.
How do you use it?
Start first by understanding your current features and how they’re performing — v/s market, v/s expectations. Are they for the right market? If yes, try to improve them. Track those metrics and seek to push them to their best possible level. You might need to sit down with the business team and see if you can open up some of the walls (payment/registration requirements etc) for free users to get into your product. This should provide enough arsenal for you to take the right decision for your product.
There are a few more that I’ll cover in a subsequent article. The important thing to note here is that with Product Management, nothing is absolute!
Your journey in product management is a constant write-rewrite of empirical information.
Thank you for reading!