Curious to get folks take on the “written narrative” concept that Marty Cagan talks about in Empowered. Here’s a link to the concept on SVPG.com:
Here’s a summary from Empowered (slightly different from that blog post):
~6-page doc
Spend a few pages describing the problem you’re trying to solve, why this will be valuable for customers and for your business, strategy for solving the problem
FAQ for the remainder of the doc, esp to anticipate concerns and objectives from execs and stakeholders
The question I have is not what it is but rather when / in service of what to use it for.
E.g. possible uses:
to bolster the case for investing in product discovery around a problem / need space
to bolster the case after investing in product discovery around a problem / need space to then move forward with product development / delivery, because through the discovery process we refined our understanding of the problem / need and were able to iterate to land on a compelling solution for customers and our business
to provide details about a significant thing to be built, without product discovery, to explain how it would work
I don’t see value in #3. I think this is what Marty meant about spec. It’s not a spec.
I can see value in #2, e.g. here’s what we learned and why we should care because here’s how it makes a difference for customers based on testing.
I can see value in #1, so long as the narrative talks about the strategy for solving the problem, and not the solution itself (because that’s putting the cart before the horse).
This seems like a spin on Amazon’s Product FAQ. These FAQs are written before there is final sign off, it’s purpose is primarily around #1. It’s essentially an opportunity assessment.
I haven’t read Empowered yet, but I think I’ve used something similar in the past that I’ve called the Product Framing Document (PFD). It shouldn’t be longer than 5-6 pages. The PFD is one outcome of the research and synthesis phase of product development. I like to keep it high-level and consumable, but with enough detail to establish a common understanding across stakeholders. I’ve used it to help focus roadmap and investment discussions, and serve as a touchstone throughout the development process. It can be a starting point for creating detailed epics and user stories. I’ve seen marketing, sales, and other GtM departments use the document as input for their materials as well.
The work that I’ve usually done before writing a PFD includes:
User research and contextual inquiries
Persona analysis
Value Drivers and Problem Statements / User Goals
Market Requirements, including competitive research
Brainstormed solutions and idea generation (“how might we”)
Rough MVP definition
Low-fi wireframes
Every time I write a PFD it looks a little different depending on the scope of the project, but overall it follows the same format. I try to address all of the following topics if relevant to the project:
Definition of the market problem or opportunity that the product will address
Quantify the problem and its impact as much as possible
The vision, outcomes, personas
How we will measure success
High-level features, assumptions, and dependencies
Features, concepts, and work that is out of scope
Initial design and architecture materials, if available
Brainstormed solutions and idea generation (“how might we”)
Low-fi wireframes
What’s the rationale for including the above?
Is it mainly to help readers/stakeholders get an idea of the experience/solution, e.g. picture is worth a thousand words?
I find in early conversations that such things are enormously helpful, but I have to caveat the heck out of them, and plaster “ILLUSTRATIVE” on the slides, so people understand we still need to figure it out.
I don’t usually include those in the document itself. The first list of bullet points are usually the type of work that is done to develop the content of the PFD (the product strategy, really) but those artifacts aren’t included in the document itself. It would get too long and unreadable.
