My last job title at Trade Me was ‘Head of Product’.
If you say you are a ‘Software Developer’ or even a ‘Development Manager’, then most people working in technology will know what that means.
But, I’m not sure I’ve ever heard a succinct definition of what makes a ‘Product Manager’. In fact, I’m not even sure I’ve heard a succinct definition of a product, in this context.
I thought it might be useful to try and describe, at least as I’ve experienced it, for those who might be interested in this sort of role.
Some long time readers (there are a few of you left, right?) and a handful of former Trade Me employees may recognise this old diagram:
I used this as part of the induction of new employees into the development team at Trade Me, to try and describe the broader product management process that we were part of.
There are six links in the infinite loop, so let’s go through them.
Actually it’s two somewhat separate loops: the smaller software development loop and the larger product development loop.
The work involved in the smaller loop is pretty well understood, I think, and widely documented elsewhere, so I won’t spend much time on that here.
Let’s pick it up at the point where you are ready to deploy a new feature out into the wild…
Release
The first important thing to realise about a release it that it’s not an end point. It’s just another link in an infinite loop.
This can be tough to understand for technical people who have predominantly worked in a project environment, for example as you would commonly experience in a consulting business. In that world projects have a defined beginning and end and then everybody moves on to the next project, and the software moves into “business-as-usual” mode.
In product management there is only business-as-usual. You are never “finished”.
This has a number of consequences, not the least being the importance of pacing yourself. Managing a product is a never ending marathon, not a sprint.
The second important thing to realise about the release cycle is how you win.
It’s tempting to think that you win by doing a good job and getting everything “right”. But, remember, I just said that you will never be finished. There is no such thing as “right”.
However, there is such a thing as late. The trade off between right and late is what makes product management more art than science. The best product managers typically have a bias to roll the dice and just try stuff - “If you’re not prepared to be wrong you’ll never come up with anything original”, “if you launch and you’re not a little embarrassed then you launched too late”, etc etc.
In other words, the challenge is not to necessarily navigate your way flawlessly once around this loop, but to navigate your way around this loop as many times as you can, getting a little bit better each time.
In order to achieve that you need to make sure that the release process is baked into your tools and process. You should be able to deploy and roll-back often and easily, ideally with one click.
I’m also a fan of a bit of release theatre, so that everybody is aware when changes are deployed and can celebrate the progress that represents.
Measure
As soon as changes are released, the next challenge is to create a feedback loop.
This is where you get to listen to what people do rather than what they say. If you can start to understand how people are really using your product then it helps you to cut through debate in the next two steps of the process with facts rather than feelings. It’s how you build confidence in your theory of what users will respond to (which doesn’t always mean what users will love, by the way – often it’s a product managers job to do what is best for the system as a whole, rather than for individual users).
I think it’s really important that everybody in the team understands how the business wins. It’s the product managers job to make sure that all of the developers and testers know what the key metrics are – for example, with a big screen on the wall showing these values and trends. But, more than that, they should be able to articulate how the features they are working on will positively impact on those numbers.
Prioritise
Broadly speaking the first job of a product manager is to keep lists.
You have to be able to take inputs from lots of different and often competing sources and constantly organise these so that the important stuff bubbles to the top, while at the same time not drowning in the long tail of less important stuff.
I recommend a “Now / Next / Later” approach.
Firstly, you need to be aware of all of the things that are underway, ideally with some idea for when they should be completed so you can keep a schedule in mind.
Secondly, and most importantly, you need to have a strong focus on what’s next. You should be able to list the next top three, four or five projects from memory, so you can stay focussed on those.
There will constantly be competing suggestions, of course. In that situation, provided you can list off the current priority projects, the question is simply: “which of these existing projects gets bumped by this new suggestion?” That usually puts new ideas in their place (on the later list).
It’s really powerful if you can have consensus from the whole team on what the next priority projects are. A useful technique for getting to that is to organise a prioritisation session where everybody is asked to bring their top two or three project to the table and advocate for them, then as a group rank them in terms of bang (i.e. expected impact on key metrics) vs buck (i.e. expected cost to implement), then pick the ideas which have the best ratio. Ideally nobody leaves until everybody has agreed what those are.
Finally, you need somewhere to dump everything else. It may be that you don’t even need to write these things down – if you’re prepared to assume that the good ideas will keep coming up. Or, maybe having a long shopping list is handy to have, so that you can fill any gaps that come up with something useful. Either way, the key is to ensure that these don’t become a constant distraction or an overwhelming background fear (remember you’ll never be finished, so getting to the end of the list isn’t the goal).
Once you have priorities agreed you also need to consider the order. There are two different approaches to scheduling projects that I’ve seen used effectively:
The Riverstone Model
Think of your schedule as a riverbed, and your job is to cover it in river stones. You’ll start by placing the big stones, picking the most important big projects to go first. Then you fill in the gaps between the big stones with some medium stones, again picking the highest priority medium projects first. Finally, in all of the little gaps between the medium stones you scatter some little pebbles – you probably don’t have to pay too much attention to which of these go first, it could be a simple as first in first out, or whatever else works. Or, you can live with the gaps and leave some slack in the system, which is often not a bad thing.
This model is recommended if you have more priority projects than development capacity.
The Train Carriage Model
Think of your schedule as a series of train carriages. On a regular timetable one will leave the station. Your job is to make sure that all of the seats on the carriage are filled. When a new project is agreed you also pick a carriage to target for release and reserve a seat in that carriage. Once a carriage is full you need to pick the next one available. And, if a carriage leaves the station with empty seats then that is a missed opportunity, so you always need to be thinking ahead to make sure that doesn’t happen – if there are no big projects ready to fill the space available then put some medium or smaller projects in there.
This model is recommended if you have more development capacity than prioritised projects.
Scope & Design
This is where a product manager will probably end up investing most of their time.
Everything should start with the user experience. I recommend having designers in the team, so you can be constantly working on this, starting with wireframes and high-level designs and later moving onto more detailed mocks which demonstrate the intent of the user interface.
There is always going to be a blurry line between design and development in any product team, and it’s important that there is a good working relationship between them. I’ve seen examples where this breaks down and developers treat the designs they have been given as a broad direction rather than a detailed specification. It’s better if the designers are responsible for the design, and developers are responsible for the code, but with a lot of communication in both directions – the developers need to loop back regularly with designers to make sure that what is implemented is as intended, and designers need to be constantly talking to developers so that specifications take into account development constraints.
I recommend putting together a project team at the very beginning of the scoping stage. This should include designers, developers and operations people as well as testers and/or support team members who bring an understanding of the current business rules and likely pot holes from dealing more directly with end users.
One of the important questions for this group to consider is: what change are we expecting, and how are we going to measure that? As we discussed above this creates a feedback loop after the feature is released, where you can confirm that the work you’ve done has had the intended impact, or not, and learn from that for future scoping and design work. If you can’t clearly articulate what the intended change or benefit is, then you probably need to go back and think about the feature some more before you start designing the user experience or cutting code.
As scope and design bleeds into development and testing the product manager will hand over to a development manager to make sure that the build runs smoothly, and will likely become a “customer” in that process. In a smaller team the product manager and development manager are often the same person, so it’s important for them to realise the two competing roles they fill in that situation.
Everything & Nothing
To do all of these things well demands a varied and interesting set of skills from a product manager, including a lot of soft skills that are not always easy to find in technical people – you need to be able to put yourself in the shoes of an end user and have empathy for who they are, how they think about your product and how they are likely to respond in different situations; you need to be able to think analytically – you’ll probably spend more time looking at spreadsheets than looking at code; but, on the other hand, you need an aesthetic judgement, a sense of style and an understanding of design trade-offs; you need to be able to write authentically and succinctly (writing is a muscle and one of the main reasons why I maintain this blog); you need to think like a marketer, because making things that people will love is hard; you need to be able to work with a variety of different people, both technical and non-technical; and, last but not least, you need to understand that you can achieve a lot in this sort of role provided you don’t need to take all of the credit for it.
In my experience the best product managers are heads-up developers who can code but don’t want to anymore.
If that sounds like you then think about how you can get involved in some of the areas that I’ve described above within your team, so you can build your skills and over time move from a software development role into taking responsibility for product management.
I’m interested in your thoughts, especially from those who have been a product manager or worked with one. What are the other jobs of a product manager that I’m missing?
Of course, the problem with an infinite loop like this is that there is no obvious beginning. This all assumes that there is an existing product that needs to be managed and developed. It doesn’t talk at all to where the idea for the product comes from in the first place, so maybe that’s where we’ll turn out attention next…