Project versus Product and Product Owner versus Project Manager

In this article, we explore what is meant by the terms project and product and look at the differences between a Product Owner and Project Manager.

Project versus Product

The term project, according to Wikipedia, is a collaborative enterprise, involving research or design, that is carefully planned to achieve a particular aim.

The word comes from the Latin projectum meaning ‘before an action’. In fact, the original adoption into English meant the planning of action and not the action itself.

In modern business, a project is usually taken to mean the planning, the execution, and the delivery. The term in software development is more often used when the process used for delivery is a non-agile methodology, such as waterfall. It usually refers to a set of sequential specialist stages in which a manager is required to keep track of the many dependent parts, the finance, the risks, and the time to deliver.

Project Manager

In my opinion, a Project Manager is required on any initiative, agile or not, if the organisational design is optimised too much towards specialisation of skills or architectural components (Conways Law). Over-specialisation is a local optimisation which supposes that if you group people around a specific skillset (for example DBAs, or BAs) or architectural component (for example a code library, or service) that this gives efficiencies in either cost or quality. Unfortunately, this is rarely true in practice. And this type of optimisation has the flip side at the system level, of producing:

• high levels of hand-off
• too much work in progress
• lack of ownership
• poor quality

You can read more about this in my blog post on gaining more capacity without hiring anyone and in Craig Larman’s presentation recorded at AWA last year.

The Project Manager is required in this instance as the only point of ownership to somehow bring the whole initiative to its intended conclusion.

Typically, a project is funded with specific goals and a business case in mind. Being of finite time, and of finite expected value and cost. It is typical to bring people or teams together for the purpose of planning, executing, testing, and releasing the outcomes of the project. Often these teams are disbanded at the close of the project.

Product Owner versus Project Manager

A Project Manager’s function then is to create a plan, often called a baseline plan, that the project will follow. They then drive the people involved in the project to follow that plan with as little change as possible. If there are deviations from the plan, then the Project Manager’s role is to limit these deviations and to bring back the execution as close as possible to the original baseline. If this falls outside an accepted variance and is not recoverable, the Project Manager must explain and gain acceptance from the original stakeholders or investors. Or in the worst case, tell them how it is. Sometimes this deviance from the base plan may result in the funding being pulled from the project.

A Product Owner conversely has no baseline plan. A Product Owner’s role is to constantly evaluate the viability of continuing the execution of delivery. The Product Owner may optionally produce a high-level road map instead of a detailed plan. The roadmap is typically detailed only for a few weeks ahead. It then becomes progressively less refined as the time horizon increases.

Ultimately, estimation and forecasting are not required in many cases. This is because everyone knows the teams are working on the most important items at any given moment.

Product Groups & Agile Development

A product group in agile is typically formed of long-lived teams. These sometimes last for many years. The Product Owner has two responsibilities; these are prioritisation and clarification. By continually prioritising work, and making sure the delivery teams are working on the highest priority possible. Stakeholders know that whatever the outcome, the teams are optimised around achieving the right objectives with the smallest amount of work possible.

In agile development, feedback is gained every release or sooner. This is at the end of a sprint in Scrum. In Kanban (and sometimes Scrum), this is every time a work item has been completed.

This feedback guides the prioritisation of further work. Thus ensuring that the teams are building the right thing (reducing business risk). And that they are continuously delivering (reducing delivery risk) every few weeks at the longest.

Lack of motivation…

Large batch delivery cycles (typical on projects that fix time, scope, and cost) cause pressures to occur in the team. These pressures often cause the team to take shortcuts, resulting in lower motivation from lack of mastery. The primary measure of the success of a project is often given to the delivery teams as delivering a set of features on time and within budget. This focus removes the ability for the team to ask the question WHY and focuses the teams on the WHAT and the HOW.

Lack of motivation increases because the teams lose a sense of purpose. They become merely an extension of the project machine. Fixed scope and the loss of autonomy in how to operate compounds this low motivation. The most efficient means of execution in a crisis is when the manager tells the team exactly what to do and when. When crisis becomes the usual mode of operation, and autonomy is removed, motivation and dissatisfaction increase accordingly.

As motivation is reduced, people leave, compounding the problem of delivering on time.

Simon Powers

…vs high ownership of outcomes

Conversely, in a product delivery team, there are no such pressures. The time and cost may be fixed, but the scope is not. With a variable scope, and through feedback and collaboration with stakeholders, the manager/leader/Scrum Master, is able to remove this pressure. They can then create an environment where individuals reach a higher potential. Where people operate autonomously, resulting in better problem-solving, higher ownership of outcomes, and faster time to market.

The role of Project Manager

In short, a Project Manager, whether they have agile in their job title or not, is a stop-gap role. They are in place whilst the organisation removes the impediments stopping a team from being self-managing and optimising around product delivery.

This is typically:

• Introduction of the generalising specialist (system optimisation)
• And reduction of over-specialised silo teams and bottleneck people (local optimisation)
• Introduction and maturity of automated testing allowing shared code ownership across teams and automated integration
  • significantly reducing the need for people level co-ordination and instead moving dependency problems to code level dependency
• Removal of long term fixed scope initiatives and instead value / risk based prioritisation
• Change of management style from Theory X to Theory Y
  • removal of arbitrary deadlines
  • removal of the idea of developer commitment even over short time frames
  • removal of locked down internet sites
  • removal of bonuses as a means of motivation
  • increase of transparent financial management
  • increase of short term rolling budgets funding prioritised backlogs and constant product viability feedback
  • rise of the leadership and reduction of management

When this happens, the need for the Project Manager simply disappears. There is less need for the high level of coordination and fake motivation required for teams working in a purely agile way.

Further reading

Co-ordination Chaos. Thank you for Ari Tikka for sharing.

Thank you to Ram Srinivasan for sharing the following links:

• Project vs Product 
• No Projects – Projects Flawed
• Beyond Projects

Finally, if you’re interested in project and delivery management, why not take our Certified Agile Project & Delivery Management (ICP-APM) course, which is available in-house.