Product Ownership Evolution, part 1

This post is the first (out of 4) of blog series about Product Ownership Evolution. Our organization has been evolving quite a bit in our Product Ownership thinking and understanding during our transformation journey. In these blog posts I try to summarize our main approaches, the evolution and some thinking and challenges that have been visible in our context (some of these thoughts may also be something you can relate to).

1. Simplistic Scrum approach (this post)

2. Scaled-Up Scrum (part 2)

3. Requirement Areas (part 3)

4. Enterprise Product Ownership (part 4)


We started more than 3 years ago with basic and simple Scrum approach. Scrum definition of Product Owner:

The Product Owner is the one and only person responsible
for managing and controlling the Product Backlog. This is the
person who is officially responsible for the value of the work
done. This person maintains the Product Backlog and ensures
that it is visible to everyone. (Scrum Guide page 4)

This approach assumes a few vital fundamentals that are in place, otherwise we might will face problems:

1. Scrum team is in place: we have a ScrumMaster, PO and a team. Team should be crossfunctional end-to-end feature team. In my thinking this implies that enterprise level operative view is embedded within one team. In other words the whole value chain is realized with 5-7 persons and multiplied (if scaling is required) with additional teams that share the same approach.

2. Customer collaboration over contract negotiation. This is the fundamental from Agile Manifesto which is maybe the most important (and most often misused) when considering PO. In enterprise this means that there should not be separate Product Management and R&D organization. PO (as fully responsible of value of the work done) has the authority and responsibility to use all assets as he/she prioritizes. There is no role for R&D line organizations to decide what work is done by people or machinery. The traditional commitment game has disappeared. Unfortunately I have not seen or heard this being realized in any large organization. If this is not in place (as I have witnessed) -Scrum does not work. 

While we now seem to somehow understand these we do not have (or did not have) these fully in place. This created a lot of confusion and additional challenge in understanding how Agile is realized within Scrum context. A couple of examples.

Product Owner did not understand what is the level of technical detail he/she needs to go. This was partially due to missing authority on the business side -focus was put on the technical issues instead of business value. This was partially fixed with moving more responsibility of technical work to System level Communities, which were for developers (I will open up this more in part3 of this series)

System test was completely missing from the early User Stories and Epics. This resulted that work was only partially done within Scrum teams. This division also was visible also within Product Owner: “Done” features could not be delivered to customer before additional testing or configuration (outside Scrum teams) and this was not perceived as responsibility of PO.

Impediment handling was not sufficient. Only part of the organization was attending to the continuous improvement work withing Scrum context. A lean principle “see the whole” was missing and this resulted to sub-optimization.

To summarize: our organization was not able to adopt simplistic Scrum approach to make it work sufficiently. We might come back on these ideas when we learn how to implement more vital key fundamentals but initially our decision was to adapt. Our next approach was to introduce Scaled-Up Scrum (more on next part of this series).


About Henri Kivioja

I believe in teams, personal development, humanity and good life.
This entry was posted in Agile Thinking, AgileTesting, Continuous Deployment, Framework, Leadership, Lean, Product Owner, Scrum and tagged , , , , , , , , . Bookmark the permalink.

5 Responses to Product Ownership Evolution, part 1

  1. Antti Jarva says:

    Thanks, Henri! Very interesting notifications you’ve made.

    A few comments/questions as follows:
    1. Who makes the decisions regarding the grade of cross-functionality in teams, i.e. who should be aware of each individual’s knowledge areas?
    – the plain fact is that the majority of knowledge is of type tacit
    – my experience and empirical research studies fully support the idea to have end-to-end operative capabilities within a team and that line organizations shouldn’t have operative authorities
    – actually the question could be formulated like “Which organizational entity has the responsibility to take care of all individual competences and that those competences are used in the best possible way to support the strategy, business continuity and success of a specific firm, as well as to secure competence development according to the company strategy?”
    2. The conclusive idea to integrate product management and product ownership instances sounds pretty tempting. Yet, the following aspects could be taken into consideration:
    – usually product and R&D strategies are separated; of course, R&D strategies have to support all the strategies above them, e.g. overall company and product strategies
    – product management is involved with marketing and sales related product strategies
    – my empirical studies point out that one of the most important interfaces R&D POs’ have is towards the product management
    – POs should be able give input to product strategies, but not to be responsible for them (POs secure that strategic plans are executed in an operatively effective way)
    3. Customer collaboration is crucial as Henri proposes
    – strategic dimension of customer collaboration takes place by the product management
    – POs could be involved both with strategic and operative collaboration
    – teams could participate in operative colloboration actions, e.g. to secure that right type of features are to be delivered at right time (also potential “verification outsourcing” possibilities can be seen in the team-customer interface)
    – customer collaboration, being an initial step towards strategic network management, is important for companies to survive in the ever-accelerating business world

    Looking forward to reading the other parts of Henri’s blog posts concerning the topic Product Ownership Evolution.

  2. Outi Vaattanen says:

    Great start for a series! Looking forward for coming posts!

  3. Henri Kivioja says:


    For bullet 1 I can only comment that responsibility is not within organization but merely on individuals themselves. This is clear for new generation but sometimes challenging for a bit older generation.
    For strategic viewpoint I see the same symptom as from pure organizational perspective: A company should only follow one path. If you divide your strategic intent then you are not fullfilling the ultimate purpose of any company: to delight the customer. This implicitly leads to better customer collaboration and removing barriers from achieving this.



  4. Antti Jarva says:

    Thanks, Henri!

    Do you mean that your Agile teams define, thus are responsible for the entire company vision, mission and strategy? Actually, pretty attractive an idea to have, e.g. one team for such purposes. Regular outcomes in sprint reviews could improve communication of company’s direction heavily. Sprint length may not be less than a month. This special team should consist of the BoD-members, the CEO and other upper-level decision makers. Usually Agile teams are dedicated only to a tiny operative sub-mission to be carried out at a time. To reach specific sub-missions, tasks, teams are assumed to utilize anything, e.g. knowledge and tangible assets, available within and for a team. Surely, inter-team plans and decisions are owned by team members only. On the other hand, input from teams, e.g. new ideas and creation of new knowledge, is valuable to management teams and even BoDs, which should have all the skills to see the seeds of new business, strategic and operative improvements as competitive advantages, etc.

    About strategies: Different entities inside the very same company do not have similar strategies due to differentiated missions. E.g. sales people have a strategy of their own, and development organizations theirs – but lower level strategies must support upper level strategies. OK, micro and small companies are expected to be vertically more integrated and more dynamic, reducing also the number of needed missions and strategies.

    The purpose of privately owned companies is to create (according to the law: to maximize) positive, continuous return on the share owners’ investments 😉 Sorry, I just couldn’t resist.

    How do you organize team specific customer collaboration activities in practice?

    • Henri Kivioja says:

      This is the hard part, as it is not natural for most of the people in teams to address the business, company leadership and strategy. In addition to this most of the structures in traditional companies to not support this approach: the managers already possess these areas so why would they want to change? In long term (my belief) culture should address this, but fierce resistance may result that it just would take too long. And this might result to a situation that we could see collapses on surprisingly many companies in near future. As long as investors (as the owners of the companies) do not understand these new laws it is virtually impossible to see any significant change in how companies are run.

      This is the main reason, I believe, that Agile and Lean are successful in smaller, privately own companies and might not never really succeed in public sector or large corporations.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s