This series of posts about Product Management is designed to explain exactly what Product Management is and what the benefits are to the client and the developer.
To start, let’s define what we mean by “product” – in this context, a product is any piece of technology which provides value, generally by solving a problem. You have no doubt benefitted from products solving a dozen or more problems for you before you even started work this morning, for example:
- your alarm clock solved the problem of waking you up on time
- your calendar solved the problem of telling you what appointments you have today
- your satnav solved the problem of finding the location of your first appointment
- and the instant messenger on your phone solved the problem of letting a loved one know you’ve arrived safely
These products, and the problems they solve, are so ubiquitous people take them for granted (which is exactly the point in a lot of instances), but each one of these products was designed, tested, refined, and launched with the goal of making people’s lives easier.
But it takes more than just a good idea to solve a problem, as the solution needs to be balanced out with the goals of the business, the technological requirements which let it function, and the user experience it provides.
And it’s here, balancing out these distinct areas of focus, that Product Management sits, or to put it another way, like Martin Eriksson did in 2011:
“I’ve always defined product management as the intersection between business, technology, and user experience […] A good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.”
Who Does the Product Management? Introducing the Product Manager
So, what does a Product Manager do? And how is that different to a Project Manager?
A Product Manager is the person who will take long-term, high-level ownership of a product. This means they’ll be responsible for understanding the problems a product solves and the value it delivers, and will typically own the roadmap, allowing them to facilitate the direction of its future development. They do this by being the liaison between the product’s stakeholders and the developers who write the code, while also being an advocate for the end user.
We like to think of the Product Manager focusing on the “who”, the “what” and the “why”, distinct from a Project Manager, who is more focused on the “how” and the “when”. A Project Manager is typically working to a specific budget and timeframe for delivering a specific set of features, whereas a Product Manager will have an intimate relationship with the product for the long term.
A Product Manager’s main tool is communication. They’re responsible for translating requirements from stakeholders into specifications ready to be consumed by developers, ensuring everyone involved along the line has an equal understanding of said requirements. This means everyone must understand not only what needs to be done, but more importantly, why it needs to be done, and who it’s being done for.
But they also must be part-facilitator, part-researcher, part-scribe, part-evangelist, part-techie, part-leader, part-entrepreneur and part-marketer, all without having any actual authority over the people writing the code and building the features. A tall order indeed.
So, How Do They Do It?
The Product Manager is vital for keeping the product on track: helping keep the overview and objective of the product known to the team, liaising between the stakeholders/client and the developers, and retaining the user perspective to deliver value.
There are any number of tools in the Product Manager’s arsenal, many of which I’ll be discussing in upcoming posts: