As I have been writing about over the past few weeks, there are a number of key responsibilities that strong product owners carry.  I’ve talked about communicating with the product manager who provides vital information from the market.  I’ve talked about creating user stories as the best way to capture the reasons why we are building out the functionality that we develop.  And last time I wrote about tending the product backlog to ensure that the right issues are being captured and worked on by the team and that no one is distracted by extraneous issues.

Today I want to talk about the next on my ‘top ten’ list of product owner responsibilities: supplying subject matter expertise to the development team.  When coders, testers, and designers have a question about what a user would expect or need from a particular part of the application, they need to know where to get that information.  The product owner serves that role by providing subject matter expertise.  By the same token, when the product manager needs to know the details about exactly what is functioning in the product and what is being worked on next, again the product owner is responsible for providing that information.  This is a key part of being on the bridge: when information is needed the team needs to know who to call with their questions (just like this: http://www.youtube.com/watch?v=KvkKX035484).

One of the first jobs of the subject matter expert is to know when you don’t know the answer to a question.  If a member of the development team asks about some specific item of design or functionality and you don’t know the answer, the worst thing you can do as a product owner is to make something up.  Agile development happens quickly and iteratively, which means that wrong answers or incorrect pathways can get coded fast with new things built on top of them.  Instead it is much better to say, ‘I don’t know but I will find out,’ and then take a few hours or a day to get the right answer.  This is far preferable to stating your opinion as if it were market-tested fact and stating something that you think might be right as if you were sure it was exact.  Providing poor subject matter expertise undermines the trust that is vital between the product owner and the rest of the team.  So when you don’t know the answer, make a point of learning whom to ask in order to get the answer: an internal expert, the product manager, a particular client, or another resource.

When it comes to providing expert knowledge, the specialty of the product manager is the market; her role is to ask the market what people need – solutions to pervasive problems that people will pay for.  She then funnels this information back to the product owner and the wider development team, who in turn use this data to create user stories.  The effective project manager is regularly engaging with the market to ensure that the products being built will satisfy clearly identified market needs.

With this market knowledge in hand, the development team works to design and build products that will thrill the target market.  During this process, the team will regularly have in depth questions about business rules and use cases: What is the expected result of this process or what are the situations in which a user would want to accomplish this task?  Traditional waterfall methods of software development try to anticipate and answer all of these questions in advance through requirements documentation.  The Agile development methodology handles these questions as they arise, relying on an engaged product owner to have or to research these answers when the development team encounters these issues.

This is an important difference between Agile approaches to software development and more traditional waterfall methodologies.  In the document-heavy traditional model, all ‘subject matter expertise’ is supposedly condensed into requirements documents that provide all of the relevant information the team will need to design, build, and test the product.  Agile approaches on the other hand acknowledge that static documents are no substitute for the engaged knowledge of the product owner.  Questions are addressed as they arise in the development process; some of these questions might have been anticipated but others will not have been – and in either case the opportunity for the team to interact with the product owner will ensure that the coders, designers, and testers get the most applicable answers possible.  Traditional methodologies assume that the answers can be written down ahead of time; Agile teams know that is impossible and instead they expect an engaged product owner to help the team learn when the subject matter expertise is most pertinent.

In my role as a product owner in a financial software company, I regularly answer questions about the correct inputs for certain calculations, the underlying accounting or reporting logic behind certain outputs, and the expectations that specific client groups will have when using our products.  I need to know enough of the math and finance involved in our products to provide the expertise our development team needs – and I need to know who else to ask when I get questions that I cannot answer myself.  Standing on the bridge between the market and our development team, part of my job is to provide the subject matter expertise that our designers, coders, and testers need in a timely way so that the development process does not get caught in a bottleneck.  Of course, in truth it’s not that simple.