Webinar: What makes a great Product Owner?

The theme for the month of May was Product Ownership. We had two of our agile42 coaches covering this topic, Daniel Lynn and Lothar Fischamnn. Daniel kicked off Part 1 with a video interview where he looked at what makes a great Product Owner, including how to handle a team looking for a list of tasks to complete as well as navigating those needy stakeholders. 

In Part 2, Lothar looked at why having a Product Vision is so important for a Product Owner and what we can learn from “Shark Tank”.

This culminated in a webinar on the 26th May, where Daniel and Lothar shared their thoughts and experience in a Q&A style session. The audience certainly gave them some challenging questions! 

Some of these included:

  • Do you coach/teach Product Owners to ruthlessly prioritize to drive better product/service focus?
  • There was a debate whether the Product Owner role is still required in Scrum. Any thoughts?
  • What would you say are the most important "watch-outs "or pit-falls as a Product Owner?
  • Can you be a PO across 2 teams working on multiple products or is that another role completely?

As always the hour flew by with many more discussions still to be had. This is why we have decided to launch a Lean Coffee event after each webinar where you can continue the conversation with two of our agile42 coaches. This provides an opportunity to address those remaining burning questions as well as meet like-minded people. Join our free agile42 Community to gain access to our monthly Lean Coffees as well as an array of other benefits. We hope to see you there!

If you missed out on the live session, don’t panic! We have the recording for you here - please feel free to share around with your network. 

Please do get in touch with us should you have any questions. We would love to hear from you.
Stay tuned to our social media platforms for next month's theme!

LinkedIn | Facebook | Twitter

Part 2: What makes a great Product Owner?

In Part 2 of our series on "What makes a great Product Owner?", agile42 coach Lothar Fischmann, looks at why having a Product Vision is so important for a Product Owner and what we can learn from “Shark Tank”.

You can watch the full video interview below:

Why is having a Product Vision so important for a Product Owner?

One of the first questions we ask Product Owner’s when it comes to any kind of coaching conversation is: “what is your product basically about”? And hopefully, the Product Owner is able to give us a short insight into the main characteristics of his product and be able to tell us where the journey should go. If he is able to tell it to us, he should also be able to tell it to stakeholders, users, or clients. The basic idea behind the Product Vision is that the Product Owner should be able to make an elevator pitch for instance to his company’s CEO/CIO of the idea behind this new product.

Are there any good examples of Product Visions?

There are a couple of good examples of Product Visions that are very well known. For example, JFK’s “Man on the Moon” speech or Martin Luther King who stated, “I Have a Dream”  and, of course, Steve Jobs’ vision of the iPod. So what we are seeing is that a Product Vision can also be used for organisational or social development as Martin Luther King did. A vision and a clear understanding of the product is helpful and guides people on the journey. 

We use the idea of a Product Vision also when we talk about an agile transition. For example, where there is a sponsor at the top who has an idea of how the agile organisation could look like, what the benefit of agility is and why it is important to start working in an agile way. Other good examples of Product Visions can be found within shows such as “Shark Tank”. The principle behind “Shark Tank” is quite simple. There are people who have an innovative product idea and they would like to get some capital from venture capitalists. So they pitch their product and try to convince the “Sharks” to invest in their product.

What can we learn from “Shark Tank”?

The people on “Shark Tank” are extremely motivated in selling their product to the “Sharks”. In their presentation, they will focus on the most important aspects of their product and why people would buy it. Some of them also hand the product to the “Sharks” so they can touch, smell or possibly taste it, which can be quite important for some products. 

It’s not only the presenter's work we can learn from. You could also learn something from the “Sharks”. For example, what kind of questions are these people asking? Typical questions include:

  • have you already sold some of the items or is it still an idea?”
  • have you been able to collect customer feedback?
  • what did they say and how have you been able to incorporate that?
  • what is the market looking like? Are there any kind of competitors?
  • Why should we use this approach over other competitors? (i.e. a “make or buy decision”).

You will find Product Owners who have given a thought to all these questions, who prepared themselves in front of a mirror or with friends, who thought how to present their product in a succinct way that will be well perceived by stakeholders, users, or the “Sharks”. This helps people to understand the product and to develop it. Therefore, working on a Product Vision is always a good first step on your journey.

 

Watch the recording of Lothar's webinar on "What makes a great Product Owner?".

*Click here to read Part 1 blog post* 

 

Part 1: What makes a great Product Owner?

In this interview, agile42 coach & trainer Daniel Lynn, looks at what makes a great Product Owner, including reminding the team that you're in this together and when we don't have all the solutions, it is ok to say "I don't know".

You can watch the full video interview below:

What makes a great Product Owner?

A great Product Owner always has the customer or end-user in mind. In fact, this is one of the most important things that a Product Owner brings to the Scrum Team. If you look at the Scrum Guide, most of the responsibilities of the Product Owner can actually be delegated out. There is no reason that the development team can’t add items to the backlog and help identify what priorities they should go in. Those are all things that the Product Owner is accountable for, however, can get help from other people. 

While the development team is focused on building a product increment and the Scrum Master is focused on the overall health and effectiveness of the team, the Product Owner is still thinking about the end-user.

      • What solves their needs? 
      • What are the next most important needs to solve? 
      • What are the unanswered questions that need to be resolved and brought into the team so they can make a more effective product?

So if you want to be a great Product Owner you need to always be thinking of what does the customer or end-user need and how can I connect the rest of the Scrum Team to that.

What about teams who are looking for a list of tasks they will be assigned to complete?

It is not uncommon with new Scrum Teams that the development team will just look for “what exactly am I supposed to build - give me a list of tasks”. This is normal, as this is how they have worked for many years. However, Scrum is different. In Scrum, we are trying as a whole team to tackle complex problems. Problems that often we don’t know the answer to. So as a Product Owner you need to help keep the voice of the customer in that conversation. You’re bringing the most pressing challenges to the team - not the most important solutions. So it is often valuable to remind the team, as you start backlog refinement meetings and planning sessions, the Product Owner is there as the voice of the customer to help connect and translate what is the highest priority, what is the highest value work to be focusing on.  

What about very needy stakeholders?

As a Product Owner it is not uncommon that you’re going to have stakeholders that have an idea of how something should be delivered, think that their piece of work is the most important and always wanting to know exactly what is going on and when it will be delivered. This is normal. Every Product Owner has to deal with this. So what do you do when that happens? 

As a Product Owner you need to understand the needs of the stakeholder and then devise a framework for engaging with those stakeholders and identifying what is the most valuable work. You shouldn’t try to hide this from the stakeholders. Invite them into the conversation. Often invite many stakeholders into the same conversation so they can all see how their needs align with one another. 

If you have a particular mechanism that you’re using to determine value, it’s important to share that early on. If your team is building a product that helps another team be more effective, then maybe that is one of the metrics you’re going to use to determine what is the most valuable work to do. Then when a stakeholder comes to you and says: “I want this done and here is why it’s important”, they already know the framework their value will be judged against. For those stakeholders who always want more information, there are real needs behind that. Reach out to them and understand what their needs are.

 

                • Are they using that information for planning or budget purposes? 
                • Are they using it to plan trade shows? 
                • What is it they are trying to do with that information?

And then help them succeed. Help them get the information that they need to make the decisions that they need to make.

 

Watch the recording of Daniel's webinar on "What makes a great Product Owner?".

*Click here to read Part 2 blog post* 

Prioritising with Cost of Delay

This week the “Meet the Coach” webinar series delved into the interesting topic of “Prioritising with Cost of Delay”. The presentation went really well and we had many people listening, once again. It makes us happy to see so many people returning to our webinars, with new faces joining all the time. We hope to see you all again soon! 

Whether it is for large initiatives or items on the product backlog, prioritising work is something many organisations are struggling with. Some choices will have different impacts for certain stakeholders. Often it is hard to keep things objective, since there are opinions, ego’s, status and emotions involved. Ordering by value is not always as linear as you would expect. In many cases we are comparing apples with oranges, for example how do you compare an initiative to attract new users with quality improvements?

In the webinar we looked at different aspects related to comparing items and I explained the concept of Cost of Delay and how it can be used as a prioritisation technique. Below you can find some of my suggestions from the webinar. 

 

 

 

If you missed out on the webinar, don’t worry! We have the recording available for you. Feel free to share it around with friends and colleagues. The recording of the session is available on YouTube. If there is anything we can help you with regarding this topic, feel free to contact us.

 

 

As mentioned in the webinar, if you want to learn more about Cost of Delay, or how to work with stakeholders, how to make choices and how to be a good Product Owner – join a training with us! 

The Product Owner journey starts here.

Take the first step on the journey by attending Certified Scrum Product Owner training.

In this training you will learn the theory of the Scrum Framework and work through tools to enable great Product Ownership. The CSPO course is appropriate for aspiring Product Owners, business analysts, managers, project managers, and organizational team leaders seeking a deeper understanding of the Product Owner role, and how to improve Product Ownership in their organization. 

If you are already a CSPO, take the next step and deep dive with Advanced Certified Scrum Product Owner training . All upcoming trainings can be found online. Please bare in mind that in order to receive an A-CSPO certification it’s required to hold a valid CSPO certification with Scrum Alliance and validate at least 12 months of work experience specific to the role of Product Owner (within the past five years).

