Insights for product managers from a Scrum Master

Scrum is a frequently used approach for software projects and many other types of projects that would benefit from agility, including physical products. While Scrum is common, there are still many issues organizations encounter using Scrum. To understand how to overcome them, you would want to hear from a real master, and that is Fred Fowler, one of only 50 individuals in the United States who holds the prestigious Professional Scrum Master Level III certification. Fred has been developing software in Silicon Valley for more than 35 years. He tackles many of the issues he has encountered in his book Advanced Scrum Case Studies: Real-World Situations and How to Address Them.

Summary of some concepts discussed for product managers
[3:03] What attracted you to Scrum and becoming a Scrum practitioner?

It’s hard to pinpoint the actual moment. I’ve been developing software forever, and for a long time I made my living working with people who didn’t understand technology very well but understood business. By understanding their needs, I was able to craft solutions that fit their needs.

Scrum is about identifying needs and organizing people to fill those needs in a way that can be measured. I can’t emphasize enough how important measurement is, because unless you’re measuring, you have no idea whether things are getting better or worse. One of the most powerful aspects of the Scrum framework is its emphasis on measuring things—in product development, measuring the value of the product.

In the world of software, many software practitioners don’t focus on measuring the value of their products. They measure the effort users put in but not the value users get out. It’s very important to measure the right stuff.


[6:18] What metrics should product teams measure?

Measuring the productivity of individual developers is impossible and a waste of time. Almost all the metrics I’ve heard about are just measurements of effort. There’s no point in measuring effort because you’re not finding out whether that effort is producing value. The only thing that makes sense to measure is the value of the product.

A product owner or product manager is the person who is the investor in the world of Scrum. The product backlog is a list of needs to be filled. It’s the product owner’s responsibility to figure out which needs are valuable to work on now. There’s a negotiation between the product owner and the developers to reach an agreement about what is going to be produced by the end of a fixed period of time called a sprint.

The developers figure out whether the product is possible and the product owner figures out whether it’s valuable. The product owner invests the time of the team to develop valuable results.

In software, people get focused on technology and measure effort because it’s easy, but you need to figure out whether you’re developing something that is worth more than the cost you’re putting into it.

[9:38] How do you measure value?

The product owner needs to use the tools of product management to put a gauge on the value. The customer needs to give feedback. In the Scrum framework, during the sprint review, you look at the state of the product at the end of the sprint and have people who want to buy it in the room reacting. They give guidance to the product owner, who builds the feedback into the Scrum cycle. Ideally, have the customers heavily involved. If you have a single customer, that’s simple. If you have a mass market, you need focus groups or test markets.

[11:52] How are customers used to provide feedback and what are some of the decision criteria for how they’re part of the project?

There’s only one way to measure the product’s value: Sell it. Measure value by having people put their money where their mouth is. In the world of Lean, you deliver value in bit-sized pieces—minimum viable products. Get something into customers’ hands as soon as possible and find out what they think about its value by asking them to pay for it.

There are four ways to increase value:

• Increase sales and revenue. It’s easy to calculate the value. If you sell 1 million copies of a smartphone game for $1.99 each, the value is $1.99 million. If it cost you half a million to make, that’s a great investment. If it cost you $3 million to make, that’s not a great investment.
  
• Decrease cost. If you make a million widgets a year and can save 50¢ on each one by improving it, the value is $500,000.
  
• Decrease risk. This is more complicated to measure. When I was a CIO, we had our headquarters at the end of a long fiber optic cable from a major city. About once a year, someone with a backhoe dug up the cable and cut us off for a day. We made $1 million per day, so that was a loss of $1 million per year. For $50,000, I moved the computers to a safe location and saved $1 million per year.
  
• Improve opportunity. If you’re in a competitive bidding situation and on average win one out of five bids, you could make a change to win two out of five bids. You can calculate the value if you know the value of the bids to guide you in how much to spend.
  

Don’t spend $1 million to save $100,000. Do spend $100,000 to save $1 million.

[16:59] Have you seen issues with a product owner not properly representing the customer or having the customer involved too much? How do you make sure the customer is properly involved in the process?

The Scrum framework is about allocating responsibility for making decisions to people who are capable of making those decisions and following through. The product owner needs to be a business person who understands what the customer thinks is valuable and can make rational decisions about how to address the customer’s idea of value. The developers need to be people who are capable of producing that value.

In Scrum, we talk about cross-functionality and self-organizational principles. A team is cross-functional if it has the capability to produce the product without getting any outside help. That’s very important in Scrum. If a team cannot do everything to create the value the product owner identifies, it has an excuse for not producing. The people who get authority are the ones capable of carrying it out, and if they can’t because they don’t have the right people or skills, they shouldn’t be making decisions.

Just as important is self-management. Teams have to make their own decisions about how to get the product created. People don’t want to do that. Developers say, just tell me what to do and I’ll do my best.  They’re basically saying, I’ll try, but I don’t guarantee anything, and if it’s wrong it’s your fault. Teams have to make their own decisions so they can’t point fingers at anybody else.

[20:46] Where does the product manager role fit in?

The word manager is dangerous in a Scrum context because a manager is usually somebody who’s held accountable for results. In Scrum, the development team needs to be accountable for producing results. Developers love to have managers because they can avoid responsibility. Being a product manager in that context is a difficult, thankless job.

The product manager has a toolbox to figure out what the market wants. The product owner uses those tools and poses challenges for the development team. The product owner doesn’t tell them what to do, just what would be valuable.

At the sprint planning meeting, the product owner and developers have a negotiation. The product owner has a list of items with the most valuable at the the top. The product owner says, “I want everything done.” The developers say, “That’s crazy. We can’t do it all.” And they go back and forth until they reach an agreement on what the developers can do and shake hands. The developers have agreed with no one holding a gun to their head that they will deliver those items, and the product owner has reasonable, valid expectations that at the end of a sprint, the product owner will see the product with those items added. The developers have to take responsibility because they said they would get it done. These cross-functional teams are highly accountable.

The product owner’s role is to identify the value that can be produced and be accountable for it. The product owner is an investor. You measure an investor’s success by looking at the return on investment. You measure the product owner’s success by looking at the value of the product compared to the cost of developing it.

[25:07] How do roadmaps work with Scrum in product management?

I’ve dealt with many roadmap issues because roadmaps tend to be made by C-level people and committees making a calendar for the whole year about what they want when. The problem is none of them is actually doing the work. An old joke says nothing is impossible if you don’t have to do it yourself.

When a manager says, “I don’t care how you do it. Get it done,” it leads to disaster because people under pressure will make it look like they got it done, but actually they will not have gotten it done. They’ll take shortcuts and kludges to make it appear they met the deadline.

Action Guide: Put the information Fred shared into action now. Click here to download the Action Guide.

Useful links:

• Check out Advanced Scrum Case Studies on Amazon
  
• Visit SiliconValleyScrum.com
  
• Connect with Fred on Linkedin
  

Innovation Quote

“I will teach your people to say ‘No.’  If they can’t say ‘No,’ then when they say ‘Yes’ it has no meaning.” – Fred Fowler 

Thanks!

Thank you for taking the journey to product mastery and learning with me from the successes and failures of product innovators, managers, and developers. If you enjoyed the discussion, help out a fellow product manager by sharing it using the social media buttons you see below.