13 things I learnt moving from Agile Coaching into Product Management
Switching careers is nothing new and at companies like Spotify it is actively encouraged. Unsurprisingly, the key is finding a new role in which you already have at least some of the skills required, then quickly learning those ones you don’t.
Last year I did exactly that: moving from Agile Coaching (AC) into Product Management (PM) and I thought I would share a few learnings from my experience so far.
I’ve talked plenty about the intersection of the two roles in previous blogs, so will do my best to avoid going over old ground and to focus on the things I discovered moving into the PM role.
1) You are accountable for everything
I like teams where everyone holds themselves collectively responsible for building great products, but at some point as the PM you will be asked: “Who in your team is responsible for the delivery of <insert thing being built here>?” and you will need to respond.
If like me you want to say: “we all are”, you’re going to get an annoyed look and likely a follow up question along the lines of: “but who exactly?”. At this point the best response I have found is this: “I am ultimately accountable for reporting on the progress of everything being worked on in my team and we are all responsible for getting it done”.
If you don’t shield your team from these kind of questions, you might have problems down the line when members of your team are contacts directly by stakeholders.
For more on this, I suggest reading this excellent piece on accountability vs responsibility.
2) Alignment (and coffee) is everything
Product Managers are often asked to work “ahead of the team.” While this concept made sense to me before taking the job, it really struck home once in it. My week now needs to contain multiple quick syncs with other people across the company (mostly PMs). If I don’t make time for these “coffees,” there is a good chance my team will build something that will be irrelevant before we even ship it.
3) Big teams create more work for the PM
This seems so obvious as I write it now, but it took me by surprise when I first took on the PM role. As an AC I was a big fan of larger teams (≈12) as they are able to own their own destiny by having all the skills needed to get things done. I didn’t realize, however, the impact this had on the PM and their time, or lack thereof. The size of your team is directly proportional to the number of hours you will need to work each day as a PM; even if you work “smarter not harder” or “[insert other generic phrase that people say which doesn’t help]”.
This doesn’t necessarily change my opinion on the best team size and I believe with delegation you can lessen this impact. But it does allow me to be a lot more sympathetic to those PMs who are running multiple workstreams within their larger teams.
4) Know what you’re being measured on
I am being measured on two things: team health and shipping products that move metrics. Team health came naturally to be through my time in Agile Coaching. Moving metrics, however, was completely new.
First things first: make sure your metrics are correct, as there is a good chance they are not. Secondly, make sure everyone in your team is in agreement on what metric the thing you’re building is trying to move before you start building it.
5) Publicly credit the team at every opportunity
Giving credit to those you work with is something all leaders should do. It builds trust and empowers the team. PMs are often the public face of the team, so when you’re asked to speak about the work of your team: whether it be on a stage, in a presentation or externally; make sure to give credit to those who actually did the work. Being a PM puts you in the spotlight and that power can go to your head, but you shouldn’t delude yourself about who is doing the hard work!
Even better than giving credit to your team is persuading them to present the work themselves!
6) Books might not be the answer
One of the first things I did when switching roles was ask other PMs what books I should read. This had been an invaluable source of learning when I took up Agile Coaching and I was hoping for a similar boost. However it turned out the tools and techniques advised in these books were exactly the same ones I had learnt before; albeit with a slightly poorer understanding of what Agile actually is.
Although this was a relief, as it meant modern PMs understand the skills required to build great teams and run effective workshops, it didn’t help me with the parts of being a PM that were new to me: building and selling a vision. Having failed to find inspiration from books (apart maybe from “Badass” by Kathy Sierra), I instead searched internally for great vision decks, where the team had actually on gone on to build to product. Much like the ShuHaRi method of learning a new skill, I would first have to copy others in this new art form.
7) Act on your ideas as fast as possible
No one owns an idea. Fact. If you have a good idea, talk about it and don’t act on it, someone else will. You might create a deck, conduct some user research or simply post on slack; either way once it’s out in the open it’s fair game.
You will need to persuade embeds to join, increase your headcount or make do with what you have by limiting your work in progress. Either way, other teams won’t wait for you to build the idea you have.
8) Overcommuncation is key
The hardest part of moving roles was getting used to oversharing everything all of the time. Sometimes people assume if they haven’t heard from your team for a while, then you aren’t doing the right things (or even anything at all). So as a PM you need to be constantly letting the world know about your progress and accomplishments. I’ve had to learn to build “sharing” decks, which although not my strong suit, have allowed me to spread ideas across companies without a thousand coffees.
9) Learn to be defensive about your calendar
This was a tough lesson to learn, as it meant sometimes telling people you didn’t have time to help them; something an AC finds very difficult. However as a PM you will have too.
Be a good colleague to the wider company and help everyone out that you can, But don’t let your team suffer because you’ve spent all week listening to other people’s ideas and problems. The team always comes first.
10) Sometimes you decide
One of the hardest things moving from AC to PM was not always being the facilitator. I will always try and let the team work it out, but sometimes you need to be the deciding vote (or at least the one who decides the mechanism for voting). Finding the right balance between decision maker and facilitator is a never ending struggle, but just know that sometimes it will be on you. Get comfortable with that.
Know what decisions are important and need debate, from those that will likely have very little impact and just need to be made quickly.
11) Vision is hard
It took me 9 months to have my lightbulb moment with what “vision” is. Although I understood that vision was the why and strategy the how, articulating an inspiring future is not easy. In the end, a lucky interaction with my product director changed me. Having been presented with my proposed vision, he basically said: “who cares?” It wasn’t meant in a mean way, more it nudged me to make a bigger leap and expand my view of what was possible beyond just keeping the wheels moving. I came back to the team with a grander, more exciting plan and the reception was completely different.
My second lesson was that it takes a long time to seed this vision across an organisation, you need to repeat your message, take feedback and constantly explain the why. Just when you think nobody listened, you hear someone explain the vision you painted back to you. That’s when you know it’s on :)
12) Learn SQL (or whatever else you need too)
Sometimes you won’t have a data scientist in your team, or you simply don’t want to interrupt an engineer’s flow every time you need a specific data set. So learn the skills you need to take the load off them. Early on this will be tough. It’s awkward to ask someone to explain something, especially something they find so easy.but you’ll usually find them more open to teaching than you might think.
13) Don’t forget your old role
Whether it be WIP limits, individual coaching or running a story mapping workshop, don’t forget the role you used to do (and likely were really good at).
This came to light for me when someone in my team said: “Wish we could have a workshop on this, you used to be really good at those when you were an Agile Coach”. It was both helpful feedback and a little gut wrenching, I’d completely forgot the basics of what I had done so well before. Celebrate these moments the best you can and encourage your team to call you out when you (temporarily) lose an important piece of yourself.
What do you think?
Of course there are loads more things to learn and loads more that I’ve forgotten I learnt. Let me know your biggest lessons on switching roles @BenjiPortwin
