Product Management

It’s been said that a successful product team needs three key people: ¹

1. A developer
2. A designer
3. A dictator

I have a Computer Science degree, so I can code. And I’ve been fortunate in my career to work with some really great designers who have taught me many of their tricks, so I can design a little too. But, if I’m honest, I’m not world class at either of those things. I realised, when I thought about this list, that if I was going to have any role in a product team I’d need to become a good dictator.

There is no shortage of advice online about how to be a good designer or a good software developer. But what about advice for those who aspire to be good dictators?

The last job title I had at Trade Me, many years ago now, 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 it means to be a “Product Manager”.

Let me attempt to describe the job, at least as I’ve experienced it, for anybody who might be interested in this sort of role.

Back in the day, we used this 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. I think this is generic enough that it could be applied to any team working on developing a product or service, whether it’s brand new (as Trade Me was then) or decades old (as Trade Me is now).

There are six links in the infinite loop, so let’s go through them.

Actually it’s two somewhat separate tracks: the smaller software development loop and the larger product development loop.

The work involved in the smaller loop is pretty well understood these days and well documented elsewhere, so let’s focus on the larger outer loop, and pick it up at the point where we are ready to deploy a new feature out into the wild…

Release

The first and most important thing to realise about any product 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 involved 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. We are never finished.

This has a number of consequences, not the least being the importance of pacing ourselves. Managing a product is a never-ending slow and steady run, not a sprint or a death march.

The second important thing to realise about the release cycle is how we win.

It’s tempting to think that we succeed by doing a good job and getting everything right. But, remember, I just said that we 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" , and “if you launch and you’re not a little embarrassed then you launched too late” , etc etc.

In other words, our challenge is not to navigate flawlessly once around this loop, but to navigate our way around as many times as we 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.

Measure

As soon as changes are released, the next challenge is to create a feedback loop.

This is where we get to see to what people do rather than listen to what they say they will do. If we can start to understand how people are really using our product then it helps us to cut through debate in the next two steps of the process with facts rather than feelings. It’s how we build confidence in our 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 we ensure that we focus our efforts on the things that matter. As a product manager this means making sure that everybody knows what the key metrics are. We 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 that everybody can see. And, more importantly, always ensure that our team can articulate how the particular features they are currently working on will positively impact on those numbers.

Prioritise

Broadly speaking the primary job of a product manager is to keep lists.

We 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, we need to be aware of all of the things that are underway, ideally with some idea for when they should be completed so we can keep a detailed schedule in mind.

Secondly, and most importantly, we need to have a clear focus on what’s next. We should be able to list the next top three, four or five projects in the queue from memory, so we can keep everybody focused on those.

There will constantly be competing suggestions, of course. In that situation, provided we 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 we 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 ideas 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, we need somewhere to dump everything else. And for any non-trivial product everything else can be a lot! It may be that we don’t even need to write these things down - if we’re prepared to assume that the good ideas will keep coming up. Or, maybe having a long shopping list is handy, so that we 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 that makes it difficult to keep going on the things that need to come first.

Remember we’ll never be finished, so getting to the end of the list is not the goal.

Once we have priorities agreed, then we need to consider the order. There are two different approaches to scheduling projects that I’ve seen used effectively:

The Riverstone Model

This model is recommended if we have more priority projects than development capacity.

Think of our schedule as a riverbed, and our job is to cover it in river stones. We’ll start by placing the big stones, picking the most important big projects to go first. Then we 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 we scatter some little pebbles - we 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, we can live with the gaps and leave some slack in the system, which is often not a bad thing.

The Train Carriage Model

This model is recommended if we have more development capacity than prioritised projects.

Think of our release schedule as a series of train carriages. On a self-imposed regular timetable one will leave the station, and our job as product manager is to make sure that all of the seats on the carriage are filled. When a new project is agreed we also pick a carriage to target for release and reserve a seat in that carriage. Once a carriage is full we need to pick the next one available. And, if a carriage leaves the station with empty seats then that is a missed opportunity, so we 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.

Scope & Design

This is where a good product manager will probably end up investing most of their time.

Once we reallise that the most important thing is what the customer actually does, not what the software can theoretically do, everything should focus on the user experience. We typically start 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 we can confirm that the work we’ve done has had the intended impact, or not, and learn from that for future scoping and design work. If we can’t clearly articulate what the intended change or benefit is, then we probably need to go back and think about the feature some more before we start designing the user experience or writing 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 heads-up skills that are not always easy to find in technical people - we need to be able to put ourselves in the shoes of an end user and have empathy for who they are, how they think about our product and how they are likely to respond in different situations; we need to be able to think analytically - we’ll probably spend more time looking at spreadsheets than looking at code; but, on the other hand, we need an aesthetic judgement, a sense of style and an understanding of design trade-offs; we need to be able to write clearly so we can communicate well with others, both internally and externally; we need to think like a marketer, because making things that people will love is hard; we need to be able to work with a variety of different people, both technical and non-technical; and, last but not least, we need to understand that we can achieve a lot in this sort of role provided we 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 we come from a technical background then to be a successful product manager we need to build our skills in these other areas (in my experience, some of the best product managers are heads-up developers who can code but don’t want to anymore). And, vice versa, if we don’t come from a technical background then getting to grips with how the product is built is important, so that we 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.

Related Essays