I wrote last time about the key role of strong communication between product owners and product managers. As I continue with the second of my ‘top ten responsibilities of product owners’ I want to focus on telling stories. Great product owners translate the market knowledge gathered by product managers into concise stories that developers can turn into requirements.

From my experience, this is a key place where the Agile software development methodology differs from more traditional ‘waterfall’ approaches. In the traditional model, business analysts deliver specification documents to coders outlining the feature set requirements for a product. These specs tell the developers what the software needs to do and how it needs to look. Subsequent conversations between the business analyst (BA) and the coder as she writes up her functional specs (assuming there are any such conversations) often involve the BA saying things like, “I need a button that will take me to the next step in the workflow,” or “I want the page to have this set of information laid out in the form that I put in the document.”

There are at least three problems with this approach to creating software. First of all, what I want or I need from the software as a business analyst is largely irrelevant; I am not going to buy the software and I am not (in almost every case) the primary user. The focus should be on the people who will actually pay for and utilize the product and what they want or need from it. Second, this approach minimizes the opportunity for effective collaboration in the development process. I tell the coders what to make through my specs and they build what I told them to build (or at least they build what they think I told them to build). Finally, this method for developing software never provides any context or explanation for the required feature set. The business specifications document (and the subsequent functional specs and design specs) simply lay out the required features and how each one is expected to work without explaining the reasons behind these requirements.

User stories in an Agile environment take a completely different approach. Like all good stories, user stories begin with people – in this case the people who will actually use the product as opposed to the people who will be building it. User stories focus on the ‘why’ rather than the ‘what’ of the product. Why will the clients use the product, what problem are they seeking to solve or what benefit are they trying to achieve? Users don’t need features they need solutions, so focusing on real people and the real market problems they encounter in their business puts the emphasis of product development in the right place. Software users don’t need a button to push; they want to analyze a set of data. They don’t need highlighted grid rows or bold check boxes; they want the ability to focus easily on the most important information for the tasks at hand.

As I have mentioned before, the folks at Pragmatic Marketing have some great material about this aspect of product ownership (check it out at PragmaticMarketing.com); their insights have shaped some of my own thinking on this topic. Their discussions on requirements that work talk about three key features of good user stories:

1. The stories focus on a persona. As a product feature is planned, designed, and developed, it is crucial to keep in mind the person who will be using this feature. Market intelligence gathered by the product manager helps to define the different personas in a given market segment and to identify the pervasive problems or desires that these people face with enough frequency and urgency that they are willing to pay for a good solution. An effective user story highlights the person that a particular feature is designed to delight so that the focus in the development and testing phase can be on what that user will experience from this new feature.

2. User stories focus on a central problem or benefit. When developing a new product or an enhanced feature, user stories ask what problem is being solved or what benefit is being offered to the user. Features are not added to a product because the business analyst likes them, because the developer thinks they are cool, or because the designer likes how they look on the page; new features are prioritized for development because they will address a pervasive market need that prospects or clients will pay us to help them resolve. User stories focus on what to solve rather than on how to solve it, and so they outline the use scenario rather than design requirements for a feature.

3. User stories set the context for a feature request. How often does the user encounter the problem described? What else will the client be trying to do when they step into the workflow we are designing? Under what conditions will the user want to access this feature or perform this task? Rather than providing developers with the detailed specs for a feature, user stories spell out the context for the problem being solved or benefit being offered and allow the developers to create the best product they can to meet that identified market need. The stories focus more on information and less on instruction, trusting that creative developers and designers with the right user stories will do a better job creating solutions than a business analyst can do on her own in a product spec.

Part of what allows the Agile development methodology to be collaborative is that designers, coders, and testers are presented with the stories of real users facing real problems in the context of their daily work and then allowed the freedom to come up with creative solutions. User stories are designed to be simple and lightweight (as opposed to the heavy and complex specifications documents of more traditional software approaches); their goal is to promote collaborative conversations among the development team as the product owner users these stories to bridge the gap between clients and engineers.

As I have said before in an earlier post on user stories (Clear Communication is Crucial), this is not something I am very good at. I like stories – listening to them, watching them in movies, reading them, telling them – but I am not very good at creating user stories as a product owner. It’s not that I love the details of feature specs – in fact I prefer to focus on the high level needs of clients and leave the details for the designers, coders, and testers to worry about. Instead I think the problem is that I think of myself as the user and so I focus on what I want from the product. While knowing a product and its capabilities intimately and putting myself into the mind of the user can be a good thing, in this instance I think it gets in the way of my crafting good user stories. My natural bent is to think about feature requirements and implementation suggestions and I need to push myself to think in terms of user stories instead.

As interesting as I find the ‘how’ questions, as a product owner I need to focus on the who, what, why and when of a good story instead. The creative and collaborative conversations among product owners, designers, and developers provide the best format for digging into feature requirements. The best thing I can bring to these discussions as the bridge connecting the client-facing world of software users with the development world of engineers is solid user stories that lay out the persona, the problem or benefit, the business context, and the impact of addressing the issue. That’s how I can spark productive conversations that will help produce outstanding products that delight our customers. Of course, in truth it’s not that simple.

Post-script: After finishing this posting I received a link to a great article from a colleague that hits on many of the same points. Here is the link; I highly recommend reading this other article as a companion piece to my posting: http://bit.ly/qsdeuW