By Georges Duverger
In 2015, I moved from software engineering to product management. Since then, I spent a lot of time thinking about the role of product manager and I believe that we can summarize it in 3 fundamental questions.
Product management means many different things to many different people. Some PMs (product managers) are technical, like me, others have more of a business or design background. Regardless of where we are coming from as product people, we have to answer 3 fundamental questions to fulfill our role:
What to do?
What is the vision? How big is the opportunity? Who are the users?…
It includes all the research, validation, and prioritization necessary to decide what to work on. Fortunately, we can now respond to change along the way instead of following the wrong plan to the ground.
Is it done?
Are we blocked? Do we need more info? Has it been released? Can we test it?…
Chances are our team is already overallocated and things are inevitably falling through the cracks. That is why we need management—the process of dealing with humans.
Did it work?
Did it increase revenue? Did it improve the acquisition, activation, or retention of users?…
In an ideal world, a goal would be attached to every task, even a qualitative one like customer satisfaction. That goal would then be monitored over time to measure success objectively.
The intent here is not to shoehorn everything a PM does into confining categories. Instead, the point is to make sure that whatever it is a PM already does offer good answers to those questions.
Adopting that framework helped me identify key challenges:
Nobody likes a cumbersome tool. Most project management applications are trying to be everything for everybody. Jira, the leading solution, tries to answer the first 2 questions at the same time (the “what to do” with descriptions, comments, and ranked backlogs, and the “is it done” with issue statuses and version releases) which results in a lot of inefficiencies.
Nobody wants to be micromanaged. Having to frequently ping team members about the status of a task is distracting and generates unproductive tension. For example, asking engineers to report their progress seems like a waste of time given that most of that information is already available in the codebase.
Nobody knows if it worked. Big companies have ways to link a specific code change to an increase or decrease in revenue, for better or worse. A lot of startups, due in part to their lack of scale, only have hopes that a set of features will have a positive impact on their business.
I am interested in hearing if that framework resonates with other PMs and if some have experimented with methods to address those questions or challenges. Please reach out to let me know.
Styled with Screen