Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles How to Run Your Product Department Like a Coach

How to Run Your Product Department Like a Coach

Key Takeaways

  • When building a product department at a new organisation, first of all don’t break anything, then ask people what’s not working – this will allow you to focus on getting those things to 7/10, before you try and make anything 10/10.
  • Your product people community will determine if you succeed (or not)  and can plug a lot of process gaps – put time and effort into getting to know everyone within it, then make it part of everyone’s role to make it great. 
  • Keep teams together and give them time “to be teams”, focusing on just one product at a time - the high-performing teams you’ll build will deliver more and be able to quickly switch focus if needed. 
  • Great product leaders are comfortable with not knowing how to do something - stay calm, ask for help and just like when you were a PM, trust your brain to work it out.
  • When moving from Product Management into Product Leadership, pick your next organisation carefully – make sure you have the autonomy and power you need to influence how things are done.

Having found what I thought was my calling as an agile coach, I took the tough decision to move sideways into Product Management in the hope of using what I’d learned to one day run my own department. I believed that coming from coaching would allow me to see things others could not and create something special. Although only time will tell if I have succeeded, this is the story of where I am up to so far.  

From Agile Coach to Product Manager

I moved roles due to a mix of luck and needing a change of scene. I’d been a successful Agile Coach at Spotify for over a year, but my manager, who was also the general manager of my business unit (aka the “tribe lead''), had recently moved to Instagram after a cascade of unfortunate events starting with the CTO of Spotify being demoted. My new boss was sadly not the best and didn’t understand what agile coaches did – this led to me feeling demotivated and in need of a change. 

At the same time, by chance, a new product manager (PM) failed to build trust with the two senior technical leads of their assigned team and had an “organ rejection” situation. This led to them exiting the company at short notice and putting one of our most high-profile products (Discover Weekly) without a PM and in jeopardy. Not for the first time, I was asked to coach an engineer to hold the fort as an interim PM, but knowing how much energy this would take and given how I was feeling at that time, I decided instead to take it on myself. As I wasn’t sure if I would like it (or would be any good at it), we set a three-month trial period and I got to work. 

Three months came and went –  I brought a different style to PMing than they were used to, a more “people-first” Product Management mantra and the team bought in, inviting me to stay on permanently. Unlike previous PMs, I had pushed back on the need to build new features and listened to the team. In fact, we spent most of those three months simply addressing technical debt that would stop them getting beeped at 3am every week because a data pipeline had broken. Although my style changed as I spent more time working in Product Management, I never forgot the people skills I learned as an agile coach and they would stand me in good stead when I would eventually become VP of product years later.

Building the Product Department at accuRx, a Hyper-Growth Healthtech Scale-Up

I knew I was stepping up coming into accuRx – I felt confident I was ready to build and lead a product department, but I hadn’t done it before and knew they were taking a chance on me. I’d built up a “what good looks like” playbook from my time at organisations like Spotify and Monzo, but crucially I also had a long list of things I’d seen fail repeatedly in various environments (eg. gantt charts). I’d earned my shot at showing I knew how to build and run a department, but knew I would need to hit the ground running if I was going to be given the power needed to do it my way. As a coach, the first rule of joining a new organisation is “don’t break anything” and although I would of course spend the majority of my first fortnight doing just that, I also knew I needed to make an impact quickly.

My top priority was ensuring that I had a great product team to work with. If you’ve got great people, then you can get away with minimal process and so I needed to assess who I’d inherited and then create a scalable plan to grow the team at pace (we had just had a cash injection that would allow us to double in size over the next ≈9 months). However, like many early-stage startups, there was a lack of process around hiring PMs and no formal progression framework to reference. This meant there was no consistency in how we were hiring and assessing PMs.

