An Introduction to Product Management
As a developer, product management can be an entirely alien craft. It can seem like either a valueless function or it can seem like glue holding the whole operation together. Oftentimes, it’s somewhere in the middle and is heavily influenced by how your product manager fulfills their role. Here’s a little view of what it means independent of those factors.
Let’s start at the bottom and work our way up. The most basic purpose of a product is to fulfill consumer need; products solve a problem. Products, before they can solve problems, must first be designed, built, and marketed. Product managers sit at the intersection of these three processes. They work with UX and design teams to develop how the final result will look and feel. They work with developers to architect the solution and decide how they’re actually going to build it. And they work with marketers and the business to decide how (and why) they’re going to sell the product.
Between all three domains, the PM needs to understand each process, communicate reasoning and design considerations across teams, and guide the various teams towards the completion of a successful product. Of those responsibilities, understanding process is the most important. The teams working together via a product manager can be reasonably siloed and can’t be expected to consider all the challenges faced by the other teams while also developing solutions within their own domain. Here, product management is the glue that holds the whole operation together. The PM should be conversant in each team’s expertise so that they can understand how the product is coming together and communicate it broadly.
Putting it all together, the product management process can be boiled down to six steps:
Product conception —
Before anyone can manage a product, we need to come up with a product and products are all about solving problems. Find a problem that needs solving!
Validate your hypothesis —
Does the proposed product actually solve the aforementioned problem? Can you quantify the addressable market? Is the it even marketable? This step aims to reduce assumption. In a long-term project like product management, the number of assumptions made is directly proportional to risk.
Develop —
This is the most work intensive and likely longest step. The product’s technical requirements need to be identified and work needs to be prioritized. In the real world, this is often an iterative step. Requirements can change and priorities may shift, usually one as a result of the other. The risk involved in this step can be considerably reduced by producing an MVP, or minimum viable product, before moving on to a more feature-rich solution.
An MVP is the bare minimum solution to the consumer’s problem. The goal here is to perform the least amount of work necessary to get the most information about the problem your product is intended to solve. Working towards a minimum viable product rather than diving in head first allows the product manager to do three very important things: Fail fast, save money, and reduce work.
Failing fast means company resources aren’t wasted on products that aren’t marketable or won’t generate sufficient revenue to justify their production. Saving money and reducing work both follow from fast failure. Identifying an unsuccessful product early saves money, time, and working hours.
Launch —
The most important step of launching is setting the launch date. At the very least, the product manager should have some say in when this occurs as it can have a dramatic impact on product success (especially in the software industry). Launching also means that the product is now in the hands of consumers. This means it’s time to collect feedback and analyse marketing data. What could be better? How effective was the latest marketing campaign?
Iterate —
No product is perfect the first time. It may not fully solve the problem it was intended to solve. The problem may have changed or a false assumption might have been made during the production process. Essentially, we take it from the top and go through the product production and management process all over again.
Steady state —
After various iterations, the solution has either achieved its purpose or it hasn’t. Either way, there isn’t much more to be done. Now it’s time to decide the product’s fate. Is it worth maintaining? If not, how do we make the product end-of-life? For software, this is pretty easy. The product manager marks the product as EOL in official documentation, sets a date, and withdraws support for the software. For hardware, however, this can be a far more expensive problem. Oftentimes, this means setting the MSRP at a discount, paying the retailer the difference, and hoping the remaining stock sells out.
In the end, the goal of the product manager is to coordinate the many disparate facets of the production process and ultimately produce an efficient, aesthetically pleasing, and marketable solution. This may sound like a tall order and, simply put, that’s because it is.
Much of my insight into this process comes from my attendance of a product management workshop by the title Product Management 101 with Sekou White, hosted by General Assembly. Sekou, as of writing this, is a professor at NYU and regularly runs workshops at General Assembly. You can check out his upcoming workshops here.
