5 huge mistakes I made in my first months as a product manager
Focusing on the solution, not the problem
A few weeks after I started working as a product manager, I was assigned a low-stakes product that lost its owner and kind of just lived a life of its own. Occasionally something happened when someone had the time for it, and sometimes nothing happened for weeks.
It was supposed to be a tailor-made internal solution, inside of an already existing and quite heavily used internal application, that was supposed to solve an issue one of our engineering teams.
At the time, the product already had a history. Decisions were made, trade-offs happened, merge requests were merged, deadlines were stated and not fulfilled, stakeholders asked for updates and showed their frustration… everyone was getting anxious, and I wanted to push this to the finish line and get a quick win. So I took some time to study the history, understanding the product and how it was supposed to work, and so on. Then I started focusing on the delivery, helping the team inch it towards the win.
You probably see where this is going. I was helping with delivery, but we were building the wrong thing.
In my defense, I did talk to the requestors, but in reality, I should’ve spent the first hours and days asking very different questions than I was. It took me a couple of uncomfortable interviews to figure out that the solution that we invested our time into was no longer solving issues that the team was experiencing, and many of the features that were at the beginning specified as must-haves have shown to be too difficult and time-consuming to make into a reality by the product team.
I knew the what and the how from my own research, and I believed I knew the why because the problem was clear to me. If I dug deeper, just a bit deeper, and asked some uncomfortable questions, I would’ve understood that the solution wasn’t going to work on the first day. However, I accepted it, started to like it, and it took me too long to challenge it. Why are we doing it like this?
In the end, it was all just good old sunk cost fallacy. And since there was no owner, nobody felt in the right to make the decision to scrap it. So we scrapped it, and started again and right. The problem was clear and simple, but the solution was inefficient and unusable and not solving the right problems.
While my example was pretty specific for a certain scenario, the advice that I have is simple and universal, and commonly known. Make sure that you identify what the core of the issue you are solving is, and don't fall in love with the first solution you come across, even if you have already invested time and effort into it. Fall in love with the problem.
Focusing too much on delivery
Looking back, even at the example above, I’ve spent a big portion of my time focusing on delivery, and not even close to enough time on discovery. Focusing too much on any one thing is an issue, so you should strive to find a healthy balance. And a balance that works best for your company. In some companies, a product manager will be there to fill in the gaps and serve as a patch for certain things and processes that are not working very well — which could be unfulfilled deadlines. If you are lucky, you will be living your Inspired dreams filled with a bit of everything that makes Product Management such an awesome career.
If you are working for a company where product managers are expected to be Project Managers, you will most likely find it hard to find time to do everything else while focusing on driving projects forward, keeping stakeholders informed, and getting rid of impediments & roadblocks. If on top of that, you are also a meeting facilitator, cross-team coordinator, a scrum master, a tester, … you might not even get to think about doing any discovery work.
You should be talking to your customers, even if you have dedicated UX Researchers. You should be aware of what your competition is doing and do regular checks yourself, even if you have Market Analysts. You should do experiments and try to find the best solution together with your team. You should be doing all of that and much more, so make sure that you get your feet wet as soon as possible, and don’t take no for an answer. Don’t just be a deadline keeper, or you might get stuck doing that forever.
Not involving engineers, designers, and analysts from the start to “spare them the trouble”
For a while, I honestly thought I was doing people a favor. I didn’t want to bother anybody, especially engineers, and I also felt the need to prove myself and show that I could prepare that fleshed out specification myself. I would write the specs down in detail and hand it to them so that they could use their time for the most valuable thing they know how to do — coding. “Don’t worry, leave this unnecessary ideation to me”, right?
Very, very wrong.
On one hand, an engineer’s time is precious and should be handled with care (for example, don’t invite them, or anyone else, to useless meetings). On the other hand, great product managers include developers, designers, analysts and sometimes others who will be involved anyway from the beginning, because they know that working together with them will allow them to find the best possible solution, and how to validate it and build it right.
Especially at the beginning of your journey, you are going to get things wrong. You are much more likely to get things wrong if you only think about them by yourself with minimal involvement from the rest of the product team. Involving people is going to make everyone’s job easier — not harder — and you shouldn’t be afraid to ask for opinions, or straight up ask for help.
Making assumptions & taking things personally
This piece of advice is useful for life in general, and it's also quite self-explanatory. Especially in product development, it can make everyone’s life hell if people's assumptions don’t match.
Here the advice comes first. Don’t make assumptions about your users, your product team, or your stakeholders and their needs. Just don’t.
When building a product, or anything, ask questions, see if users or data support your assumptions, but don’t just assume something and call it a day. Even dealing with interpersonal relationships, it’s better to verify what you think is happening, because sometimes it’s not, and it can lead to some juicy office drama.
Without data, you’re just another person with an opinion.
Working as a product manager, there will also be times when people who don't see into your head and all of the decisions you made and why you made them (so, most people) will question you, and your decisions, or make assumptions as to why you have made some decisions. There will be times when they will heavily disagree with you, and tell you that your brilliant idea is not a brilliant idea. Sometimes, they will be right. It's a part of the job. Hopefully, most of this feedback will be constructive, and you will use it to move you forward. Either they will be right, and they will save the company some trouble and time, or they are wrong, and you might decide to communicate your decision making process more in the future.
Not communicating enough
Communication is where it all starts and ends. If you are not communicating enough with your product team, stakeholders or users, you're gonna have a bad time.
Especially if you are working with a remote team, you have to make sure that you are on the same page. You don't have the luxury of bumping into each other near the watercooler and resolving a small misunderstanding without it becoming an issue. You have to make sure you have channels open that allow for all kinds of information to flow through, and more importantly that everyone feels safe to speak their mind, and know that they can bring up anything for discussion.
When in doubt, overcommunicate.
Are you not sure if your team is interested in what you have to say? Would you mention it or would you ask your colleague about it during lunch or coffee? If yes, it's probably worth mentioning it. The same goes for updating your stakeholders — are you not sure if they'd be interested in what happened in the last two weeks, even though the answer is “nothing happened”? The answer is probably yes.
“There has been no new development since the last time, we are trying to figure out if there's an easier way to do it. I'll update you in the next two weeks.” is much better than silence, followed by more silence, followed by an “Ok, we can't do that.”.
When working remotely you have to very actively decide to communicate, while if you are working with people together in the same room, information usually flows by itself. Make those extra steps and keep everyone informed. If you don’t, it might come back to bite you in the ass.
Thanks a lot for checking out this article! If you liked what you read, feel free to connect with me on LinkedIn, or read one of my other articles below!
