Product Management

How do we turn promising ideas into real products people can use?

It’s said 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 I’d need to become a good dictator.

There is no shortage of advice about how to be a good designer or a good software developer. But much less about effective dictatorship.

The last job title I had at Trade Me was “Head of Product”. Most people understand what it means to be a software developer. But I’ve never seen a succinct definition of a product manager. Let me describe that job for anybody who might be interested in this role.

This is the product development process we used a Trade Me. It could be used by any team, whether it’s brand new (as Trade Me was then) or decades old (as Trade Me is now).

There are six steps in two loops. The work involved in the smaller “software development” loop is well understood now and well documented elsewhere,² so let’s focus on the larger “product management” 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 about any product release is it’s not an end point. It’s just another link in an infinite loop. When we think we’re done, that’s the beginning.³

This can be tough to understand for technical people who have predominantly worked on projects that have a well defined beginning and end, when 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 trek, not a sprint or a death march.

The second important thing about the release cycle is how we win. It’s tempting to think it’s about getting everything right. But, remember, 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. Remember “if we’re not prepared to be wrong we’ll never come up with anything original”, and “if we launch and we’re not a little embarrassed then we launched too late”. The only way we learn which parts we need to be embarrassed about later is by launching and listening carefully to the feedback we get.

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.

Some release theatre can help, so that everybody on the team is aware when new features or even small fixes are deployed and can celebrate the incremental progress that represents.

Measure

As soon as we make changes, the next challenge is to create a feedback loop.

This is where we see what people do. Once we 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 a model about what customers respond to. This doesn’t always mean doing what customers love. Often it’s a product manager’s job to do what is best for the business as a whole, rather than for individual customers.

The whole team should know what the key metrics are and how the business wins, so we stay focussed on the things that matter. We can highlight both the current values and the trends. For example, on a visible big screen on the office wall, or shared online dashboard. We should always be able to articulate how any particular feature we are working on will positively impact those numbers.

Prioritise

The primary job of a product manager is to keep lists.

We have 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 the work in progress, ideally with expected completion dates 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 projects in the queue from memory, so we can keep everybody focused on those.

There will constantly be competing suggestions, of course. When that happens we need to list the current priorities and ask: 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 powerful if there is consensus about the priority projects. A useful technique 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 (the expected impact on key metrics) vs. buck (the 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 good ideas will keep coming up. Or, maybe having a long shopping list lets us 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 backlog 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:

Riverstone model - if we have more priority projects than development capacity.

Think of the 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 the little gaps we scatter some little pebbles - we probably don’t have to pay too much attention to which of these go first, it could be as 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.

Train carriage model - if we have more development capacity than prioritised projects.

Think of the releases as a series of train carriages. On a self-imposed regular timetable one will leave the station, and our job is to make sure that every seat on the carriage is 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. 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 the link in the chain where a good product manager should invest most of their time.

Once we realise 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 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. 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. More importantly, both designers and developers need to be talking frequently with customers.

When considering any major change we 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 customers.

We should be able to describe the change are we expecting once this feature is released and how we will measure that. This question creates the feedback loop, so 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 need to think 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.

Everything & nothing

The job demands a wide range of skills, including people skills not always common among technical people.

As product managers we need to have empathy for users: who they are, how they think about our product and how they are likely to respond in different situations. We need to think analytically. We’ll spend more time looking at spreadsheets than looking at code. On the other hand, we need aesthetic judgement, a sense of style and an understanding of design trade-offs. We need to write clearly and 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 comfortable working with a variety of different people, both technical and non-technical. Last but not least, we need to understand that we can achieve a lot in this role provided we don’t need to take all the credit for ourselves.

Product managers need to be a bridge between the product team and the customer. In the early stages we also fill any gaps. For example, if there is no sales team then we are the sales team. If we come from a technical background we need to build our skills in these other areas. It’s rare that a product manager is great at all of these things. The best product managers I’ve worked with are heads-up developers who can code but don’t want to anymore. If we aren’t technical, we need to understand enough about how the product is built so we can communicate effectively.

A great product manager helps teams create products that customers love.

Related Essays