5 Pitfalls to Avoid When Building Products

Image for post
Image for post

Over the last 10 years in Product Management, I’ve overlooked certain pitfalls that led to uncomfortable discussions with my Development Team & Stakeholders. I’ll walk you through those pitfalls and help you ensure that you don’t do the same in your journey in Product Management.

Preface

As a product manager, you’re required to switch contexts frequently. This has a toll on your ability to focus. 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 — and you end up making mistakes. Fundamentals are thrown out of the window and the focus is to get things done, just so that you can go back home! The tragedy of this is that you end up with a sub-par product/feature that will be raised by your customers.

Note — These pitfalls are not to be taken at face value. Keep them with you as a yardstick to measure your decisions.

1. Do not confuse Customer requirements for Product requirements

If I had asked people what they wanted, they would have said faster horses.
- Henry Ford (allegedly)

Customer requirements that are posed as solutions to the problem they’re facing are incorrect indicators of the underlying problems. e.g. If the customer demands that a new CTA be added to a particular screen on the app, don’t just add it. Find the underlying problem that is being solved. It might be that the functionality already exists, but isn’t apparent! You’ll need to revise your customer journey after you quantify the problem faced. There are 3 other reasons, to the best of my knowledge, that can be attributed to this:

a. The customer may not know what they want

Remember, it is very difficult to prescribe a specific solution and predict its effectiveness without actually building it, or at least building a prototype. The customer knows they are in pain and are prescribing a solution that they deem fit.

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. Do not mistake yourself for 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!

You have 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. Do not mistake customers with users

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?

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 separation.

4. Do not confuse features for 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 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 jargon.

How do you use it?

If you can’t go up to your product and in 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. Do not add features for the sake of adding features

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 a relevant viable problem?

Sadly, adding features will rarely improve your product. The 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 why 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.

Take a step back and understand if you’ve committed the follies listed above. There is a good chance that you might have done some of them. Product management is all about learning, and you’re essentially building your database of issues to avoid. Please use the above to identify and improve yourself on your product journey.

Thank you for reading!

Written by

Simplifying Complexities for a Living | rkakodker.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store