Ron Jeffries recently posted about the need for a Product Champion, someone who knows the customer marketplace, who can be accountable for maximizing success. He refers to the Scrum Product Owner and XP Customer as possible implementations of the Product Champion. He mentions that in his latest book The Nature of Software Development he deliberately chose the term Product Champion and that the intent behind the name is that there is more to the role than is normally attributed in Scrum teams.
He introduces the idealized product effort as:
We might imagine an ideal product situation, where a group of equals band together. They have a product idea and they collaborate actively to create it. They have all the skills they need, they work together as smoothly as the Flying Karamazov Brothers, passing ideas and product bits back and forth, weaving a beautiful product as they go.
He then says that the reality is more likely to be complex and messy,
In most product efforts, we are likely to have issues like these:
- Some person or organization is funding us.
- We have a finite budget in time and money.
- There are key stakeholders who demand control, or the illusion of it.
- We do not all know the market equally well.
- We do not all know the technology equally well.
- We are not all equally good designers.
- Some of us just want a clear picture of what to do.
- Some of us want to figure out a better thing to do.
- … it goes on and on.
He makes the point that the Product Champion is accountable for maximizing the success of the product and that they need to be empowered and knowledgeable. The Product Champion also doesn’t need to have all the skills and be expert in all the details of building the product.
The Champion is probably not expert in all the details of building a successful product. If it’s an animated movie, she doesn’t know all there is to know about story-boarding, tweening, character development, story-telling, dialog, and all the other things that make up a movie. If it’s a software product, she doesn’t know all the UX, the database, the coding, the testing, and all the creative work that goes into making a delightful product.
What she has is a team, and access to the world of people who may want the product.
He continues to describe how the Product Champion role complements Scrum and helps make it great.
Contrasting the way “Backlog Refinement” is perceived in many organisations with the way a real Product Champion behaves he says
It’s perfectly good Scrum – in fact it’s great Scrum – if the Champion brings in problems and the Dev Team solves the problems. The more flexibility the Champion has in her question, the more power the Team can bring to bear. A conversation takes place, some stories get created, the testing Dev Team members propose a few Executable Acceptance Checks, and the Sprint Goal becomes “Solve this problem.”
He then discusses why many Scrum teams don’t get this ideal situation and challenges them to use Scrum, XP or whatever “Agile” approach they use to influence the organisation and nurture great Product Champions:
- Learn to build a product increment every two weeks. Use our Scrum Sprint Review to show the product to our Produce Owner (Champion-in-training), and to all the stakeholders we can find.
- Join actively into Backlog Refinement sessions. Ask questions about the problems behind the stories if stories are too specific. Whenever possible – and it always is – offer better ideas for how to solve the problems.
- Ask questions about what prospects and users said. Ask to talk with them. If necessary, find some of our own and talk to them. Use what we learn to help the Champion.
- Make our Product Champion a hero in the organization. Don’t worry that we won’t get credit: if we make them a hero, they’ll keep supporting us and helping us get happier.
- Use our ScrumMaster to influence the Product Champion, and the organization. That’s what they’re for. Do the same with other team members. Learn to make an elevator pitch. Use your contacts.
In a similar vein, Roman Pilcher found that many of the people who came on his Product Ownership classes were not able to actually act in that capacity. To help erstwhile product owners understand what the role actually entails he posted a Product Ownership Test which people can take to see if they are REALLY the Product Owner for their product. He summarizes one of the most important attributes of real product ownership as
To find out if you truly own your product, ask yourself: Am I empowered to disregard feedback and reject requests? Can I say no, even to powerful stakeholders? Exercising agile product ownership requires a positive answer to both questions.
