Product Management: Six months in
What two new Product Managers have learnt on the job in their first half-year.
Bonny and I have both taken on the role of Product Manager at UK publisher Immediate Media in the past six months, working within the wider team to deliver products and services for our editorial brands. During the rollercoaster ride of these first few months we’ve both learned a hell of a lot. The reality of doing the job is very different to the mystique that surrounds it. It’s much less of a science and more of an art.
As we’ve got to know each other, we’ve found it really helpful to share our experiences and learn from each other. We’ve had highs and lows, and plenty of face-palm moments! We’d like to share a few of the things we have learnt together, to help anyone else starting their product management career.
About us:
Linzi: Before Immediate, where I am currently a Junior Product Manager, I was in an Editorial Associate role, providing online editorial support to editors and coordinating with their publishing systems.
Bonny: I’d been a UX Architect for about ten years before I moved into the Sports & Specialist Product Manager role at Immediate.
Tips from the front line of product management
Make structured lists
It’s easy to forget details when there are lots of things going on. By making a prioritised list at the start of the day, and rolling yesterday’s incomplete tasks onto it, you can keep track of what needs to be done. There are always too many things to do in a day, but this approach ensures you focus on priority items and make sure those are completed first.
Prioritise by data, not decibels
It’s important to work out which requirements are truly the most important, not just who is noisiest asking for them. Find evidence (or request it) for requirements before believing they are real. People can be really convincing (and persistent) asking for things but it doesn’t mean they are important to the goal you are pursuing. Noise can be really distracting so it’s important to see it for what it is and not get sucked into chasing features that are not necessary.
Love the data
Rather than basing requirements on assumptions, like “this seems like a sensible idea”, use data to inform your decisions. (Basically, make dashboards in Google Analytics and other services until your heart’s content).
Compare data from different sources to ensure the meaning you’re taking from it is consistent and not skewed by something unknown to you. And remember, the plural of anecdote is not data.
Learn to say ‘no’
It’s crucial to maintain focus on your priorities, and not jump in on something non-critical straight away which could disrupt the scrum/development process. Part of the role is to keep distractions and chaos away from the development team so they can get on with delivering the agreed sprint outcome. Constantly saying yes is very disruptive. You have to say no, or not right now, to most things to be able to deliver something. To paraphrase Stephen Covey, it’s easier to say no when there’s a bigger yes inside.
Accept that you can’t satisfy everyone
A lot of decisions will be made, some of them will be popular with stakeholders and others not so much. Sometimes your decisions will make you unpopular with some groups, and that is OK. Your job isn’t to please everyone at once, it’s to deliver a product which delights the users. Having good working relationships is very important, and communicating decisions and priorities well will help to maintain them.
Confirm the requirement is possible before saying ‘yes’
When you first start a new role you are conscious of making an impression: the right one, of course. It’s very tempting to want to please people by agreeing with them. Jumping in too soon and saying yes to a stakeholder requirement before checking in with your development team is not a great idea, especially when they turn around and say the required change will take five sprints!
People don’t ask for what they want
Double and triple check what stakeholders are asking for, because they don’t always mean what they say. For instance, we’ve delivered requests exactly to the requirements we’ve got, only to find out it’s WRONG ~sad trombone~. Likewise, make sure you work through the user journeys related to your own ideas, to ensure the logic is consistent.
Always check things mean what you think they mean (or people don’t do what you ask)
There is a lot of room for confusion when it comes to communicating with developers. For example, we found out ‘ALL’ doesn’t mean ALL to our development teams, it means ‘SOME’. It’s taught me not to be complacent about what different meanings things can have in different contexts. Making sure the acceptance criteria are super-clear can really help.
Overcommunicate
Never assume everyone is on the same page, because the chances are, they’re not. Communicating what we’re working on, why we’re doing it (and even who we are sometimes) is an ongoing requirement and it doesn’t go away. The more you communicate across teams, and the wider business, the more things you realise you need to communicate.
Apologise without guilt
Even when it’s not your fault. Taking ownership of failures is an important part of the product role. Things go wrong, or don’t work as planned. That’s one of the ways we learn.
Accept failure
Even when it seems like it’s all the time. There are moments when it feels like the failure is constant and unrelenting, and then it’s not, and it’s OK. Our product management positions both require a fair amount of context switching, from dealing with lots of legacy issues, through to developing new features as part of a company-wide project — which gives plenty of opportunity for mistakes, errors and misjudgements. It’s all learning though, and we are much less precious today about failing than we were six months ago. Each time something goes awry we learn something we won’t repeat!
It’s not personal
The direction of the business can change, and so plans have to change — don’t be precious about it. Being flexible and collaborative is more productive and enjoyable than being fixed and closed off to ideas.
Develop a network of peers
Having other people that understand the role is really important and helps a lot — especially when things become challenging. Having a sounding board to ask things like “is this normal?” and “what options should I consider?” gives real peace of mind and helps maintain perspective.
Documentation is really important
Document everything. Literally everything. Having almost no documentation explaining how products work becomes challenging, especially when it seems that it’s only functionality without any documentation that breaks and makes troubleshooting harder than it needs to be!
No one really understands what you do
(Including friends and family), and it’s hard to describe what you do. And then you start questioning what you actually do. But it is OK because everyone is learning how to do what they do all the time.
Love learning
The product management role has stretched us more than we thought it would do, and the process of learning how to work with ‘stretch’ goals has been an important personal development challenge. Although we had challenges in previous roles, we have never had to take on so many things in such a variety of flavours. It’s similar to a roller coaster: you either hate the ups and downs and get off, or you stay on for more rides and learn to enjoy the speed. We are screaming less, so must be getting a taste for the job!
In all seriousness, the challenges of the role are satisfying and become addictive —We want to see things through and watch the changes. There isn’t a chance to be bored, and there are so many opportunities to both develop interesting ideas and develop personal skills; we feel very lucky to work in this position.
