Lessons from the experiences of a Product Manager
‘To err is human.’
-a partial Alexander Pope quote about forgiveness
To avoid easy errors is wise. Be a wise human. As a product manager, you will make mistakes. If you don’t think you have, you lack self awareness and reflection. Below I share some mistakes I made, so you can avoid them. It covers goading the developers instead of inspiring them, pretending you know best, refusing to reverse a decision, rushing things that can’t be, and assuming requirements are obvious. Happy reading.
Mistake 1 — Goad the dev. team instead of inspiring
You have a new dev. team — welcome! Before you joined, they also worked. You’re the new one, not them. They have their processes, their habits, their expectations. Their pace, their priorities, their way of work. You can’t strut on in and expect to headbutt the team into working faster or harder. Oh, you think it’s cool to be ambitious, but why should they care? ‘Let’s work harder so we can achieve more!’ Oh, but you’re a tough guy drill master locker-room motivational speaker who expects everyone to magically fall in line with your new drives and tougher expectations? Good for you, no one cares. Tell it to the wall. Ok, so you want to second guess them or their work by asking why does this development take so long? Inquire away, but if you come close to insinuating that something is their fault, in a way that makes them feel that they could and should be working faster or harder, then you will cause harm and demotivate them. Have some tact, c’mon.
They want to succeed, too. Remember that.
Instead, you have to gain their trust and inspire. You have to help them improve. You have to help motivate them to want to do better work. You have to create space for each member, and the team, to thrive. You can do this by helping elucidate the impact of their work. By helping clear obstacles and frustrations. By empowering them with more tools. By making room for their ambitions and expressions too. For their input, creativity and strengths. Make space for their contributions. By connecting them with resources, and others who may be able to help. By improving their lives and conditions. By showing you care about them, and by actually caring about them. Sounds lovely-dovey hippy-dippy kumbaya stuff, but it’s real and it’s legit.
Mistake 2 — Pretend you know best
You will know less than many of the people you work with. You will know less about marketing than the product marketing manager you work with. You will know less about technical writing than the technical writers you work with. You will know less about developing in the domain of expertise than the tech lead developers who have been working on this stuff for ages. You will know less about design than your designers. And on and on.
You have to admit that. First, to yourself. Then, in your interactions with other experts. True, it is your responsibility to lead and align, to ensure delivering value outcomes to your key stakeholders. But that does not mean it is your responsibility to know how to write the best line of code. Or to know what the best software architecture to use for this particular feature. To know what interaction pattern to use for this interface. That’s where collaboration comes in. Teamwork. Relying on others.
Pretending you know can be harmful for several reasons. First, (a) it will lead to bad product decisions. You will by definition be making decisions based on insufficient information at best, and on errant information at worst. (b) Next, it will alienate you from your expert colleagues. They want to feel utilized. They want to leverage their knowledge and expertise. They want to be relied on and challenged. And if you don’t use their help, since you pretend to know best, then you distance yourself from them. No one wants to work with a know-it-all. Additionally, (c) it will make you stagnate. If you pretend you know, then you can’t learn. You can’t ask questions. You can’t take an explorative inquisitive mindset. You’re stuck in a fixed (conceited) mindset that is not conducive to growth. Also, (d) it will reduce trust and confidence in you. Others will pick up that you don’t know (remember, they know more than you), and will realize that you’re full of it, that you’re pretending to know things you don’t. And they will second guess your decisions, and undermine your ability to collaborate effectively with them.
So stop pretending, and start asking questions. Start filling gaps of knowledge. Ask colleagues where you can learn more about a particular subject. Ask for their advice. Make yourself a bit vulnerable. You may fear that this will make you look like an idiot. Like an ignoramous. There probably are things you should know but don’t. But everyone has gaps. And once the domain expert express their opinions, and you understand the reasoning behind their opinions, it’s still your responsibility to weigh all relevant factors and to make the tough product decisions.
Being transparent about what you don’t know will only increase respect for you. You’re not saying that you will never know, just that now there are gaps, and you need help filling them. And when you do catch up and learn whatever it is that you have to learn, then you will be in a position of strength and power to make informed decisions.
Mistake 3- Refuse to reverse your decision
If you’re an effective product manager, you’re making tough decisions. A decision is tough when information is partial, uncertainty high, ambiguity rampant, and important stakes. So you assess risk vs. reward, see if you can defer the decision (you can’t), and jump in the water with best guess. A feature is developed or skipped, and you monitor the consequences of your decision. Turns out, you were wrong. This sucks. People who disagreed with you can now say ‘I told you so’. You question your efficacy, your worth, the value you bring. For the anxious among us, this risks metastasizing into a general self-questioning. What are you even doing as a product manager? As a professional of any kind?
When you come to your senses, you realize that the cataclysmic end of the world has not yet ensued. True, your decision was wrong. But, alas, maybe you can fix it, or at least recover partially? The worst thing you can do is get defensive about your wrong decision. Strong psychological mechanisms are at play in order to protect your precious precious ego. It’s not you who made the wrong decision, no, it was because, well, it wasn’t implemented correctly. The product failure is due to, er, poor marketing. Flawed design. Yea, blame the designer. Or because the software architects forgot about dead letter ques. No, your decision was right!
This rabbit hole of ostrich denial is destructive. It hurts your credibility with the dev. team and others in the organization. It will continue to hurt your product and customers, since not admitting wrong decision leaves you trapped with it. In order to fix it and recover, you have to first admit that you made the wrong call. Be mature enough and accountable enough for your role team and product, and fess up .Once you can do that, there are ways to recuperate, at least partially. Undo the feature you built. It was a mistake. Or change it, so that you reverse the flaw you created. Re-design it. Re-develop it. Re-factor it. Whatever, address it in some way. Don’t let fear of being wrong dominate your conviction to bring awesome products and features into the world.
Mistake 4 — Rush that which cannot be rushed
Moving fast is trendy. It’s survivalist. It’s economic. It’s appealing. That’s what the MVP is for, right? The half baked not-yet-ready version to iterate on. But sometimes no, fast can be too fast. If your product or feature is not well enough thought out, then don’t send it to be developed. If the effort estimate of the responsible dev. team is large, you cannot rush the dev. team into doing it in half the time, without removing scope from the requirements. Don’t rush. Yes remove defer and eliminate scope if you can.
Mistake 5— Assume Some Requirements are Obvious
This itself is obvious, but needs to be stated: if you as PM/PO do not require it, the developers do not know to build it. That which is obvious to you may be lacking in the understanding of others. Respect ‘theory of mind constraints. Do not have expectations of users or developers. Just write it out.
Thank you for reading.
About this Series
This article is part of a series on Product Management. based on my experiences.
About the Author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
