My Biggest Mistakes When I First Became a Product Manager

I first worked as a Product Owner when I was 23 years old and had less than a year of full time experience. As with most Product Managers at the time, I got my role by overstating my knowledge and experience, ultimately leading me down a path of real time learning and wisdom building. Upon reflection, here are the biggest mistakes that I made in my first Product Management role:

My first grooming session in a nutshell

1. Pretending I Understood What The Development Team Was Saying

In my first role as a Product Manager, I embraced a “fake it til you make it mentality” towards getting things done that had actually worked pretty well for me through internships and college. In my first years’ grooming sessions, I would discuss a user story as confidently as I could manage and open the room up for questions as cooly as possible, while praying to God that there were no questions. There always were. Developers would ask lightly technical questions (“Where is the information stored?” “What is the mechanism for storing?” “Do we own the data?”) and I would flounder. I would NEVER ask clarifying questions and would as often as possible attempt a “let’s take that offline” to get the heat off of me and my ignorance, doing my best to point developers towards someone I felt could better provide clarity. The fear was that the team would learn that I was an idiot that didn’t know what I was doing. Particularly being a 23 year old woman in a reasonably male dominated industry, it felt like everyone was realizing how out of my depth I was.

The reality is that we were one team. I could have really used my first few months to vulnerably ask questions and learn. I could have had a weekly 1:1 with the tech lead and brought all of the items that I didn’t understand to him. Instead, grooming sessions and sprint planning sessions were anxiety inducing for me, unfruitful for them and I was singlehandedly ruining opportunities to be vulnerable and collaborative. It took a couple of years to learn what level of knowledge I should have, and when it was appropriate to not understand all of the details of a conversation and raise a, “What should I be taking away from this discussion?” instead of nodding my head and pretending like the difference between an ELB and an EC2 was meaningful to me without further explanation of the differences.

2. Not Appreciating The Value That I Could Bring To The Team

In a very similar vein as the first point, I spent my first year as a Product Manager extremely focused on the knowledge that I lacked. I signed up for coding bootcamps, got an architecture mentor and really focused on developing my technical knowledge. The reality is that, while technical knowledge is certainly helpful and will gradually come with time, I should have spent more time focusing on the actual value that I brought: Having the widest knowledge of the goals, objectives and stakeholders of the product.

The first product that I ever worked on was for a global cosmetics company. I was the product owner for the creation of their internal repository of formulas, chemists and products. We already had the designs in hand from the design agency, and it was my job to simply execute. Holding the design in my hand and relaying what the designs are to a development team felt like the most intellectually offensive way of engaging with a development team. Surely, this team could look at these designs and build this themselves without me writing Jira tickets describing what it is that they are obviously already looking at?

The reality is that, as a Product Manager, not only did I have the widest view across our stakeholders, strategy and customers, I was also the only person that could really give meaning to the work to our engineers. The development team was less than enthused at spending their time creating a lipstick repository for internal associates (“Lipstick and lip gloss are the same thing, right?”), but they WERE enthused at the fact that we were improving efficiency for chemists by 20% by cutting down on their need to find people via e-mail. We were going to have to problem solve around storing all of the chats for 7 years, as per the legal requirements, in the event that the company were to be sued or face litigation. We had to create a search engine from scratch and it was the first time some of the engineering team members were brought to the user research sessions to hear how they interact with the products (SPF strikes fear in the heart of all legal teams) instead of just receiving a tactical ticket describing a feature. What was simply a search bar on the UI, was 4 sprints’ worth of logic and testing that ultimately was a make-or-break feature for whether associates with actually use the product (Shocker: You actually can’t MAKE associates use their internal tools. You can only build and beg).

3. Grounding My Vision In A UI/ Experience And Not An Outcome

This one is a bit more complex and took be a couple of products to get the hang of it. Continuing with the repository product from earlier, my vision of the product that I would be launching was entirely the designs that I was holding. My personal view of a successful project and release was whether what we launched replicated the designs down to the last pixel. While this is certainly noble, the reality is that what I should have been tracking against wasn’t bringing the designs to life, but rather creating a tool that associates use, find value in, that creates efficiencies and lowers risk.

If I had the experience that I have now, I would have noted that my goal KPIs would be:

• 80% of associates used tool in the last 30 days
• Positive associate NPS survey recommending the product
• 20% decrease in time to market speed
• 0% legal audit findings

The KPIs that I was actually tracking against:

• 100% of the design team likes me

4. Embracing Failure

A good Product Manager makes sure they are releasing MVP iterations that they track, measure against and learn from. The goal of this approach is that it is easier to pivot and that too much time and resources aren’t being put into a wrong mistake. Something that took me a long time to learn is that launching a feature that doesn’t work is not a sign of failure. Failure is being unwilling to acknowledge when something doesn’t work and refusing to pivot or retire, ultimately digging your hole deeper and deeper.

I worked at Citi for a couple of years early in my career and found the environment to be extremely positive in this regard. On a monthly basis, all of the primary and partner teams would meet up for a huddle and, one of the items of that huddle, was to give an award to whoever had the biggest failure that week. The message was twofold: If noone is failing, then we aren’t taking any risks, and if people are afraid of failing, then we won’t be pushing any needles. This was monumental for my career. Those weekly huddles and that award have led to me being someone that is exceptionally comfortable with acknowledging and owning mistakes and failures. Having a perfect record of releasing perfect products is not a track record that is good for a product manager to have. It means that you are operating in a box, not taking risks and perhaps not defining what “success” and “failure” even is.