OWN IT - 8 Simple Secrets of Product Owner Success ebook

Table of Contents

Foreword

About the Author

Introduction

Part 1: The Product Owner

Why Do Product Owners Exist?

The Routines

Common Mistakes

The Characteristics of a Good Product Owner

On User Stories

Prototypes and MVPs

Summary

Part 2: The Success Factors

Four-Step Success Factor Model for Product Owners

Success Factor 1: PLAN

Success Factor 2: GUIDE

Success Factor 3: RELEASE

Success Factor 4: LEARN

Summary

Part 3: The 8 Principles for Successful Product Owners

Building on the Success Factor Model – The 8 Principles

Principle #1: Purposeful Planning

Principle #2: Fantastic Feedback

Principle #3: Optimal Ownership

Principle #4: Team Tactility

Principle #5: Mind the Minors

Principle #6: Earn and Learn

Principle #7: Positivity to Profit

Principle #8: Aspire to Excel

Summary

Recommended Reading

Acknowledgements

Foreword

When Arto told me about his new book and asked me to both review it and to write a foreword, I was both flattered and scared. I was flattered by Arto’s trust in me and scared of writing this foreword. I wasn’t scared about reviewing the book, as over the years we’ve worked jointly on several product manuals, guides, and white papers, in which Arto did the bulk of the writing and I then “polished” them (a bit).

Arto is one of the most humane tech leaders and educators that I’ve ever met, and it was a great pleasure to read and review this book (several revisions of it, as a matter of fact); it’s a clear demonstration of his humanism, passion, and vast expertise in software development processes and best practices.

For this book, Arto has invested a lot of thought in putting forth a structure that makes his views and ideas approachable and easy to remember and use. The book was a pleasure to read and reminded me of more than a few “challenges” we’ve tackled (or just experienced) together, and I wish I had realized years ago some of the things I learned while reviewing the book.

This book should be read by every Product Owner, Product Manager, Project Manager, R&D Manager, Quality Assurance Manager, Scrum Master, Tech Lead . . . and every technology company founder and CEO. It helps those who need the skills and tools that this book teaches, but it also provides great insight to those stakeholders who need to understand why a software product development organization does (or at least should) work the way that Arto describes.

This book also contains novel concepts and ideas that will make the process more effective and enjoyable for product organizations that adopt them, and make the end products better for it.

—Petri Bäckström (who has served in numerous specialist, generalist and management roles in almost as many companies)

About the Author

Arto Kiiskinen has worked for over 20 years in product development, in different roles such as R&D Project Manager, Program Manager, Product Owner, Scrum Master, Test Engineer, R&D Team Lead, R&D Manager, and R&D Director. He has over 10 years of experience on agile methods, Scrum, Kanban, and experience on leading complex R&D projects that span multiple cultures, countries, and across large time zone differences. He worked 15 years in Nokia, in different product and service areas such as mobile phone software development, digital service business and venture programs, and others. After his Nokia career, he has led the R&D organization in a smaller software company for 5 years.

As a trainer and coach, Arto has helped small and large companies and projects and programs of widely different industries transition to more effective and agile ways of working. Speeding up the path to reduced waste, increased efficiency, and superior team-learning and morale are Arto’s main strengths and passions.

Arto is a PSM certified Scrum Master, PSPO certified Product Owner, certified ISTQB Tester, and certified SAFe Agilist. He has a Master’s degree from Lappeenranta University of Technology.

He is the inventor or co-inventor in 15 U.S. patents and 6 EU patents.

Arto lives in Kirkkonummi, Finland with his wife, cat, and fleet of motorized and pedal powered vehicles.

https://www.linkedin.com/in/arto-kiiskinen-a98611/

Introduction

Product Owner Is the Most Important Role in Agile

Most organizations that are involved in research and development of new products or services acknowledge that one of their key success factors is R&D, especially the people who work in R&D. In modern R&D, almost everyone has access to same technologies and computer resources, but the people create the difference. People use their knowledge and skills and the organizations’ resources and work together to create new, innovative products and services. R&D people with good motivation, tools, ways of working, freedom to self-organize, and vision are vitally important to any organization’s future aspirations.

How does the organization maximize the value they get from their people? The answer is simple – in addition to having the correct skills, tools, and resources, the people need a clear vision and goals, work that’s clearly specified and tested to be of the highest value in any given moment. In essence, that’s what product ownership is all about.

The Product Owner is one of the principal roles in Agile, the others being the development team and the Scrum Master. While scrum is the most popular agile framework, even if the organization or team is using some other agile method, such as Kanban, most of the time, it still makes sense for them to have the roles of team, Scrum Master, and Product Owner. Sometimes, especially in smaller teams, a single person has multiple roles. This doesn’t detract from the importance of still having the roles of Product Owner and Scrum Master in the team.