We run all our trainings both remotely and in-person! If your organization would prefer a private training, we can even look at customising the training for you. Get in touch and we can discuss the best solution! 

And don’t forget about the coaching. At agile42 we do a lot of role coaching, and the support we can give your Product Owners will help their daily work. 

I have shared the slides used during the webinar below: 

 

Here you can learn more about the Business Value Game. The Business Value Game is a tool for estimating the Business Value in software development projects, it helps Product Owners and Stakeholders in sharing information related to Business Values in a relatively short time. It avoids anchoring by asking each Stakeholder to play their estimate card so that it cannot be seen by the others and then all cards are exposed at once.

Here you can order the Planning Poker Cards. Planning poker is mostly used to estimate the effort or the relative size of tasks in software development. The members of the project team come together and estimate each item in a few rounds using the planning poker cards until the team reaches consensus on the size of each item or task.

 

For more webinars and recordings, please look here!
Hope to see you in the next ones! 

 

aerial photography of people

Tips for the beginner Product Owner: How many PO?

Basically, this article is about why it is a bad idea to try to counter a dysfunctional situation by adding more people to the job.

A phenomenon that I encountered often is that companies tend to hire more Product Owners when their setup with one does not seem to work. Can the reflex to just hire more people when the existing ones are not doing what is expected from them help?

Before we take a deeper look into what can go wrong, let‘s summarize how it should be. The three main qualities of a PO are:

  1. Availability
  2. Knowledge
  3. Authority

The Product Owner needs authority. When he says something and gives information to the team, that should be valid and hold. If he cannot say anything because either he does not know or is not allowed to make a decision, this is a major dysfunction.

In order for the Product Owner to make a decision, he needs to be knowledgeable. He needs to know about the product and the product domain. He needs to understand his customers for whom he is building the product, so he needs to be in contact with them. Without knowledge, his authority will not hold and he will lose the ability to make decisions.

And finally, he needs to be available for the Team Members and Scrum Master if they have questions. As well as for the stakeholders when they bring new ideas to the table or have concerns. The best PO is of no use if he is not there to answer a question.

All these qualities enable the PO to optimize the Return on Investment, for which he is responsible. Being responsible also means (apart from the burden) being able to act or decide on one‘s own without supervision. If you are dissatisfied with the work of your PO, the first thing that you should look into is: Is your PO really empowered and can she ultimately shape the ROI? Does she have the tools, like a clear product vision and business values attached to product backlog items? Is the team stable and is she the only channel from whom the team can pull product backlog items?

Often occurring problems after a transition to Scrum is that there are still managers that give direct tasks to members of the team, overrule the decision of the PO or do not really allow him to make decisions. Often, the PO is not allowed to talk directly to customers and stakeholders, so someone else becomes the main source for information that the PO depends on. Lastly, another problem is that the PO is not solely a PO but also responsible for a multitude of other tasks, reducing his availability and focus on the product.

If one of these things is happening, it does not matter how many people are sharing the PO position, it will not get any better.

Normally, one PO can deal with one Team (5-9 developers). Under rare and complex conditions, it might be a good idea to give him a business analyst as an assistant, but at least as often, a PO might also be able to deal with two teams at once. By adding more POs to the job, you dilute the ideal „one face to the team“. If the Backlog is set up as suggested and the team is following the Scrum rules, this will work out.

So before you decide to add more people to the PO position, think about how it could help and if there are no other dysfunctions that need to be solved if your PO tells you that he is overloaded.

Conditions, where it is a good idea to put more POs on the job for one team, is when you have a lot of „disruptiveness“ of the business and have to work out different „branches“ of strategy or be prepared for quickly opening opportunities. Another one may be a highly complex outside world with many different stakeholders that you need to care for. When you should do this, keep in mind that you need a shared responsibility for the ROI and a clear distinction of who is responsible for what.

Tips and Tricks for the beginner Product Owner

Most people are afraid to fail. Shame is at the core of the fear of failure, psychologists say (see Dr. Brené Brown @TED). The problem with fearing failure, though, is that it does nothing but help you fail.

In our western culture, shame is a driver to get others to do things. By using shame and guilt as tools, we do not only burden us with an emotional baggage that is wearing us down emotionally, but we also create a lot of dysfunctions as we hide mistakes in order not to be blamed.

Transparency and courage are values shared by most of the agile approaches, Scrum in particular, the opposite of shame and guilt. We can choose to try to live our lives on our own terms: either by trying, failing and learning or by remaining in the swamp of shame and guilt and not improving. When you feel guilty and ashamed, you behave accordingly. Your mind will keep thinking about what happened and will not allow you to change anything as this would mean acceptance of the failure.

