3 mistakes I made as a new PM
and some lessons that I've internalised from them.
When I decided to apply to be a Product Manager at Spotify, my only Product ‘education’ came from reading The Lean Startup and Inspired. My Product ‘training’ came from working in teams with two great mentors, Johan and Irene. My only Product ‘experience’ came from covering for PMs who took their Swedish summer holidays, paternity or maternity leave.
That is to say, I had no formal education and no formal training on Product Management. I felt like the biggest imposter as I put on the PM hat on in my first sprint planning meeting with my team. Without any foundational background to lean on I needed to use my intuition and common sense to work in a way which I felt would have an impact. Intuition which was formed from watching Irene and Johan. This got my started. Reflecting and learning from myself and my own mistakes how I’ve continued to grow.
In the latest episode of the Product Internals podcast, Arvid and I discuss tips we would give to a new Product Manager at three critical stages of onboarding (1 month, 6 months, 1 year).
Here are the three mistakes that I made early in my career, which helped me internalise the lessons which led to those recommendations.
1. Trying to have all the answers
It is the Product Manager’s responsibility to make ‘Product Decisions’, or decisions which affect how users interact and derive value from your product. That’s true, sort of. But if I’m a new Product Manager on a team then I definitely won’t be the best person to make those decisions. The engineers, designer, data scientist, engineering manager, or literally anybody else who has been there longer than I have will have more context and therefore be more qualified to make those decisions, at least at first.
So I spent my first 6 months learning as much as I could about our product and the problem it was supposed to solve. I read all the documents, I had 1:1s with all my teammates to learn the historical context. I met with lots of users to understand how they were actually using and abusing our product. It was way different than we thought (of course!). I learned like a sponge and 6 months in I could give a reasonable answer to pretty much every question about our product and strategy, either from the team or from stakeholders. I had an explanation or justification for every challenge and critique.
In retrospect, that first 6 months was well spent. This helped me ramp up tremendously and I was able to positively influence our team and product quickly. But the critical mistake was thinking that it was a good idea to actually have answers. My ideas and answers weren’t bad, I was never bullshitting. I had varying levels of confidence in the things I was saying, but I did always believe that what I was saying was reasonable. I would often get very insightful questions on something I had thought about just enough to have some idea and I would answer, but it was not necessarily an answer I had fully thought through. And giving an answer in these moments effectively shuts down conversation.
Consider the person asking that insightful question. They are asking a question which is insightful because they have a lot of context themselves. Quite often they have an opinion themself too, and I really want to hear that opinion! If I give a half-thought-through answer to this person I risk losing what they can teach me. And they would not only teach me what they see, but could also teach my team or others who might be listening like other users, stakeholders or leadership.
When you get a truly insightful question, the sort that stumps you a little bit, instead of trying to come up with an answer respond with this: “That’s a great question, I do have some thoughts on this, but what do you think?”
Having all the answers isn’t my job. Making product decisions isn’t my responsibility alone. Leading and empowering my team so we can do it together is the job. And I need to learn from them, as well as from our users and stakeholders. And together we’ll make the best decisions.
2. An implicit, verbal strategy that we “agree” on
After that first 6 months I started to form opinions. I understood the bigger picture, how the problem we’re trying to solve fits in and why it’s relevant and important to solve now. I understood how our product actually would solve this problem and what the future perfect world would look like after we’ve solved it. I had a product vision in my mind. I formed opinions on what the plan should be in order to actually achieve this vision.
I formed these opinions with the help of my team. We had lots of conversations together as a team, as well as in 1:1s about the plan, and why we believed it was a good idea. I pitched the plan to our leadership and stakeholders and they seemed to agree. This plan was our strategy. Everybody pretty much agreed that this strategy, that we had verbally aligned on, was the right way forward. Pretty Much.
Within my team, each person understood about 80% of the plan and 20% was confusing (this 20% differed from engineer to engineer). In some cases I misunderstood the input I got from my teammates and created miscommunication. In others I hadn’t explained myself well enough and they couldn’t internalise the reasoning that I had in my head. The stakeholders were onboard but didn’t grasp the implications of what I was suggesting, especially since it required other teams in the company to do some work.
We broke down the strategy that we were pretty much aligned on into next steps and a roadmap. Then something (un)surprising happened. We started arguing about the finer details, about some peripheral use cases, about some tradeoffs we were making. We argued a lot, and we had the same arguments repeatedly. It was debilitating. We did make some progress, and what we built did follow the strategy. But on the more controversial points we were going around in circles.
The mistake I made was assuming this implicit, verbal alignment and agreement was good enough for strategy. By simply writing the strategy down on paper, things improved drastically. I included the historical context, the justification for such a plan. I also included the tradeoffs we had decided on making and why. This took each engineer from 80% alignment to maybe closer to 95%. And that remaining 5% was the same for everybody. There was no more confusion or misunderstanding, we were aligned on what we were misaligned on. Our productivity picked up almost immediately, and together we were able to pragmatically approach and resolve the unknowns and controversial areas.
Taking verbal alignment on a plan to a written strategy sounds like it could be unnecessary work if you are truly aligned already, but even still it provides a reference for all of us, including new members of your team. It provides a single place (the google docs comments, that is) to ask questions, raise concerns, or discuss things we don’t fully agree with. We still take these conversations in person but now we can be pragmatic about it and discuss the right things. We share context faster, align faster, take decisions faster, build faster, and learn faster.
Have a great idea and a brilliant plan? Write it down!
3. Being Busy
As a Product Manager I have a lot of responsibilities. I want to be a proper member of the product team and join stand-ups, plannings, retros and other team-local meetings and discussions we have. I need to meet with users and stakeholders. I am also a leader and am part of a leadership team within my department as well. I am occasionally leading some large project where my team is a key part, which means more planning and checking in on the different workstreams to report progress and concerns to stakeholders. Occasionally I am also hiring and need to spend time talking to candidates and interviewing. The meetings pile up, and it's all very busy. But that’s the job right?
But the work that I’m responsible for doesn’t really happen in these meetings. I also want to dig into data, to consolidate and understand user research, to come up with and write down a strategy. I probably should spend time preparing for quarterly and sprint plannings so I can lead the team in the right direction. I need to read other strategies and documents which are floating around the company and are relevant to our product and my team. And I need to spend time understanding the big picture, and how my team and product fits into it. That’s also a lot, especially on top of the (un)healthy dose of meetings. I was incredibly busy, but that’s the job right?
I did my best to squeeze the real responsibilities in between meetings. I managed to scrape by doing a good job, working very hard and getting done what I considered to be the bare minimum. There wasn’t time for anything else! I thought that being busy and filling up my time with meetings was the nature of being a PM. Every other PM I looked at had a similarly full schedule, I had signed up for this. Months went by without really being able to think about strategy and my stress levels were through the roof. It wasn’t sustainable, and looking back at it now I wasn’t actually doing a very good job.
The mistake that I made was that I was not deliberate with my time. I participated in everything that I felt like I should and I tried to do everything that I felt like I was supposed to. But all together it was too much. Instead of being deliberate with my time, I could only be reactive. I would spend time and energy on what seemed to be the current burning issue, and I’d give that my attention. This meant that at best I would scratch the surface on what is really important and not let anything drop. At worst, I would give no attention at all to the areas where we could have the most impact. Trying to do everything (which was too much) was causing me to be reactive and drop things. Trying to do all the different aspects of my job was ironically causing me to underperform.
But working at Spotify we are very fortunate to have some amazing coaches around, and I met with Thomas every few weeks for a coaching session. We’d discuss the different things I was focusing on, the challenges I had. He has the talent to help you to have some profound realisation by asking provoking questions. We covered a lot of things in these sessions, but the one that really sticks with me is the need for self-reflection and planning my time proactively.
I started reflecting weekly on how the week had gone and what I wanted to accomplish the following week. I also did something daily. The weekly reflection helped me ensure that I actually was setting myself up for success to do the head-down work that needed to happen between meetings, that would require some focus time. If I wasn’t, then either I would cancel some things to make time, or drop it and properly set expectations.
The daily reflection helped me stay on script, to ensure I was actually spending my time on the things which would lead to me accomplishing what I needed to. We called it the 3,2,1 plan. Each day I would decide 3 things that I wasn’t going to spend any time or mental energy on, 2 things that I would delegate, and 1 goal for the day. It sounds simple but the impact was profound.
Being busy and ‘getting everything done’ isn’t the job. Doing the right things really well, which means leading your team to have impact is the job. Make sure that you are personally spending time on the things that lead to impact. Be proactive with your time.
In our last podcast episode, Arvid and I reflect on our own experiences starting out, discuss tips that we have for a product manager in a new role different stages of the journey. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!
If you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post weekly. If you find them as valuable as we find writing them please share them with your friends and colleagues!