Five Product Pitfalls and How to Handle Them
Whether you are new to the position or you have your fair share of experience, there are some dangers for product managers that not many people talk about.
I like to think that I have a lot of experience building products. Not because I’ve been doing it for a long time, but because I’ve made a lot of mistakes.
One of my key characteristics is to feel confident about things that I don’t know enough about. This creates something of a “hit or miss” approach to my personal development. I either ace things really fast, or I fail spectacularly the first time I engage with something new.
Most times I’ve failed in product management was because the risks were hidden. Sometimes they were not obvious, other times I was misled by common knowledge. In this article I recall a collection of pitfalls where I’ve fallen into headfirst.
The following five pitfalls are examples of so called lessons I’ve learned in my product management career and thought to be true. In retrospect, I now know that I was wrong and misinformed. I hope that by writing this article, I can prevent you from doing the same.
1. “Deadlines are for projects, not products.”
Every single product manager, me included, listened to this at least once: “When is it ready?”. To which I responded “day XX, but this is just an estimation, it can change”. Not setting up dates made me lose the trust of some very important stakeholders, which I believe was one of the reasons for my termination.
Both product and project management have negotiable triangles. For project, time, cost and quality are variables, while scope is always fixed. If you need to negotiate, the customer choses two of them to focus, one to leave behind. Product management changes scope for quality as the fixed variable, since quality is unnegotiable. You choose two to prioritize again. Time is a common variable for both.
In several cases, time is the single most important variable. Assume you are developing a minimum viable product (MVP) to show at a convention, for example. Your teams work is meaningless if you don’t meet the event deadline. Turning a blind eye for time is like cutting an arm off. This is why I’ve learned that product managers should know how to read every demand they have and assess where they have more leverage to negotiate.
2. “People read your documentation.”
I’m not very good at creating documentation, and to be honest, I don’t know many people that are good at it. Most teams I’ve worked with are very lousy when it comes to historical tracking. There is a reason why.
Documentation is very important because we can’t hold every information we come across in our minds indefinitely. Despite that, you sure don’t have to spend the majority of your time writing instead of conducting discovery or enabling delivery. The reason and the hard reality—is stakeholders and customers don’t read.
Stakeholders and/or customers won’t read your six month roadmap. They won’t read your Kanban board. They won’t read your four page feature documentation. In a lot of cases, this is also true regarding your managers and team peers. If you write things down and don’t actively go after the interested parties and talk to them, you are as good of a communicator as a news anchor that can’t speak.
3. “This is not my job.”
More than once I’ve been guilty of saying this statement. I remember saying these exact words when I was asked to manually control the formatting of e-mails going through our newly built engagement rule. It was not long until I lost the product to the marketing team who did a much better job than I did.
Being a product manager is about making sure that your product is awesome. Depending on how your team is structured, that might mean that you must play the designer sometimes, or the quality assurance(QA), or the business analyst(BA).
It’s an unfortunate experience to have to do something that you didn’t prepare yourself for. It’s even worse to do something that you know won’t forward your career. Maybe the product is so new that you have only the frontend, and everything behind the curtains should be done manually by you. These realities I have now learned, is a part of the product manager experience. If you ever let go of a responsibility that “is not yours” and the product suffers because of it, you will be accountable for it.
4. “Fail fast.”
Failing fast and experimentation came to light in the wake of The Lean Startup movement and has been part of the product management dialogue ever since. The idea is that no matter how much research you do, you are walking blindly into the night when it comes to user adoption.
Product managers everywhere took this at heart and started treating ‘product growth’ as a form of ‘mad science’. They tried every kind of test (or worse, feature release) in the hopes of maybe finding the one silver bullet that will drive numbers up.
I’ve worked with a team once which the sole objective was to conduct tests on the product. We had the entire thing at our disposal and we were supposed to find a way to increase conversion. We were doing around two tests per week, but we ended the quarter with no budge on the metric.
The intention behind “failing” is not to press luck. It is to learn what doesn’t work. Every failure should lead to learning, which is then applied to the next iteration in the hopes of not failing anymore. If you failed and haven’t learned anything, it doesn’t matter that it was fast. You’ve just failed your product.
5. “If the user wants it, he’ll use it.”
User interviews are an art on itself and it often receives little attention from product teams. This dialog is an adaptation from a real interview I participated in once. It’s an amazing example of how the wrong question can lead to the wrong conclusion:
“Would you be more inclined to buy a fridge if it was 50% off?”
“Absolutely!”
“Great! Here, take this 50% off coupon and buy a fridge at my store.”
“No thanks, I don’t need a new fridge.”
The sheer amount of researches I’ve come across with unintentional bias imbued into them is staggering. People making questions often don’t want to discover, they want to validate, and that’s the biggest pitfall a product manager can fall into. Learning this reality reminded me of a quote from Teresa Torres in her article “Ask About the Past Rather Than the Future”
“You don’t want to ask people about what they would do. They simply don’t know. We are notoriously bad at predicting our future behavior.”
When you ask your customers if they would use something, there is absolutely no guarantee that they’ll use it. On the other hand, if you understand why they are asking for a given feature, and how they’ve used similar solutions in the past, you would have a greater chance at discovering the right solution.
To find out more in regard to avoiding pitfalls
This article was inspired by a presentation done by Dave Wascha in 2017 during Mind the Product Convention, “20 Years of Product Management in 25 Minutes”. This talk is packed with mistakes and lessons from his own experience. If you haven’t seen it, I beg you to do so right now.
For a more “advanced” post-reading content, Marty Cagan has been developing a new circuit of lectures called “Yes, Product is Hard, but WHY?”. He explores a lot of topics that I haven’t covered but can also be considered pitfalls: MVP usage, Lean vs Agile, Solution tunnel vision and much more.
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