If all went well the first time we tried, we would never ever get any better. As we strive for perfection, we should embrace failures as they give us the chance to grow. Inspection and adaptation require reflection on things that could have gone better. From my experience, once people accept that they basically constantly „fail“ in the way of retrospectively not having chosen the best approach for what they wanted to achieve, they harness the incredible power of creativity and courage and gain the intrinsic motivation to do better at every future step (see Drive).

Shame is a tricky concept and a very useless one too. It has been rooted deeply in our society for maybe longer than a millennium, and that is by far too long a time. As eastern (buddhist and hindi) cultures show us, there is no need for that concept. So stop seeing yourself as a bad person because you did something wrong. Consider yourself lucky that you were given the opportunity to change your future behavior.

So accept that you could have done better, every second of your life, If you had had your current knowledge. You did the best you could, and given the situation at hand, that‘s all you could have done anyway. Wouldn’t it be awesome if we recognized a few of these „failure moments“? Wouldn’t they be an evidence that we have learned something and we can harness the power of learning to improve?

Throwing the concept of guilt and shame overboard is the first step in the direction of good agile risk management. We know that all of us could have done better constantly. So after we accept that fact, we can think about ways to make the biggest mistakes transparent.

So why should we embrace to fail fast? When diving into a new project, I am often confronted with a situation where the management fixed the time and release date, the scope of what should be released and also the quality in terms of SLAs. The first question that I ask under such conditions is: „When do you want to know how badly you are going to fail?“

While the question might be a bit confrontational, the discussion thereafter is awakening most of the time. If the „iron triangle“ (scope, time and quality) is fixed, than it is better to know as fast as possible if the plan is off or not, so that we can react and soften the damage.

As a manager, the worst thing that can happen are surprises for which expectations management is key. Agile methods are the best tool I know to get the most trustable and fast results. Worse than having bad results is having bad results late.

From my practice as a Product Owner, you need a tool to manage releases, not only Sprints. So what I do is to set up a release map and give the developers some overview about the planned high level requirements. In return, I ask them to give me a rough relative estimation about the effort of each of those requirements. Once the first requirements get broken down to little pieces, and the little pieces get estimated, I start knowing more and can do recalculations. With every completed Sprint, I gain knowledge about the progress and even in very large projects, it does not take long to get a good idea about: when it will be finished, or if we need to tighten the scope. This helps  significantly when dealing with multiple stakeholders. Particularly, conversations tend to get way more concrete when I am approached to enlarge the scope. It is easier and faster to forecast the impact of any given change.

So embrace failing fast and don’t fear to be ashamed! Every failure is a new learning opportunity if you accept it as such. Once it is there, you cannot change it anyway, but you have the chance to make the best out of it—learn something from it.

man holding incandescent bulb

Tips and Tricks for the beginning Product Owner

Envision a vision for a better PO

I want to point out that a vision is a necessity. The Product Owner is not going to do a good job without one. The product vision is not part of the Scrum framework. Nonetheless it is often mentioned in the Scrum literature as something that is a prerequisite.

In my experience, most companies lack a vision for their products. On rare occasions,  there existed a product vision, but it led a gloomy existance in a dusty drawer.

A good product vision is short, concise, broad, understandable and most important – engaging! With a good vision in place, everybody in the company will be aligned to the same goal.

Make it clear what you build, what your target audience is, what is the single uncompromiseable feature and what are other features that distinguish your product from your competitors’. Make every sentence and word matter, not longer than an abstract. The book from Geoffrey Moore “Crossing the Chasm” is a great source to learn how to write a vision statement properly.

Why is the product vision a vital tool and not just a toy for esoteric trainers? Imagine the perfect Product Owner. She has the authority to substitute the customer directly when facing the development team when a question arises. This can be accomplished if she has a very good relationship with the customer and knows his wishes, the product and the environment very well. – Even without a product vision.

Now imagine that this Product Owner has more than just one customer. She would need a split personality with a shared knowledge and understanding. And the stiuation gets even worse with three or more customers. And now keep in mind that building a product does not just mean to fulfill the customers‘ wishes. It is about building a product with many other stakeholders like development and marketing as well as juggling with internal requirements and restrictions.

The product vision is the shield for the Product Owner. Many dysfunctions in companies arise because there is no product vision. The common tragedy that follows is that many opportunistic moves undermine the product integrity. The product loses its identity. Nobody knows anymore what makes it stand out, what makes it different, marketing does not know what to advertise about the product, developers are not proud of their product anymore and stop taking care of it. In the end you have a bunch of people who try to hold it all together until there is no more money to squeeze out. The end of the product life cycle is reached. The vision is the tool to align the goals of all stakeholders and allow the Product Owner to challenge and also motivate the team.

So help yourself and the team and forge the tool you need to motivate and keep the integrity of the product instead of whining because it all falls apart.