I’d been extensively involved in hiring agile coaches at Spotify and helped design parts of the Monzo PM interview process, which allowed me to build what I thought was a simple process that actually tested what’s important for being a PM in my department. Our bar was simple, we needed to feel confident that they could take on a team on day one if needed. Although not the ideal onboarding experience for any PM, in startup life it happens more often than it should, and although we would be around to help, we couldn’t hold their hand. However, as experienced PMs are notoriously hard to find (and quite expensive), we agreed we were prepared to take on people without much formal experience and train them up – this is how we would scale at pace, get PMs working our way and stay within budget. 

We have a mantra in Product at accuRx of “throwing responsibility at people until they drown, but then being there to catch them when they do” – so this is what we looked for in our interview process. We wanted to understand how you dealt with stressful situations (did you ask for help?) and how coachable you might be (do you know you’re on a journey?). My first PM hire ended up being someone who applied for a data scientist role and our success in helping them become an amazing PM, led us to build a formal six-month fast-track Associate Product Manager (APM) program down the line. 

We got our hiring process to 7/10 (my “good enough” standard) and then moved on. If you’re coming into a new situation like I was, then although it feels counter intuitive to not keep going and make it 10/10, the time spent doing so will not pay you back as much as moving onto the next thing that needs fixing – for us, this was building the V1 of our progression framework. We wanted PMs to focus on three things: building healthy effective teams, delivering at pace, and building the right things needed to move product metrics. Building out the progression framework with the current team allowed it to bed in quickly and was also a great way to understand each of their backgrounds and motivations going forward. I spent quite a bit of time with each of them asking them standardised coaching questions (eg. from the coaching habit book) about what they thought was going well and what we should change. Quickly a narrative emerged that allowed me to build the right framework, assess their individual skills, and also know what the organisation was struggling with as a whole, tl;dr – autonomy and accountability. 

I found that I had some people who were likely “rocket ships”, who I just needed to point in the right direction and coach; and that I had some who were struggling to keep up (and might need to find another home). This is always a really tough but necessary part of joining any organisation and we sadly had to let one person go as a result of those conversations. I also had to reformat the reporting lines to a simpler structure – both of these were tricky conversations to have, but I knew it was important for me to be the one to have them, as it showed I was ready to lead.

The other place I put the effort early on, was into the culture of the product team – I’d help build so many teams as an agile coach, that luckily this comes second nature to me by now. A colleague of mine had already done a terrific job of getting this going, so it was more a case of injecting some more energy into the situation. I knew from my previous experience as a coach that a strong community can plug a lot of process gaps, as it creates a culture where people avoid saying “that’s not my job”. I did some simple things like personal mapping together as a group and took the time to get to know people on long walks along the London canals. 

Once we had hiring going and had aligned PMs on expectations for the role, I needed to introduce a simple framework for product at accuRx. When I arrived, we were project-based, with each team being told to build a solution; this needed to change for us to be successful and scale. I settled on a simple Vision > OKRs > Roadmap framework (see below), which my head of design helped me to visualise and get on the walls for reference. Most of the team had no expertise in writing visions or facilitating the creation of OKRs, so it took some explaining – both the how and the why (they were needed). At the same time, I also needed to manage upwards, educating from first principles why this system would work better than short term Gantt charts focused around weekly deliverables. Taking over any department at a start-up you’re going to need your founders to place some faith in you and I was lucky that I had this backing to make significant changes to our way of working.

A key part of this new way of working was something that was drilled into me as an agile coach – keep teams together and give them time “to be teams”. Until this point, teams had formed and disbanded for each project, however, I knew that for us to move faster, the key would be high-performing teams and that takes time. Instead, we would try to keep people together and if needed, change their focus rather than disband them. This has easily been one of the most successful parts of a new way of working I brought to accuRx. As part of this focus, I worked closely with the CTO to establish clear leadership and accountability within each team. We agreed that every team would have a PM/TL (technical lead) pair, with both being held jointly accountable for the team being healthy and effective at delivering at pace. This “leadership in pairs” system has been crucial in allowing us to scale quickly whilst holding ourselves to account. 

