I’ve been wanting to write this blog post for a while. As the title may infer, it’s a particular bugbear of mine to conflate the two roles. These are two distinct professions, which have vital roles in a delivery team. In this blog post, I wanted to share what I see the major differences between the two are.

Let’s start with the basics

Product Managers are in charge of understanding customer needs. They concentrate on crafting a product vision, strategy, and making sure the product meets market needs. A Product Manager tends to thrive in uncertainty and are not worried about failing because they see it as an opportunity to learn especially during something like discovery.

Project Managers focus on developing and executing plans. Their success is measured by how well they handle timelines, resources, and deliverables to finish a project. I have observed Project Managers tend to crave certainty in scope and what needs to be done.

How do the two work together?

A Product Manager will work with the team to build great software aligned to the vision, product strategy and roadmap. In turn, the Project Manager will craft a timeline, which indicates when the project will expect to be finished. They will manage the risks and work out how to mitigate those with the Product Manager. The Project Manager will ensure the right expertise is part of the delivery team, manage the budget, coordinate dependencies with other teams, and will work with the Product Manager to give governance updates to senior leadership.

Project vs Product thinking

I’m a big fan of the product leader Shreyas Doshi. He articulated the difference between project and product thinking with this diagram. Let’s break this down further:

‘Project vs. Product thinking’ an image by Shreyas Doshi: https://x.com/shreyas/status/1712262410764173598

Project thinking:

• Want to know when something will be done. This will be communicated to senior leadership via timelines or gantt charts.
• Want to know the exact scope. They care that something will be produced and the plan has been executed as expected by senior leaders. They want a start and end.
• Are interested in making the process for delivery more efficient. This might be by simplifying agile ceremonies, or removing blockers.
• Are more likely to follow a well-defined structure or process. For example, using a traditional RAID log, or a budget tracker.
• Are not coding or speaking to users. They want to be hitting milestones and will worry if a target date is missed. If this is the case, a Project Manager will seek to influence the team to consider alternative options like reducing the scope or seeking to push for urgency to resolve the issue.
• The danger of excessive project thinking is to create huge amounts of documentation that doesn’t take into account change or risks. This can lead to frustration as certainty is expected. Delivering software is hard!

Product thinking:

• Care that the thing being created is meeting user and business needs.
• Are focused on improving the experience for users so that they can meet their end goals. They understand that this may mean a change in requirements, and constant prioritisation is needed to deliver the right thing for users.
• Care about identifying measures of success, and they want to exceed KPIs to show that outcomes are being met.
• They avoid solutionising. Instead they work with a multi-disciplinary team to identify pain points, test hypotheses and experiment to deliver the best results for users and the business. They empower team members by trusting them and their skillset to think deeply about the problem.
• Care about differentiating themselves from competitors to stand out from the crowds.
• The danger of excessive product thinking is that you are unable to answer the question on all stakeholders’ minds ‘when will it be done?’. The work being done can come across as chaotic unless communication is transparent.

How a project mindset might approach a problem compared to a product mindset

In a Shreyas twitter thread (seriously, please follow him), he gives an example of project thinking when Bob is approached by Alice to deliver a key feature. Bob takes a ‘project thinking’ approach by mentioning people allocation and other milestones. This approach might frustrate senior leadership because this is clearly a key priority for the CEO.

Whereas, Dave takes a ‘product thinking’ approach by recognising the request, understanding there’s data to support the request and adjusting the roadmap. They broke down the initial request into smaller chunks so it became more manageable. Dave recognises the opportunity.

You need both approaches to solve the problem posed by Alice. You need Bob recognising that we might not have the people to deliver something, but also Dave to consider how it might be delivered to meet the deadline. As Shreyas puts it, understanding your constraints leads to more decisive actions.

Conclusion

I hope by the end of this blog post, you understand the differences in thinking styles and problem-solving approaches, highlighting the complementary nature of these roles and the importance of understanding their unique contributions to achieving successful outcomes.