Products and features in an agile setting are meant to be fluid. Not like dirty dishwater with tiny bits and pieces swirling around... (because ewww). More like a lava lamp: steadily, visibly evolving. But what differentiates software's evolution from that of dorm room novelty lamps is strategy. And that's where product managers come in.
One of the exciting things I get to do as part of being a product manager for Confluence, Atlassian's wiki software, is talk to a lot of customers. I hear about what works for them and the challenges teams face as they journey on their mission to build great products.
One of the obstacles that often comes up is the tension teams face around requirements. What's the best way to manage them? What does the PRD (product requirements document) look like for agile teams? Does it still exist? These concerns are understandable, but if you get too wrapped around your axle thinking about documentation, you'll miss a much larger and more important point:
Ok: almost any means. I definitely don't recommend doing anything illegal. Or creepy. Anyway...
What does defining customer problems look like in an agile world? The agile manifesto reminds us that we don’t always have to do it the “traditional” way. As product managers, we should be doing whatever is required to tell the story of the customer. Try different things: experiment, explore, then do what works best for you and your team in the context that you might be working in. What do I mean by this?
- If it means you can have several discussions and sketch something on a bit of paper – then do it.
- What if you could get everyone (including the customer) in a room and do a user story mapping exercise? If that communicates the problems well, then you don’t need to go much further.
- Or what if you can visit the customer and watch them use your product in context? Could you get your engineers and designers to sit next to the customer to listen to and observe their problems?
- Instrumenting your product with analytics hooks give you aggregate, concrete data about how customers as a whole are using your product.
- Another option would be to grab the product triad (a product manager, engineer and a designer) for a quick stand-up to sketch, discuss and make some quick decisions on the spot.
- Need to explore some more? Try running a workshop where you gather key stakeholders and do lots and lots of whiteboarding or even paper prototyping to dive deep into understanding the problems you are trying to solve and how you could solve those problems.
You get the idea. In the past, product management and requirements documentation have been almost synonymous. And no wonder! Writing 20-, 50-, even 100-page PRDs will unavoidably dominate your 9-to-5. But in the agile world, it’s important that we consider writing a requirements document just one of many ways we can help define and communicate customer problems. (In fact, I try to avoid writing requirements documents. If we’re breaking down user stories into small, digestible descriptions of user scenarios and problems, we typically want to be raising them straight into JIRA Software, our issue tracker.)
Keep reading in this section for tips on customer interviews, light-weight approaches to defining and sharing requirements, and more. See you on the next page!