The final piece of the jigsaw was ensuring that I was able to influence (or own) what our organisational structure would look like for Product (and Engineering). I’d spent so much time becoming an expert in organisational design at Spotify, that it killed me to see Monzo get it wrong repeatedly. I knew that for me to be truly successful at accuRx I would need to be able to have things set up the way I knew worked. Luckily most people didn’t have a lot of experience scaling and so they were happy for the input, another advantage of moving to a smaller organisation in a more senior position.

Moving from Product Manager to Product Leader 

I don't think there is a magic formula for making the transition from PM to product leader and I doubt any two journeys are the same. For me, it was a calculated approach to move to smaller organisations in the hope of getting the chance to run my own department, as I knew it was possible if I had stayed at Spotify, but it might have taken many many years.

In order to make such a transition, firstly I think you need to have worked in different roles in multiple organisations with a good product culture. As an agile coach, I’d help design how to get multiple product teams to work together, I’d debated autonomy vs alignment till the cows come home and I certainly knew the issues of accountability gaps at scale. I always had a hunch that being VP of product was more like being an agile coach than a PM and, for me at least, it turned out to be true.

Secondly, you’re going to need to have worked out what kind of leader you want to be. My leadership style (and Myers Briggs classification) changed dramatically when I moved into coaching. I learned to lead “from the back of the room” and was never going back, but I also needed to be confident I could handle the power appropriately – this is one of the biggest traps for many people taking over a department for the first time. You need to be really comfortable in your own skin and really confident that you can do the role you want. 

Thirdly, and this one is much more random, I think you’re going to need to have some “big names” on your CV. I hate this, as I don’t want to believe it, but whatever anyone says, people believe that if you’ve been to places that got big then you’re probably more capable. Moving from running multiple teams in big organisations to departments in start-ups is a well-trodden path. Start-ups are dying to hire people “who have been there, done that”, as often most people in the building are doing everything for the first time.

Then it was about finding the right place. I thought it might be Monzo, but it turned out to be accuRx. I was employee number 30 and they had a really clear problem that needed solving: they had moved from one product team to four and didn’t have a good system yet for how to work at that scale. I was able to help solve that and then grow my influence from there. At the end of the day, someone is going to need to take a chance on you and then you’re going to need to “fake it till you make it (or don’t)”. Luckily as an agile coach, that’s pretty much all you do. Everyday someone asks you to facilitate a workshop on a topic you have no idea about and you need to make it work. You learn to live in the ambiguous and after a while, you get comfortable with not knowing how to do something – just stay calm and trust your brain to work it out. Of course, that also means being really comfortable saying you don’t know and asking for help from those around you (another key tenant of great leadership)!

Teams Need to Work on Only One Product

The biggest problem I’ve observed in every company I’ve worked in is the inability to limit Work In Progress (WIP). There are of course many techniques for limiting work in progress at all levels (org, unit, team, individual etc..), but for the role I now hold, the simplest and most important is not asking teams to conquer multiple hills at once (“one thing per team”). 

Despite my best efforts, it’s something I saw the opposite happen at Monzo to disastrous effect, where teams were trying to build 3 or 4 products at once and ended up building nothing. The issue in this example was that I was going against the DNA of the company, I was going against what they believed had made them successful up till now.

One of the advantages of holding the position of power I now do at accuRx, is that’s something I’ve been able to enact early on and build into the accuRx product culture. The “rubber hit the road” with this mantra early on, when in December 2020, for obvious reasons, we needed to start work at short notice on a product that would transform vaccine booking across the UK. Luckily that was just enough time (≈ six months) to have built at least one high performing team that we could ask to halt work at short notice and switch to this new problem. A combination of the policies around teams and only working on one thing at a time, allowed us to ship an MVP of the vaccine product in less than two weeks. It’s always painful stopping something important, but it’s what you need to do in order to be successful.

