Week1: the product owner

This post is part of the series “Z2A: From zero to agile”.

The product owner

Another topic to be taken care before starting with the next action (hopefully all these can be done in the one week, the first week, otherwise feel free to take more time before tackling the product backlog): appoint the product owner.

The product owner is a person. One person, not a committee. Committees may exist that advise or influence this person but people who want e.g. to change an item’s priority have to convince first the Product Owner.

He/she is the requirements responsible, the person in charge of converting the project goal or the customers wishes into requirements. He/she is also the person who takes the final decision about the requirements priority or to change them or to clarify them.

For the Product Owner to succeed, everyone in the organization has to respect his or her decisions. No one is allowed to tell the team to work from a different set of priorities, and teams aren’t allowed to listen to anyone who says otherwise.


  • Product visionary
  • Represents the business needs, the stakeholders and the end-users so the team is guided by one voice.
  • Must be fully committed to the team. Or at least, must be available to give immediate feedback on delivery and performance questions to the team.
  • Own and maintains the product backlog.

Week1: the project goal

This post is part of the series “Z2A: From zero to agile”.

Have a project goal

This is not actually an agile specific recommendation but a general project management practice; you can refer to my posts with the tag *PMI* for more details.
Anyway before going to the next topic, let’s make sure this is consolidated in your project: it shall have a proper goal, a vision. Not the requirements, nor the features neither the stories but what is the ultimate goal of this project? At a high level, what do the financial sponsors want to get out of this project?

At the end if you don’t know where to go, then any road will be the same…

How to form the goal: start from the biz case

Of course, every project or product needs to state a business case. In an agile process, you  create the business case using face-to-face commitment techniques with the key stakeholders to ensure that there is a firm understanding of and commitment to why you are doing the project.

Involve the product owner and the financial sponsors, in case make a workshop.

Remember: the shared deep understanding of why a project will be beneficial to the business is much more important than the actual business case you can print and read. Spend all the necessary time for it.

A good way to create a proper goal is to use the SMART framework.

Write down the goal

The goal can usually be expressed in a few sentences, which can be collected in one single page. It should be the first page of your project charter.

Once you have it, hang it on the wall or put it in the first page of your project intranet, so that everyone can always see it and remember what is the project final scope.

You would be surprised on how many projects don’t have a proper goal in place.

Examples of project goals could be “redesign our e-commerce website in order to improve customer conversion of 30%” or “make our government organization web site accessible” or “create a new mobile app that will do x and z”.

Can the goal change?

Short answer: usually not, but it will.

Sure, the requirements can change during the project lifetime but the goal you assume is defined at the beginning of the project and stay the same.

At the end, you need to have a strategy, a big picture, otherwise how will you be sure that the requirements will deliver values and how can you take sound decisions when changing them or bringing in new requirements to leverage new business possibilities?

But the reality is that you have to be prepared to have to change or adjust your goal as you discover more opportunities along the way. We may create a vision first, but the vision will be being challenged and updated. The agile business case stays with the product owner and the team, being constantly questioned, changed and proven.

My suggestion is that if the goal changes so much that is completely different (like if you pivot your start-up product, from “creating a system to share images for online massive multi-players” to “creating a system to share pictures with everyone”) then it’s better to close that project and start a new one.