Product Management. Explanation for Developers
Who are product managers. What product managers do and how are they different from project managers and why does it matter for developers.
If you work in a small company, chances are, your organization never had a dedicated role of a product manager. In startups, a product manager is one of the “hats” of the company’s founder. Founders use their vision and gut feelings to identify where the project should move. From a developer’s perspective, the role and the value of a product manager are not clear. The output of a product manager’s work is a prioritized backlog of product features. “We do this, then that, then something else,” they say.
I guess that developers may feel suspicious about their work. Do you need a dedicated role to generate product ideas? I mean, it’s quite easy, right? If someone asked me to create that list, I would make a year’s worth backlog of features in the half-hour and prioritize it using my understanding of the product and the market. If I want to make it more objective, we can have a team brainstorm to generate an even larger and more high-quality list.
How do you tell a person is doing a good job or a charlatan? As with politics, medicine, and child care, where everyone is a professional, product management seems to be a not-so-overwhelming task on the surface. If you understand the product well enough, you think you can manage the backlog no worse than anyone else, and you don’t need particular expertise.
As in any profession, the difference is understanding the first principles. Despite the name, the primary object of exploring a product manager is not the product, but the customer. Product managers spend the lion’s share of their time exploring customers, their journeys, desires, pains, and frustrations. Then product managers digest, systematize, document their findings, and share them with the rest of the team. Imagine, tomorrow you wake up as a product manager. Now it’s your job to explore the users, prioritize their pain points, and generate the ideas to populate our backlog. How do you approach that?
Jobs to be done and the milkshake dilemma
Bored driver sipping the milkshake
Frameworks simplify our lives. With Django or Ruby on Rails, you can hire junior developers and be confident they don’t turn your application into a total mess. At least, not immediately. The framework provides the constraints, implements best practices, guides you through the process, and tells you what’s right and wrong. You can disagree with some of the decisions of the framework. Still, it’s hard to argue with the fact that having any framework is better than not having anything.
In project management, the framework provides a mental model. Based on that model, the framework offers questions to discover the pain points. One of the most popular and promising frameworks is Jobs to Be Done (in short, JTBD), introduced by Clayton Christensen. The basic principle of JTBD is that customers “hire” products to fulfill the job that needs to be done. A job stems from clients’ need or their frustration with where they are now. The book introduces the concept through the story of a fast-food restaurant that had to increase the sales of the milkshakes. The traditional product-focused approach with questions like “what taste do you prefer” or “do you want it to be milkier, or prefer more chocolate” did not deliver any results.
The breakthrough came when the researchers shifted their focus from the “what” to “why.” Which of your needs drives you to buy a milkshake? Exploring this question, they found that many milkshake buyers purchase it to nurture and entertain themselves during the car commute to work. A subpar entertainment, but it’s better than nothing in slow traffic on your way to the office. Drivers hire the milkshake to brighten the journey with recurrent intakes of milk and sugar.
The restaurant discovered a niche of “entertainment morning commute food.” In that niche, milkshakes compete for attention with donuts, bagels, bananas, coffee, and so on. This revelation helped the owners to serve their customers better: they made milkshake thicker to last longer; also, they started adding fruit pieces to the beverage. How can fruits help? Imagine yourself in a commute, sipping your bland uniform-tasted milkshake, and then, ssssip, a tiny piece of kiwi in your mouth. Its refreshing, sweet and sour taste for a fraction of a second lets you pass behind the sorrow of your travel. That’s how a driver, maybe without recognizing it, has a job to be done and hired a milkshake to fulfill it. The takeaway of the story is that it’s difficult to innovate if your focus is on the product. You need to shift your focus to the customer to have a breakthrough.
Other frameworks
As Django has several alternatives in the Python world, Jobs to Be Done is not the only approach for the product work. As in software development, different frameworks exist to cover a wide range of product-related tasks. Some of them feel like micro-frameworks, focusing on solving one problem. Other frameworks require a global rethinking of how the organization work.
The project Product Frameworks outlines more than sixty product development frameworks, ranging from cheat-sheets and rules of thumbs to fully-fledged end-to-end processes.
Key difference between product and project management
Ok, if the product manager’s focus is on a customer, who takes care of the product? The answer is, there is a different role, a project manager. Along with product managers, project managers carry on their shoulders the responsibility of deciding what product or features can better fulfill the job. Then project managers organize teams of engineers and designers to create and deliver that feature to production.
I can’t help but notice that this is all quite confusing. Not only these two roles have the same acronym, PM. There is an overlap in functionality for turning a job into a product. Finally, in small companies and startups, it’s mostly just two hats of the same person.
In the milkshake example, it’s up to a product manager to reveal the morning commute entertainment job. Together with the project manager, they find out that pieces of fruits can be a solution. Finally, it’s up to a project manager to update the recipe, the menu, and the processes to execute the change. In the picture below, I connected these roles in a decision-making flow. A product manager talks with a customer and builds a backlog of jobs to be done. A project manager takes these insights to create a backlog of user stories to do the job. Finally, developers use these stories to implement features and deliver them to production.
Product and project managers focus on the same problem from different angles. They both find ways to satisfy clients without spending too much effort on development. Product managers work with hypotheses. Well-versed product people use anything that fits to test the idea with minimal or no activities: gut feelings, back-of-the-envelope calculations, static landings, paper prototyping, etc. The focus of project managers is on execution. They care about delivering the functionality on time and within budget. One of the skills of a successful project manager is limiting and specifying the scope of work, preventing feature creep. From a developer’s perspective, the output is the same, a set of task to implement, but product and project managers use different techniques to limit the scope and make sure that developers, designers, and other “doers” don’t waste their efforts on something that clients don’t need.
A product development lifecycle from customer needs to features in production
Caveat emptor. The picture above provides a representation of my speculation on product development. There, we have two distinct roles, and practitioners found it over-engineered. In reality, it is very uncommon to have product and project managers in the same organization, they say.
What developers see and what’s hidden from their sight
Put yourself into the position of a developer in the image above and look to the left. Imagine what you would see — a large picture of a project manager and a backlog of user stories. Behind the project manager, there is a product manager, not so prominent, holding the backlog of jobs to be done. Much further, barely visible, a customer with their needs, desires, and pains.
We, developers, have a distorted perception of what’s essential and what’s not. Product and its features are front and center while users are far away down the line. Like in a broken telephone, what we build may be too far from what a customer wants. Shortening the path between customers and developers and tightening the feedback loop is the key factor to success.
42% of startups failed because they created a useless product
Think about it from another perspective. The top-1 cause of startup failures is that they create something that nobody wants. The polished design, perfect architecture, zero bugs, shiny landing page, responsive support team, all this doesn’t matter if customers don’t care.
A developer or development manager venturing into your project, shift their perspective from product-first to customer-first. As it turns out, it’s not the same.
I would like to thank Ilya Kotelnikov @scukko for his valuable feedback. He helped me see a bigger picture of product development, and I included some of his insights and comments in the post.