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.
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 as just one of many ways we can help define and communicate customer problems.