This was originally posted by me back in July of 2012 as part of my earliest series of blogs on the role of Product Owner. Several of these posts used elements of Monty Python’s Holy Grail as their launch pad. Though much has evolved in my thinking about Agile software development these early ideas still ring true and so I am sharing them again this summer as part of commemorating 5 years of blogging. Enjoy.

I wrote earlier that one of the key ways to think about the role of product owners is to say that we stand on a bridge connecting the voice of the market with the world of the developers.  My goal is not to serve as a barrier between the business side and the technology side; instead my job is to facilitate and encourage strong communication among all of the members of the product team.

Even though I don’t guard the bridge, one well-known bridge guard poses three key questions that I think product owners have to raise to deepen the communication among product team members.  With apologies to Monty Python, allow me to frame these three questions (see http://www.youtube.com/watch?v=pWS8Mg-JWSg for the original):

1. What is your name? Before a question can get a good answer, we have to know who is asking it.  Does the issue being raised come from sales (‘how do we best describe this new feature?’), from testers (‘what would the user expect to happen in this scenario?’), from prospective clients (‘how can I use this tool in my daily job?’).  Who are we trying to help or for whom are we trying to solve a problem?  Marty Cagan of the Silicon Valley Product Group calls this identifying the target persona (http://www.svpg.com/personas-for-product-management/). The same question (for example, ‘can your product do this?’) may get one answer when posed by testers (‘No it can’t do that so you don’t need to build test cases for that scenario’), a different answer when poses by sales (‘We didn’t design it to do that so focus on how it solves the key problems we did focus on’), and a third answer when raised by prospective clients (‘Right now it cannot handle that, but if that is a crucial feature for you we can talk about where it fits in our future development plans).  To foster good communication an effective product owner must start by asking who is raising the question.
2. What is your quest? The second question a good product owner asks is what is the most important aspect of any request.  Everyone wants to find the ‘holy grail’ – a lightning fast, perfectly accurate, entirely intuitive product that costs me virtually nothing while doing exactly what I want it to do.  In reality such products are about as common as gold and jewel encrusted wine goblets were for first century Jewish carpenters and fishermen.  When enhancing an existing product or designing a new one, product owners help both the business and the technology sides to focus on the most important features and functions, prioritizing what gets worked on when and making sure that everyone understands and agrees on the trades-offs involved.
3. Knowing what problem we are trying to solve and for whom we are trying to solve it addresses the first and easiest of the three questions that product owners raise. The third question in trickier.  Some product owners and product teams get bogged down in superficial and subjective questions that rely more on opinion than on real market data (What is your favorite color?).  Others get side-tracked in the details of more esoteric issues like exactly how to solve a problem rather than allowing engineers to answer the how questions (What is the capital of Assyria?).  After identifying the who and the what with our first two questions, good product owners want to ask open-ended questions that actually prompt more discussion (What is the air speed of an unladen swallow?  What do you mean an African or a European swallow?).  Asking good questions helps the entire team grapple with the best business and technical solutions, encouraging everyone to work together to find creative and compelling answers.

Hopefully as a product owner I am not simply a troll restricting access between those on the business and the development side of a product.  Instead if I do my job well I will ask (at least) three good questions that help the product team understand who we are developing a product for, what the most important aspects of that solution will be, and what the best options are for pursuing that solution.  Summarized like that it might sound easy, but in truth it’s not that simple.