Agree! Overly verbose PRDs aren’t much use but what I’m struggling to understand is what comes after the product brief? At some point in the development of a feature you need to get more specific than the high level details contained in a product brief, genuinely curious how and where you document that sort of detail?
The interactive prototype is ideally the next level of specificity which then gets turned into specific epics/stories/tasks etc. in partnership with you, your eng partner and your design partner.
I have used something similar during my career as a PM and I always kept it around 1 page where most of the discussion was around the wireframes (easier to show than to say). So motivation etc was written, and then a link to the wireframes and off we go.
Today I'm facing a pickle where the product design ask me not to show any mocks which makes it more difficult, but doable. You mentioned a section of what the ideal product looks like. To what degree of specifics do you recommend doing that?
Lastly, one thing I add to mine are details about testing. Do we plan to test or release to all and what the KPIs are. I find this is a hot topic which, unless I missed it, you didn't mention is in your brief.
Thanks for asking Yoav and glad you found this useful.
I find that collaborating with Product Design to show an ideal state is the most helpful. Even if that's a link out to a "vision" of the final product that you'll then build and release iteratively.
Regarding testing: yes, I didn't add because my default assumption is that we're testing most product features and improvements, but I would capture this in a section on "release plan." It doesn't necessarily have to be in there at the onset of the project, but it should be understood whether quantitative experimentation is part of the project.
I'm a big supporter of light documentation. But as you suggest, there are cascading levels of supporting material.
A minimally-functional prototype, as Adam noted, is the most powerful documentation (and testing tool) in your arsenal. But there are a lot of sticky details that won't cover when it comes time to build scalable, resilient systems.
For anything remotely complex (I do a lot of deep enterprise workflow solutions), you're going to need well-articulated requirements before engineering and QA can confidently proceed. For me, that's generally a series of documents supporting the overall brief, each approximately at the "epic" level that attempts to describe all the requirements (or "stories") relevant to that subset and provides some visuals. It's sort of a sub-brief for a specific feature of the larger product.
The important lesson I've learned over the years: start light and collaboratively build on the basic product outline over time. We break the long-term plan down into testable increments and define only what needs to be defined to go learn with users. By the end of six months, we might have a pile of supporting documentation, but no one had to sit down and read it all to get where we are now -- it's really just an artifact of our progress.
Agree! Overly verbose PRDs aren’t much use but what I’m struggling to understand is what comes after the product brief? At some point in the development of a feature you need to get more specific than the high level details contained in a product brief, genuinely curious how and where you document that sort of detail?
The interactive prototype is ideally the next level of specificity which then gets turned into specific epics/stories/tasks etc. in partnership with you, your eng partner and your design partner.
Nice, thanks!
Love this.
Thanks Sippey!
Thanks for sharing Adam.
I have used something similar during my career as a PM and I always kept it around 1 page where most of the discussion was around the wireframes (easier to show than to say). So motivation etc was written, and then a link to the wireframes and off we go.
Today I'm facing a pickle where the product design ask me not to show any mocks which makes it more difficult, but doable. You mentioned a section of what the ideal product looks like. To what degree of specifics do you recommend doing that?
Lastly, one thing I add to mine are details about testing. Do we plan to test or release to all and what the KPIs are. I find this is a hot topic which, unless I missed it, you didn't mention is in your brief.
Thanks for asking Yoav and glad you found this useful.
I find that collaborating with Product Design to show an ideal state is the most helpful. Even if that's a link out to a "vision" of the final product that you'll then build and release iteratively.
Regarding testing: yes, I didn't add because my default assumption is that we're testing most product features and improvements, but I would capture this in a section on "release plan." It doesn't necessarily have to be in there at the onset of the project, but it should be understood whether quantitative experimentation is part of the project.
Thanks.
I'm a big supporter of light documentation. But as you suggest, there are cascading levels of supporting material.
A minimally-functional prototype, as Adam noted, is the most powerful documentation (and testing tool) in your arsenal. But there are a lot of sticky details that won't cover when it comes time to build scalable, resilient systems.
For anything remotely complex (I do a lot of deep enterprise workflow solutions), you're going to need well-articulated requirements before engineering and QA can confidently proceed. For me, that's generally a series of documents supporting the overall brief, each approximately at the "epic" level that attempts to describe all the requirements (or "stories") relevant to that subset and provides some visuals. It's sort of a sub-brief for a specific feature of the larger product.
The important lesson I've learned over the years: start light and collaboratively build on the basic product outline over time. We break the long-term plan down into testable increments and define only what needs to be defined to go learn with users. By the end of six months, we might have a pile of supporting documentation, but no one had to sit down and read it all to get where we are now -- it's really just an artifact of our progress.