Interestingly, our failure case around WIP is slightly different – instead of asking teams to do multiple things (due to the policy described), the behaviour I have to keep a close eye on is making sure we don’t do “ghost work”. This is where the founders see a user problem and then build a “quick win” solution over the weekend, often releasing it into the wild for a small subset of users. This requires careful management, as it’s easy to show the value of these releases with positive user feedback, but it’s much harder to show how much they slow down the development of other products and add to our collective “existential WIP”. 

Being Successful as a Product Leader 

Although I’ve loved it, it has not been easy moving into Product Leadership. Taking on a new role with added responsibility, whilst at the same time learning a new industry in healthcare and hyperscaling my team (and the organisation), has been a lot. I could write a very long list focused on what I’ve learnt so far I’ve needed in order to be successful, but will try and pick just a few of the things I did consciously or otherwise:

  1. Make sure you have a seat at the top table. If you believe you know what you’re talking about and want to implement new ways of working, then you need to be “in the room” where the decisions get made. I wasn’t when I started at accuRx; they didn’t believe they needed a head of product – I had to show I knew what I was talking about and then put a plan in place to take on the role after a few weeks.
  2. Don’t die on too many hills. I joke about this a lot, but it was something I learnt the hard way at Spotify when I got the reputation for being someone who cared about too many small things. At Monzo I started to transform into being someone who “didn’t care about many things, but cared a lot about them when I do” and I’ve carried this on at accuRx. We have a very collaborative culture and so I need to “disagree and commit” a lot to help keep things moving. At the top level, you need to make decisions as a leadership team quickly, because otherwise they quickly build up. Become known as the person who helps those decisions get made.  
  3. Decide on what your product framework is. Pick a few key principles for how you’re going to run your function and stick to them. Other than the Vision > OKR > Roadmap system I mentioned earlier, it’s about picking a few key things that teams must do. For example, you’ll hear me say “all work must go on the board”, “retros must have actions” and “people are only in one team at a time”. But I stay out of whether teams want to run Scrum, how they “show & tell” (as long as they share context) and mostly what they call themselves. Leaving space for people to work out how they work together is a key leadership trait.
  4. Be cautious about what you agree to take on. This is true with any role, but never before have I had such a constant backlog of work. Gone are the days when I go home on a Friday at inbox zero; sadly, I must be content that I have prioritised the most important things and avoid taking anything on that might be blocking others. At the VP level, you must be an expert delegator. 
  5. Don’t get sucked into the trap of estimates. The pressure to do this at any level in product is horrible, but it matters even more when you’re leading the line – if you cave you throw your whole department under the bus. Giving delivery timelines and a Gantt chart won’t work and just kicks the can down the road. People and teams don’t know how long it will take to build something, so be honest with everyone else and have their backs. Know the difference between complicated and complex types of work (Cynefin style) and explain it to whoever needs education. 
  6. Get on well with each of your peers. It was pointed out early on to me that everyone in the leadership team needs to have a great 1:1 relationship with everyone else in the team and it really took me a while to get this. If you don’t, then both departments will suffer at all levels. It took me 6+ months to build a great relationship with the VP of engineering, and it's been transformative ever since.
  7. Constantly assess if you’re doing the job the organisation needs of you right now. If you don’t you’ll do the wrong one and they may hire in above you and for me, that’s a deal-breaker. When our VP of commercial left, I took on a lot of that work, from direct negotiations with suppliers, to hiring in people to that department. When we didn’t have a VP of people, I helped lead the performance review process. I was the first to recognize I needed product directors and hired them in. Leadership is doing what the organisation needs, and showcasing yours regularly should be what keeps you in the room. 
  8. Do it “Your” Way

If you’re making the move into product leadership, you should read all you can, speak to everyone you can and quickly form your own style. This should change over time, but the key to leadership is consistency and you can only lead the way you know how, so as Frank Sinatra famously sung: 

I planned each charted course
Each careful step along the byway
And more, much, much more
I did it, I did it my way

About the Author

Rate this Article