User stories (with links to prototypes).Backlog – what are the functional requirements?.Scope / shaping – what does the first iteration look like?.Context – what are you building? Why? What does success look like?.Product requirements documents can comprise of a few key elements, each drawn from specific phases of the product creation process: But that doesn’t mean that your functional requirements documents won’t acknowledge – and link to – your wider strategy, too. For the purpose of this post, we’re going to focus on mainly functional requirements, assuming that your product strategy and roadmap are agreed. It’s helpful to think of your requirements as contextual vs. Prototypes – designs that have been agreed that can be referenced in user stories.User stories – specific functional requirements that have been agreed.Feature scoping – what might the first iteration look like?.Product strategy and roadmapping – what have we decided to build / why?.Vision – who are we? What are we here to achieve?.Requirements, therefore, are usually the domain of product managers and product designers. The PMs role is to define the ‘what’ and the ‘why’ of what it is your team is going to build. But requirements actually start with your product vision, strategy and roadmap. And sure, user stories are an important part of the picture. When you first think of requirements, you probably think of user stories. What do we even mean by requirements anyway? Let’s explore some of the ways you can find the right style for product requirements that works for you and your business.
PRODUCT HUNT PRD PLUS
And new modern tools plus a shift to remote-first working have kickstarted a renaissance in documentation. Teams shouldn’t rely unnecessarily on PRDs and the idea that the product manager is the sole person who sits down and writes lengthy documents to feed the engineering team with is certainly not the way many modern product companies operate.īut, having said that, there is a healthy balance to be found between the ‘zero requirements go with the flow’ attitude and the JR Tolkien’s Lord of the Requirements approach. And there’s some element of truth in that. More recently, it’s been seen as cool and trendy to not have too many product requirements PRDs are sometimes perceived as staid, old fashioned and corporate. Team members can disengage from the scoping process entirely or use the requirements documents to rationalise why something was built a certain way when instinctively it doesn’t feel right (‘well it wasn’t on the ticket so it’s not done’). The downsides of product requirements documentationĪn overreliance on highly detailed PRDs can create an unhealthy culture where team members become accustomed to outsourcing their thinking. The FB PM responded: I haven’t written a PRD in 4 years. But fast forward just a few months and I quickly realised that extensive, detailed product requirements aren’t necessarily always a good idea.Ģ/ An incoming PMs asked: is there a standard PRD template we use here at FB? Being a relatively new PM at the time, I was actually impressed at the level of detail he’d included. A single feature specification could be pages and pages long. It included the smallest details about what should happen when something was clicked and a bunch of different error states for each component. I was completely blown away when he showed me the level of detail he included in his user stories. I remember back in 2013, when I had recently joined a startup, I was working quite closely with a former Microsoft PM who had just joined the startup too. A decade or so ago, if you were starting out in product management, one of your key responsibilities would have been ‘product requirements documentation’ (PRDs).
0 kommentar(er)