Having a Product Owner isn’t mandatory. It’s not a law. Some organizations don’t have dedicated Product Owners in their R&D, yet they manage to create products of value. When we later on in the book discuss the concept of Product Owner, the tasks, routines, the Success Factors, and, eventually, the 8 Principles for Successful Product Owners, it doesn’t mean that a single person always has to fill this role. The mission of this book is to describe to the reader what Product Ownership is, why the things that Product Owners do are important, and how one can be successful in the role of Product Owner. It would be best if the organization would endorse product ownership, but even if it doesn’t, if someone does the same work, it will lead to good results.

Why is product ownership so important? It’s because even the best teams need direction, and even the best self-organized teams benefit from having somebody with the single responsibility to define priorities. Product ownership doesn’t mean product dictatorship – the main skills for a successful Product Owner is being able to communicate and listen to a lot of different voices, and then to boldly make informed and transparently communicated decisions.

The role of Product Owner is a challenge. But it’s also a role in which you’ll get satisfaction from optimizing the team performance and defining what gets done. You’re part of creation of new things and new customer value. It feels good. And getting better at this role and achieving more success is fun. The mission of this book is to help you understand the why, what, and how of achieving more success as a Product Owner.

Who This Book Is Meant For

This book is targeted to help people who have a Product Owner role in their organization. It doesn’t matter whether they’re new or experienced. While it’s recommended to read the whole book, an experienced Product Owner could dive directly into the 8 Principles in Part 3.

When starting as a Product Owner, it’s important to understand the different responsibilities and routines of the role. For a person new to the job, it’s advisable to read the entire book. This way, the reader can have some background on the execution of the tasks before proceeding to the mindset, values, and the 8 Principles.

In many organizations, the role of the Product Owner is poorly defined. In many cases, the responsibilities are divided between different people such as Product Manager, Scrum Master, Technical Lead, Architect, or Line Manager. In such a situation, this book can be used as a source of knowledge on agreeing who does what. One of the challenges for organizations is finding the correct person with the right skills who is still close-by and available to act as the Product Owner for the team.

While the book is targeted for Product Owners, people who work in Scrum Master, R&D Manager, or Product Manager roles might also benefit in understanding the methods behind successful product ownership.

About the Structure of The Book

The book consists of three parts:

Part 1: Introduction to Product Ownership

Part 2: The Success Factors for Product Owners

Part 3: The 8 Principles for Successful Product Owners

To lay the foundation for the reader, Part 1 introduces why Product Owners are needed, how the role compares to other management roles, and what kind of routines and tasks Product Owners need to perform. This part of the book can be seen as the why for Product Owners.

In Part 2 we will look at the success factors for Product Owners. The success factors can be seen to define the what for Product Owners. Part 2 will start to reveal the concept of the Product Owner’s Wheel of Success to the reader with its major success factors and subfactors.

The 8 Principles that are then introduced in Part 3 build on the success factors and help the reader understand the effective ways that they can work in the Product Owner role. The Principles define the how for Product Owners. The 8 Principles complete the Product Owner’s Wheel of Success.

The book doesn’t introduce details of Scrum or Kanban. The reader is assumed to know the basics of Scrum before proceeding. For a good and free introduction into Scrum, the reader can, for example, look at the Introduction to Scrum1 webinar. Another good resource is The Scrum Guide2. Terms that are used in this book are explained there.

Many books have been written about product ownership. Similarly, there are lots of training courses for people new to the Product Owner role. The mission of this book isn’t to be a comprehensive, detailed guide to the role. Rather, the book aims to offer an overview into the responsibilities and routines that each Product Owner will face, as well as offering a structure to the factors that affect whether or not a Product Owner is successful.

This book isn’t the only book that offers useful knowledge to the aspiring Product Owner. In the course of reading the book, some very good additional readings will be listed in the text and in the footnotes. The recommended reading chapter at the end of the book collects these resources into a single list.

Original Concepts

The following concepts introduced in this book were developed by the author and introduced for the first time in this book:

The Success Factors for Product Owners

(introduced in Part 2 of the book)

The 8 Principles for Successful Product Owners

(introduced in Part 3 of the book)

The Product Owner’s Wheel of Success

(complete Wheel of Success is introduced first in the beginning of Part 3)

The DEEP Method for User Stories

(introduced in Part 1 – On User Stories)

The Backlog Swimming Pool

(introduced in Part 1 – On User Stories)

The Small Discussions Ceremony

