The last job title I had at Trade Me was “Head of Product”.
If you describe yourself as a “Software Developer”, most people will know what that means. But, I’m not sure I’ve ever heard a succinct definition of what makes a “Product Manager”.
This is my attempt to try and describe the job, at least as I’ve experienced it, for those who might be interested in this sort of role.
Back in the day, we used this is the diagram as part of introducing new employees to the development and product teams 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 let’s focus on the larger outer loop, and pick it up at the point where you are ready to deploy a new feature out into the wild…
The first and most important thing to realise about any 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 onto the next project, and the software moves into “business-as-usual” or maintenance 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 slow and steady run, not a sprint.
The second important thing to realise about the release cycle is how you win.
It’s tempting to think that you succeed 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 for rolling the dice - “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, your challenge is not to navigate flawlessly once around this loop, but to navigate your way around as many times as you can, getting a little bit better each time.
I’m also a fan of a bit of release theatre, so that everybody is aware when new features or even small fixes are deployed and can celebrate the progress that represents.
As soon as changes are released, the next challenge is to create a feedback loop.
This is where you get to see to what people do rather than listen to what they say they will do. 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 customers will respond to (which doesn’t always mean what customers will love, by the way - often it’s a product manager’s job to do what is best for the system as a whole, rather than for individual users).
It’s important that the whole team understands how the business wins, because this is how you ensure that you focus your efforts on the things that matter. As a product manager this means making sure that everybody knows what the key metrics are. You should try to highlight both the current values and the trends - e.g. on a visible big screen on the wall, or widely shared dashboard. And, more importantly, always ensure that your team can articulate how the particular features they are currently working on will positively impact on those numbers.
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 clear focus on what’s next. You should be able to list the next top three, four or five projects in the queue from memory, so you can keep everybody focused on those.
There will constantly be competing suggestions, of course. In that situation, provided you can list off the current priority projects, the question simply becomes: “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, if that’s possible. A useful technique for getting to that is to organise a prioritisation session where everybody is asked to bring their own top two or three projects to the table and advocate for them. Then, as a group, rank them all in terms of bang (i.e. expected impact on key metrics) vs buck (i.e. expected cost to implement). Finally, pick the ideas which have the best ratio. Ideally nobody leaves until everybody has agreed what those are.
Last but not least, you need somewhere to dump everything else. And for any non-trivial product everything else can be a lot! 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 quickly fill any gaps that appear 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 is not the goal.
Once you have priorities agreed, you then need to consider the order. There are two different approaches to scheduling projects that I’ve seen used effectively:
This model is recommended if you have more priority projects than development capacity.
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 development capacity than prioritised projects.
Think of your release schedule as a series of train carriages. On a self-imposed regular timetable one will leave the station, and your job as product manager 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 in a scheduled release then put some medium or smaller projects in there.
This is where a product manager will probably end up investing most of their time.
Everything should focus on the user experience, starting with high-level designs and prototypes 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. The designers need to be responsible for the design, and developers need to be 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.
It’s useful to put 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 potholes from dealing more directly with end users.
One of the important questions for this group to consider is: what change are we expecting, once this feature is released, and how are we going to measure that? This creates a feedback loop, 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.
To do all of these things well demands a varied and interesting set of skills from a product manager, including a lot of heads-up 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 clearly so you can communicate well with others involved in the product, both internally and externally; 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.
Product managers need to be a bridge between all of the different parts of the product team and the customer. If you come from a technical background then to be a successful product manager you need to build your skills in these other areas (in my experience, some of the best product managers have been heads-up developers who can code but don’t want to anymore). And, vice versa, if you don’t come from a technical background then getting to grips with how the product is built is important, so that you can communicate effectively with those who are more heads-down.
Whatever direction you approach it from, 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 into taking responsibility for product management.
So, while it can be difficult to describe the exact role that a product manager will have, and rare to find somebody who is good at all of the different aspects, it’s worth the effort because a good product manager makes all the difference, helps technical teams create products that customers love to use, and ensures all of the work that takes is aligned within the business.