Product Mastery: From Good to Great Product Ownership (Geoff Watts' Agile Mastery Series)

by Geoff Watts

“Research tells you facts but it doesn’t tell you anything behind the facts,”

I’m not suggesting you surreptitiously spy on people but gathering insights into actual behavior rather than stated behavior or desired behavior can be incredibly enlightening.

with King.com, developers of mobile games such as Candy Crush Saga. They told me that they determine which products to build based on real-life user data. They fill a website with prototype games and invite their user base to play them for free. Then, rather than ask for ratings or feedback, they monitor actual usage. They track vast amounts of data about usage—the results tell them which games are the most playable, wanted, and profitable. That being said, gathering data can also be as simple as A-B testing, where you present different versions of a user interaction to 50 percent of the audience and then measure which one proves more favourable or successful.

choose to collect data on actual user behaviour, whether it is formal or informal, elaborate or simple, remember to trust what your customers say they want only to a point—you won’t know what they actually need until you see them in action.

Often, paper prototyping involves sketching out how a user may experience and interact with some functionality.

When your customer is having difficulty describing (or you are having difficulty understanding) a desired piece of functionality, a picture can truly be worth a thousand words.

When product owners make one or two bad decisions, they can overcorrect, swerving too far in the other direction, over-thinking each feature.

Although gathering data, asking questions, and observing customers is important, it is far better to develop the wrong thing quickly and get feedback than to wait around too long in an attempt to ensure that no mistakes are ever made. Great product owners know how to find the right middle ground, one with an appropriate balance of data and intuition—and a good measure of courage.

What I do recommend are what I refer to as CHILD questions, so called because they share a number of key characteristics that just so happen to spell out CHILD.

Great product owners ask questions that are curious, humble, illuminating, limitless, and direct.

People tend to think about situations from within their own paradigm. Everyone has a view of the world and a whole load of unconscious assumptions. Assumptions about what the problem is, what the available options are, which skills and knowledge currently exist, what is logical, even about what is true and factual.

Part of being well informed is understanding the product space, the market environment, and the potential purchasers, consumers, and users of their product. By balancing information gathering with the fast feedback and learning opportunities that come from using an agile process, great product owners make decisions that position their products for success.

Being well informed has another, perhaps less obvious, aspect: understanding others well enough to ask the right questions, of the right people, at the right time and knowing yourself well enough to accept and act on the answers. Great product owners create opportunities for people to find and share the breakthrough ideas that hide behind real or perceived constraints.

Product owners who are well informed in both aspects—products and people—are able to make the decisions necessary to bring the right...

One truth that DRIVEN product owners learn early on, is that agile teams operate in an environment of complexity, uncertainty and change – three factors that increase fear and stress within human beings.

A good product owner is reliable and dependable. A great product owner knows flexibility is essential for strength.

Be Strong by Being Flexible

Primal Leadership: Unleashing The Power of Emotional Intelligence, Daniel Goleman

Crucial Conversations: Tools for Talking when Stakes are High, authors Patterson, Grenny, McMillan & Switzler recommend that in difficult conversations, each person should STATE their story: Share your facts Tell your story Ask for others paths Talk tentatively Encourage testing

As the authors rightly point out in Crucial Conversations, “the only limit to how strongly you can express your opinion is your willingness to encourage others to challenge it” (134). Asking “What am I missing here?” or “What if I’m completely wrong?” brings people into the dialogue and introduces perspectives that might otherwise be missing from the conversation.

“Leaders become great, not because of their power, but because of their ability to empower others.” John Maxwell

While spending too little time with the team will inevitably introduce the risk of the development team thrashing with uncertainty or making assumptions that could prove incorrect, spending too much time with the development team can also stifle their independence and creativity. They will find it too easy to ask for an answer, which means the project loses out on the potential for proactive innovation.

Development teams often start out with a stereotype of customers who always change their minds or users who don’t know what they want. Product owners begin with the belief that developers are all looking to ‘geek out’ on new technology rather than deliver something useful. We all begin in a place of misconceptions and apprehension. Yet, to quote former American politician Henry Stimson: “The only way to make a man trustworthy is to trust him.” So trust we must.

Listen out for subtle clues in the language the team use that may indicate they view you as a customer rather than a collaborator. When the team use the word we, does that seem to include you or are you outside of that collective? Do they talk about delivering things for you or with you?

This reminds me of another joke where the CFO of a company says, “What happens if we invest in the training and development of our people and then they just leave?” To which the CIO replies, “What if we don’t invest in their training and development and they stay?!”

If you frequently need to justify your decisions or can’t make decisions in a timely manner because you don’t have the authority you need to do so, you might need to engage your own leadership in a conversation about trust. Then, use the agile development process to help address the concerns that come to light.

Good product owners write good stories. Great product owners tell great stories.

One of the biggest causes of friction between a product manager and a development team is in the interpretation of requirements. Development teams often complain of vague, ambiguous requirements while product managers often complain that development teams just don’t get it and make terrible assumptions.

Recognize, too, that your mindset and motivational strategy might be a factor in your anxiety. When we are pessimistic or cynical, there is a good chance we will think the worst is going to happen and unconsciously adopt an away from motivational strategy. When this happens we typically adopt behaviours that are very defensive and risk averse in order to protect ourselves from a bad outcome.

Awareness gives us choice. When we are more self-aware, we can choose to adopt a more helpful motivational strategy. Also, because what we choose to focus on has a large impact on what is likely to happen, adopting a towards strategy is a great way of tackling both cynicism and performance anxiety. Instead of focusing on what might go wrong, instead tell yourself what positive outcomes there could be as a result of your “performance,” not just in terms of the specific outcome, but in other ways as well; for example, self-development, self-confidence and modelling the behaviour to others.

Figure E-3. Many stories follow a similar dramatic arc.

The area just outside of our comfort zone is often referred to as the stretch zone. In the stretch zone we experience some degree of discomfort but this is the area where learning and growth is most likely to occur and where confidence may grow.

Figure E-4. Venture into the stretch zone for growth.

Good product owners represent many different parties. Great product owners know they can’t please everyone.

One way to negotiate ideas amongst a group of stakeholders is to use the technique pass the cards. This technique is sometimes called 35 or 49 because of the point scoring system used but, for simplicity, and in deference to its name in Jean Tabaka’s Collaboration Explained, I call it pass the cards.

Good Product Owners avoid bad mistakes. Great Product Owners make good mistakes quickly.

People whose perfectionism trait has become a trap often focus exclusively on end results, are unable to enjoy the journey and, as a result, lose joy in their work. Setting high standards will often lead to great achievements, but if those standards become unrealistic then dissatisfaction, and quite often burnout too, are the likely results.

In his book, Improv-ing Agile Teams: Using Constraints To Unlock Creativity, Paul Goddard discusses the power of wearing hats when trying to think or act in new ways. He explains that “hats, masks, and even costumes can help people access their ideas more readily because they help individuals feel as if they are thinking like other people.”

failure was not to be feared; failure was an acceptable outcome so long as we failed quickly, cheaply, and that we didn’t fail the same way twice. This freed us to minimise our plans and maximise our production—and to be more creative and innovative in our approach to problem solving.