(introduced in Part 3 – Principle #4)

1https://www.scrum.org/resources/introduction-scrum

2https://www.scrum.org/resources/scrum-guide

Part 1

The Product Owner

Why Do Product Owners Exist?

A Product Owner’s mission is to maximize the value generated by the product development team. This sounds easy, but in real life, it’s a very difficult task. Maximizing the value means that the Product Owner has to find out the needs and requirements of multiple stakeholders, balance and value them, and then make sure that they’re documented clearly and communicated effectively to the development teams.

This means that in addition to the development team, the Product Owner has to communicate with multiple different parties inside and outside the organization, such as other Product Owners and Project Managers in the product development organization, company sales department, marketing, product management, the company management, operations, customer support, customers and third parties and partners. The Product Owner must understand all the different requests and requirements and customer problems, and then manage this complex situation to arrive to a prioritized list of things for the development team to investigate, design, implement and release.

“Product Owners exist to maximize the value of development work.„

You can already see from this that a lot of the Product Owner’s work is communication, seeking understanding, testing ideas, defining of details and cooperation with others. But it should also be about actively rejecting ideas, because there will always be many more ideas and requests coming in than the development team can work on with reasonable quality.

If all the feedback, communication, and ideas are allowed to freely flow to the development team, it leads to frequent interruptions, task-switching, inability to focus, poor prioritization, and inevitably – as a result – poor quality and low team morale. Product Owners exist to manage this inflow of ideas to the development team, and their success is measured by how well the team can deliver what the customers want, deliver value with least amount of task switching and interruptions, and have good team morale.

Product Owner Decides What the Team Works On

The whole point of the role of Product Owner is being someone who makes informed decisions regarding what is the highest priority item at any given time. The development team has a limited capacity, and any work they start will quickly become an expensive investment as the hours start to pile up. The Product Owner’s job is to make sure that the investment is put to the best possible use.

The Product Owner does this by limiting the input of the rest of the organization to the development team. She rejects ideas or feedback that aren’t valuable and allows only items of sufficient value to reach the team. She also maximizes the value that the team produces. She does this by maintaining a prioritized list of items, called the product backlog.

The team always knows that when they want to start new work, they can take an item from the top of the backlog, and it will be the most valuable thing that the team can start at any given time. When using Scrum, the team knows that selecting items to the sprint from the top of the backlog delivers most value and are ready for the actual development to start.

“95% of the Product Owner role is communication, collaboration and discussions.„

Similarly, the Product Owner and the team collaborate on the items on the backlog, making them more detailed, accurate, and valuable. This is achieved in workshops and discussions where the team and the Product Owner work on the backlog items together. Sometimes, the items are too large, and they’re split into smaller items. Sometimes, the items require studies to find out the technical feasibility or usability of the items. Sometimes, the Product Owner may choose to work with Product Management to make sure that the business feasibility of any given idea is confirmed well enough that it makes sense to invest development team time on it.

It’s important to remember that ideas almost always don’t hit the mark when they’re introduced to the team. All development must be iterative. Product Owners must be aware of how much the idea has been tested and iterated before entering the team. If it’s likely that certain assumptions must still be tested before final implementation, the Product Owner avoids investing the team’s capacity to something that needs to be changed later. The Product Owner must make sure that the team is implementing the right thing.

What If There Would Be No Product Owner?

Without a Product Owner, the team would have a very difficult time guessing which request is most valuable. Often, the lack of a Product Owner will lead to many people shouting to the development team, and the person who shouts the loudest wins and gets their item into the development team sprint, until someone else shouts even louder! This kind of a situation is very stressful for the team and can also lead to task-switching, forcing the team members to work on multiple things at the same time. All this will lead to poor quality, a stressful work environment, and non-optimal value.

Product Owner and Product Manager

Why do we need Product Owners? Shouldn’t the Product Manager take care of all the things that belong to the Product Owner? This is a statement that’s often heard. It’s very true that the job of Product Manager, in principle, contains all of the tasks and responsibilities that the Product Owner should be doing. In this sense, it can be said that Product Owner is a role, and Product Manager is the job. While it’s true that, especially in smaller organizations and startups, the Product Manager is perfectly positioned to act as the Product Owner, in other situations and in practice it can often be useful to have a dedicated Product Manager and a separate person working in the role of Product Owner.

“Product Manager focuses on Discovery. Product Owner takes care of efficient Delivery.„

While both the Product Manager and the Product Owner have the objective to choose and define the right things for the development team to work on, the role of Product Manager focuses much more on the discovery side, while Product Owner takes care of the gritty details of the actual solution delivery. A perfect person might be able to do the work of both, but how many of us are perfect?

As this book is about product ownership, we focus here more on delivery than discovery. While it’s still extremely important that the team is iterating the solution also during the solution delivery, the prospective Product Owner should still remember that it’s very costly to do large changes of direction while implementing the product. Therefore, as the Product Owner’s responsibility is to maximize the value that the product teams generate, she must also think about discovery. Has the product concept or features that are now progressing from Product Manager to her area of responsibility been tested enough? The largest waste is generated when the product team, under guidance of the Product Owner, creates a solution that the market doesn’t want or need, or that cannot be sold because of some business or legal reason. These kinds of situations can even be career-killing mistakes, and it’s all too easy to point the finger at the Product Owner for these kinds of failures. To avoid spending expensive development team effort on work that aims to do the wrong thing, the Product Owner must cooperate with the Product Manager to study, test, and investigate the customer problem to get enough proof to make the involvement of the development team the logical next step. We will talk more about the different stages of iteration later.

One of the reasons a separate Product Owner can be useful is so that the Product Owner can be much closer to the development team or teams. One key success factor for the team is the accessibility and availability of the Product Owner to guide them during the development. Product Managers have much more tasks and wider range of responsibilities, so it’s more difficult for them to work close enough to the development teams. Having an easily accessible Product Owner nearby acts like oil in the machinery, making things roll along smoother and faster and with less friction. It also allows effective adjustment of small details during implementation sprints.

Both the Product Owner and the Product Manager need to be experts about the product and the users, especially the problems that the users of the product have. But while the Product Manager needs to have some technical insight into the way the product is developed and built, the Product Owner can have deeper knowledge about the technology and how the development works through ways and processes. In this sense, the Product Owner can be seen as taking some load off the Product Manager’s hands and making her life a bit easier. The Product Manager can then focus even more effort on the things that she will do much more than the Product Owner: testing and studying product features and ideas early on in their lifecycle; talking to wide range of customers, end users, and stakeholders; understanding details of the business model that will dictate what and how things need to get built; and definition of the product vision and long-term roadmap.

“The Product Owner exists to help the Product Manager. Cooperation is the key to repeated success.„

It’s very important that the Product Owner and the Product Manager have a good working relationship. With a good working relationship, they can agree on the division of work and responsibilities on a detailed level. Product Owners exist to help the Product Manager.

This said, knowing the details of Product Management is also recommended for people who work in the Product Owner role. An excellent book on this is Marty Cagan’s Inspired: How to Create Tech Products Customers Love3. The book details perfectly the job and the long list of tasks and responsibilities of Product Managers (and at also leaves the reader wondering how on earth all those tasks can be done by one person). People working in a Product Owner role should read the book with the mindset of choosing the things that they can help the Product Manager do. As with every large and complex job, if the Product Owner and Product Manager have a good working relationship and if they’re able to divide the work and responsibilities effectively, they can achieve more and better results than just trusting a single, overworked, and soon-to-be burnt-out Product Manager to do the job.

This book and Mr. Cagan’s book complement each other. Where Mr. Cagan’s book describes well the tasks, the content, and the what of Product Management and as a subset of it, Own It: 8 Simple Secrets for Product Owner Success goes beyond the what, and describes the ways of working and the how that lead to repeated success in the Product Owner role.

What About Other Managers?

Scrum itself defines only three roles – The Product Owner, The Scrum Master, and the development team. However, in addition to the already discussed Product Manager, typical organizations have also other types of managers surrounding the R&D department and working with them:

R&D Managers

Project Managers

Quality Assurance Managers / Testing Managers

How does the Product Owner (PO) role compare to these management positions? The first difference is that the PO isn’t a line management role. Product Owners don’t have subordinates. In fact, having subordinates is one of the common mistakes that we will talk about later.

While pure Scrum doesn’t have testers, Testing Managers, or a QA Managers, it’s still quite common to see these titles around development teams. This is fine; Scrum is a guideline more than a rigid set of rules. Organizations will find what works best for them. Still, the original spirit of a Scrum Product Owner is that she is ultimately the person who has decision power on the backlog items and responsibility for having the items clear and ready for the development team to consume. This responsibility over the backlog items and their priority is the core of Product Ownership. The Product Owner may delegate error screening to a QA Manager or an Error Manager, and she may delegate the writing of user stories to suitable persons, but she is still ultimately responsible.

The Challenge of Product Ownership

With an efficient and successful Product Owner, the team always works on the most important thing and is sure that the thing is also specified to necessary detail. The work is productive, fun, and the team is able to get a sense of accomplishment. As we see in the 8 Principles, a successful Product Owner also keeps the team informed, motivated, and continuously improving, allowing the team to learn and grow as well as achieve.

The role of the Product Owner is challenging, but it’s also very rewarding. The required mindset and skills of a successful Product Owner are now compacted in this book into a set of concrete principles and the success factors that will help the reader to understand the role, how to succeed in it, and where to improve her own skills and capabilities.

3 Marty Cagan: Inspired: How to Create Tech Products Customers Love https://www.amazon.com/INSPIRED-Create-Tech-Products-Customers-ebook/dp/B077NRB36N

The Routines