While it may seem obvious that meeting the needs of the customer is the Prime Directive when it comes to building a software product, getting everyone in the room to agree on what exactly that means can be a whole ‘nother matter:
- The CEO wants an innovative product that addresses a clearly defined market opportunity
- End users want an experience not available anywhere else (or an awesome solution to a vexing problem), and
- The design and engineering teams want a nice, juicy problem to solve
It’s easy to imagine how the first and third of these constituents might have their own conception of what to make. Said conception might even be aligned with validated customer needs but it might just as easily have more to do with what’s cool, what a competitor is doing, a personal bias, or what either group thinks users ought to want (i.e the ‘Build It and They Will Come’ syndrome).
The Product Manager’s job is to heap a dose of reality onto those pipe dreams and focus the feature discussion on the needs of the customer. He or she does this with User Stories. You’re probably familiar with the various forms a User Story can take: from Role/Goal/Benefit, to the Five ‘W’s, to Gherkin’s Given/When/Then. Regardless of form, the primary purpose of the User Story is to facilitate a conversation about the feature, from the user’s perspective.
A good collection of stories should move the reader to put aside issues of technology or coolosity and see the problem from the user’s perspective. The dialog that ensues will help everyone clarify his or her understanding of what the user wants to do and how the system should enable them to do it. Because Agile emphasizes conversation over documentation, this is how understanding of what to build is achieved.