Some Observations from my First Year in Product

This one is for the newbies.

Breaking into a career in product can feel daunting. This is often because product roles are one of the biggest culprits of the employment catch-22: almost every position requires hands-on experience, yet there are no entry level roles to break in. 

Becoming a product manager was a goal of mine for years before managing to make the jump, and I got lucky in that an associate position opened up where I could learn as I went along. For those that might be in a similar position that I was, I wanted to give some insights that I have gained in my first year that you won’t necessarily find in the books. 

If you’re new to product, looking to make the jump or just want a trip down memory lane to when you first started in the field, this one’s for you. 

Get used to hearing ‘It Depends’

The variety of the product manager role is a huge draw, but can be a nightmare when it comes to looking for a straight answer. The best advice I can give is to assume every answer will begin with ‘it depends’. This phenomenon has also been highlighted in a previous Product Breaks post. 

Coming into a product role with no experience means you likely have a lot of very specific questions, and this so this response can be a challenge if you’re used to jobs that have clear set answers (like I did). 

The second best piece of advice I can give is to ask the same question to multiple people. ‘It depends’ will often be followed with sage advice from hands-on experience, so having a range of insights will help give a broader understanding. 

Having multiple perspectives might not help you to answer your question outright; however, you can start to piece together bits from each that will set you on the right track. Then, once you’ve solved your problem and someone else in the team asks for some guidance, you’ll be ready to say ‘it depends’. 

Best believe there’s a difference between an ‘Owner’ and a ‘Manager’

The role I initially applied for was that of a product owner; however, by the time I started, this had changed to a product manager. With job titles being subject to change across each industry and business, it may seem like an arbitrary difference. With the job title change, however, came an opportunity for me to learn some of the key differences (this article from ProductPlan was a helping hand). 

The reason for our title change came down to influence on projects: we found ourselves more aligned with a traditional product manager as we were finding ourselves involved with strategy and product vision, as well as the typical product ownership.

If you’re thinking of a career in product, I’d recommend exploring what each role entails and understand where you’d like to sit. While many people will experience both in their careers, it doesn’t hurt to know your owners from your managers before taking the plunge. 

Acronyms, acronyms, acronyms 

Get ready to learn some acronyms. Did you think RICE was just an accompaniment to a meal? Did you think MoSCoW was just a city in Russia? Think again! 

It can be challenging to wrap your head around so many different acronyms and their meanings (and to be honest, I’ll still struggle with some that come up in conversation). The best thing to do is try not to be overwhelmed. 

You’ll soon learn that some appear in your daily vocabulary and are super useful, while others are best reserved for a rainy day. Make sure to focus on learning and retaining what’s important to your specific role, and give yourself the time for a quick refresher on some of the lesser used ones when needed.  

Teamwork makes the dream work

Due to the ‘it depends’ nature of product management, the role will vary project to project. You might also find yourself working alongside a delivery manager (or ADL, Agile Delivery Lead etc.). The roles and responsibilities may seem clear and carved out on paper; however, you may soon find that you’re working very closely alongside them. 

Use this to your advantage: bounce off the team around you, lean on them and allow yourself to be leaned on when things are challenging. No good product manager will religiously stick to their job description and not offer support elsewhere.

Working alongside someone in such close quarters is not something we’re all used to, but it can be extremely rewarding. It allows for opportunities to share responsibilities, meaning you can build on additional skills outside the traditional product realm. 

Theory vs Practice

Coming into a product role without any experience meant that the first thing to do was to learn the theory. Learning why we do it, before how. This was crucial for me and it set me on the right path; however, it’s actually doing the role that has been the biggest reward. 

Books and articles are great, but they are no match for rolling up your sleeves and getting stuck in. The questions I was asking and concerns I had were completely different in the ‘reading’ phase compared with once I had started on a project. 

It also quickly becomes apparent that a lot of the theory is not set up for the project you’re on (see the Product Breaks manifesto). Many articles will focus on specific scenarios, or assume that the landscape of the business is perfectly Agile and receptive to high theory. Sometimes just working through it can be more impactful than theoretical scenarios. 

Work in your environment, not someone else’s

When I was first starting, I thought I would be using many of the product elements I was reading about on a daily basis, when in fact they are more just tools for a rainy day. I was expecting a daily basis consisting of complicated charts and diagrams on Miro boards, but this has not been the case - and that is not a bad thing. 

Working alongside your team to get the best out of your environment is crucial. Some project environments are not receptive to high-concept ideas, but that doesn’t mean you are failing as a product leader. 

It’s getting the basics right that will drive the team and the project forward the most. 

Learn what your role requires 

The mindset of product people can often drive them to want to get involved in everything. They’re the ‘jack of all trades’ in the team. Learning when to put a stop to this and control these impulses is a skill I’d recommend getting familiar with. 

Trusting your team and encouraging them to take ownership and responsibility of their own workload will not only help you, but it will help the product as a whole. Learn when to step back and it will benefit everyone. 

People skills are crucial

Before starting in Product I would often hear the following description: ‘product owners sit between business and tech’. While this is true overall, the reality is the role sits between ‘people’ and ‘more people’. 

While your role might not involve traditional line management, stakeholder management is at the crux of the role. Without embracing it, you will struggle. It’s less about learning the technical and business jargon; rather, learning to empathise and manage conflicting stakeholder demands in a professional and effective manner. 

In addition, having the capacity to do this in a remote working environment is another huge bonus. 

There’s no such thing as a stupid question

We all worry about looking foolish by asking the wrong question. I find it funny how quick I often am to preface any question with the phrase, ‘sorry if this is a stupid question’ - as if people might turn round and laugh at me for asking. 

There really is no such thing. Asking questions will help you to understand, and when you’re working in a new environment and want to build domain knowledge, there isn’t a much better approach. Be curious and you will learn more, while also showing initiative. 

The number of times that by asking a seemingly basic question it has caused people to reflect or view a problem differently is huge. Sometimes taking it back to basics is a great refresher. 

Utilise the quiet moments 

When it’s busy, you’ll find yourself back-to-back. Whether you’re knee deep in tickets, endless meetings or other time-consuming tasks, you won’t have much to spare. So when it’s quiet, ensure you make the most of it. 

The nature of product management means that some days and weeks are busier than others. There are natural peaks and troughs in any project. Learning how to effectively manage your downtime is a good skill to have: whether that’s picking up a book and expanding your product knowledge, checking in on team health or getting around to some of the non-priority tasks you parked during the busy period. 

Appreciating and benefiting from the quiet moments will not only help to avoid burnout, but also ensures you avoid decision overload and will help you to be at 100% when the busier periods come back around. 

–

Any advice you feel is missing from the list? Do you majorly agree or disagree with any of these? Did your first product role differ majorly? Let us know in the comments!