I know in the age of agile, things like product requirements docs are a bit out of favor but I still like them -- at least to help solidify the PM's thinking and facillitate some tough discussions. It's often easier to flesh out non-obvious misalignment when you walk folks through a good PRD and some nice mocks than agreeing on the strategy in abstract.
So here are some things I like to see in a PRD. You don't have to write it as a long doc, heck you can even use it as a check list but if you can't answer these questions quickly, you probably haven't thought through what you're building as much as you need to.
- Who's the customer? What do they say, do, think, and feel?
- What problem are we trying to solve? Why is it a problem?
- What does success look like (this is often best written as a "press release")?
- How does it work (best written as a few paragraph user narrative like "jane decides she wants to grow her business...")
- What are the key use cases? What use cases are out of scope for now?
- What are the key capabilities and features we'd need to build to support that (stack ranked P0-P3)?
- What are the biggest open issues (and include stake in the ground for answers)?
- What does the experience look like (low-resolution sharpie sketches).
- What are the milestones? How are we gonna avoid this becoming a never ending project?
- What are the key metrics to measure and goal against? What do we think success will look like from a metrics point of view?
Happy shipping :-)
-Tom
Comments