This post introduces the concept of Working Backward (WB) narratives and formalizes the mechanism through which a company can drive product development. The WB mechanism is a complete process designed to create a “virtuous cycle” that re-enforces and improves itself as the team participates in it.

“Put the customer first, have a plan, create a shared mission, get early victories, remove process, and make it fun.” – tig

A WB narrative is a form of written memo that articulates the customer experience of a proposed product, feature, or program concept. A great WB doc answers all the questions required for stakeholders to understand the deliverable (product, feature, or program). WB docs are the primary tool in our broader mechanism for “always working backwards from the customer.” Working backwards from the customer enables us to have clarity of thought on what we want to create, up front, so we can then figure out what needs to be invented to make the customer experience true.  

 “No battle was ever won according to plan, but no battle was ever won without one.”  – Dwight D. Eisenhower

Standardized tools for creating plans make organizations more effective because standardization drives consistency and reduces the mental burden for everyone involved. Plans always start with the customer and work backwards. Plans always have the 5Ps: Purpose, Principles, Priorities, People, and the Plan. WB docs are a standardized tool for the initial forming of plans. A great WB doc creates clarity of thought around the purpose, principles, and priorities for the plan. It enables a broader team (People) to invent and execute. It asserts an ambition about when something will happen (the end-date of the Plan).

Creation and Review Process

The process of creating a WB doc is iterative and involves all disciplines but is often led by a Product Manager. When the final WB narrative review is held, and everyone is done reading, everyone will have clarity on the product, feature, or program we hope to build.

We can be as flexible as needed on the steps involved in creating and reviewing WB docs. But the process typically looks like this:

1. Someone has an idea for a product, feature, or program. If there’s a PM that is already responsible for the domain the idea is related to, the PM is asked to add the idea to their “idea backlog”. If the PM can’t prioritize diving deep into the idea, he/she owns informing the person who thought of the idea of this fact. At some point there’s enough interest, passion, or direction around the idea that someone (could be anyone, but is often a PM) takes on ownership of writing the document. We’ll call that person the WB owner.
2. The WB owner creates a new document in Word using the WB Narrative template and writes a rough draft of the WB artifact to get the juices flowing. The owner then gets other stakeholders and interested parties to read the doc and provide ideas/input. The owner iterates until the doc feels complete and ready for the first review (this is a judgement call).
3. The owner schedules a WB doc review, inviting relevant stakeholders. This calendar entry is the forcing function for the owner to get the doc in shape in time.
4. The owner drives the WB doc review meeting, listening carefully to questions asked and input given.
5. The owner then incorporates the feedback, simplifying the document.
6. Repeat steps 3-5 until the stakeholders feel they all have clarity of thought and the idea has been boiled down to its most simple form. When they do, the process is complete. 
7. Archive the doc somewhere.

“The doc is complete when nothing more can be removed from it.” – anon

Document Structure

A great WB document steps the reader through a proposed customer experience and then answers all the obvious (and not so obvious) questions readers may have about the idea. To this end there are typically five sections in a WB doc:

1. The introduction – A few terse paragraphs that allow the review meeting to be effectively run with the owner saying, simply, “ok, let’s read”.
2. The working backwards artifact – This is the prose that describes the desired customer experience we will work backwards from.
3. A set of frequently asked questions (FAQ) [optional, see below] – This is a numbered set of questions, with answers.
4. Appendices [optional, see below] – Supporting data required to understand the concept. These are printed with the main document. These appendices are not counted against the six-page limit, but authors should plan on readers taking the time to read them during the review.
5. Back-pocket Appendices [optional, see below] – Supporting data that might clarify the concept. These are printed by the owner, but not handed out unless needed during discussion. 

Each of these five sections are described in more detail below.

Document Introduction

The best narratives are self-contained: the reader should not need someone to explain the goal of the document before (or after) reading it. The introduction is the narrative author’s tool for ensuring review meetings can start with a simple “ok, let’s read and then we’ll discuss.” The best introductions are terse. They say no more than necessary to give the reader the context required to read the rest of the document.

Less-effective introductions are duplicative of content further on in the doc.

It is sometimes useful to provide context by presenting customer, business, technology, or organizational data in the introduction. However, doing so should be a highly-considered decision because it might mean the WB artifact (described below) is not clear or complete enough. In other words, the author should ask herself when writing the introduction: “Am I using the introduction as a cheat for not having to do the hard work of making the working backwards artifact truly stand alone?”

The introduction should clearly articulate the stage the document is in. For example, “This is the first draft that’s been reviewed by a broad audience. We are looking for broad, foundational input today.” Or, “This is an iteration of the idea that we reviewed with you last week. Based on the last review we’ve pivoted this idea to focus more on end-customers vs. dealer-customers.”

Working Backward Artifacts

The WB artifact is the centerpiece of a WB narrative. It is the most critical part of the WB document and the thing the team should spend the most time crafting and iterating on. The goal of the artifact is to present an ultra-clear picture of the deliverable’s customer experience in as concise a form as possible.

Examples of WB artifacts include a press-release (PR), a product review, a blog post, and a set of release notes. The most common form of artifact is a “working backwards press release”. The PR should be written as though it is the REAL press release we send out when the product/feature/whatever is released. Over time we can experiment with other forms, but as the organization starts to learn how to use the WB mechanism it is recommended this artifact be a PR.[1]

The WB artifact should be, in priority order, complete, clear, and concise.

• Complete – After reading, will the reader have a complete picture of the important aspects of the product? It should clarify who the customer is, how the customer will learn about the product, how they will acquire it, how much it will cost, and, of course, how it works for the customer.
• Clear – If readers of the WB artifact say “I don’t understand this” then the writer has failed to make it clear.
• Concise – The best product ideas are simple. If the author can’t create a concise WB artifact then the idea has not been simplified enough.

Frequently Asked Questions (FAQs

A list of questions with answers written in English are a great way to drive clear thinking on all the stuff that surround the central idea presented in the WB narrative. This ‘stuff’ includes things like strategy, execution, technology, business, and resources. Appendix A contains the current set of FAQs required for every product related WB narrative Product Managers will own. See A FAQ About Frequently Asked Questions for a set of Tenets on how to write great FAQs.

The main text of any narrative should be so clearly written that FAQs are unnecessary. To accomplish this, make a list of ten questions a reader might ask. Answer them. Then determine if those answers should be integrated into the main text (e.g., as part of the WB artifact) or handled verbally in the review meeting. Put the answers that don’t belong in the document but might be needed during the meeting (verbally) in a back-pocket appendix (see section on Back-pocket Appendices below). Repeat. By doing this, the author is forced to do the critical thinking to generate more questions and answers.

As the author does this, she or he will find questions that simply can’t be answered cleanly in the main document or are too critical to leave for the back-pocket. These become FAQs in the FAQ section of the narrative.

Appendices

Often it is useful to provide readers with supporting data, diagrams, or pictures to help them understand the concept. These should be put in appendices to be printed with the main document. These appendices are not counted against the six-page limit, but authors should plan on readers taking the time to read them during the review. In other words, if you include an Appendix expect your readers to spend time on them which will make the document reading part of the meeting take longer. Use with care.

Back-Pocket Appendices

A back-pocket appendix is a separate document that you bring to the review meeting, printed out, but you do not hand out unless absolutely needed. The idea is to have them “in your back pocket, just in case.” This is totally optional.

Appendix A – Frequently Asked Questions about WB Docs

1. When should I use the Working Backwards narrative versus other narrative forms?

WB docs can be effective anytime an idea is being discussed where there will be customer impact. It is important to remember that customers exist everywhere. Yes, your company’s real customers are important. But if the idea is an improved code review tool used by our own developers, then the customer is your internal developers. I could have written this narrative as a WB doc, but that felt doing so felt forced and awkward, so a judgement call was made to not use the WB form.

As a rule, anytime we are driving a deliverable like a product, feature, or program we will use a WB doc.

2. Is there an approval process for WB narratives?

There can and should be. To get started, use WB narratives simply as a way of ensuring everyone is on the same page, with total clarity, for product ideas. Have mechanisms for deciding what product ideas and projects are “approved” (e.g., product gates). For WB narratives where a leader requires a WB doc to be written, he or she will declare when the doc is “done.” This can change over time as more members of the team become experts in this mechanism.

3. Who should be involved in creating a WB Narrative?

This depends, and is a judgment call the doc owner must make. The doc must be complete, clear, and concise. For it to be complete, all key stakeholders likely need have provided input. The standard set of FAQs in Appendix A are designed to provide a forcing function that the owner has done his/her diligence in roping the right set of people in.

4. Who should be invited to WB narrative reviews?

Who gets invited to review meetings depends on how far along in the process the document is. If it is early stages, then the answer is whoever the doc owner thinks can help improve the document. In later stages, it is the set of people core to building the deliverable, typically Product Management, Engineering, Supply chain, Marketing, and Sales. If the goal of the review is to get guidance on the relative priority of the idea (e.g. if the team needs guidance on when put resources on the idea, and how many resources to apply), or if a leader requested it then the owner should invite that leader.

5. When should a WB document be reviewed with Sr. Executives?

As early as possible in the process. Sr. Executives, through the nature of their roles have broad context on the company’s customers, business, technology, and organization. Thus, then are in a unique position to provide structural and fundamental guidance or feedback on ideas. The earlier the owner involves these folks, the faster the doc will improve.

The key for doing this is to ensure the doc is clear (in its introduction) what stage the document is.

6. Do I have to use the standard template?

Yes.

7. Where should I store WB narratives?

They should be stored somewhere that supports collaborative editing in Word or equivalent word processor and where they can easily be searched over time.

Appendix A: Standard WB Narrative FAQs

These are REQUIRED FAQs that EVERY WB doc. This ensures we nail more of what is ‘knowable’ early in the process. Have a Word document template that includes these. Authors should use this list as a checklist for questions the WB doc must answer. If one of these is answered clearly in another part of the doc, or can be answered by asking a better question, then that is fine. The key is to ensure that the team is involving the right folks and doing the right critical thinking early in the process.

• Why is this important to [Company]?
• What are our Principles for this product/program/feature?
• What are the Priorities for the initiative?
• How will we describe this to sales?
• What is the plan for geographic roll out?
• How will this compare to the competition?
• What is the thing you think hardest about? (this is the most likely thing you have to do)
• Risk: What are the riskiest parts of this?
• Risk: What is the Impact, Likelihood, Exposure of those risks?
• Risk: What are five to seven mitigation strategies for those risks?
• What IP will we create as part of this?
• What tech do you envision we need to buy, license, use, invent, to make this true?
• What cloud services will be required to make this work?
• What device software will be required?
• How will we measure success (business & customer)?
• What metrics will you track?
• If this involves creating new hardware, what is the EOL plan for key components?
• HW: Have you had a kickoff meeting with change management?
• HW: What is the SKU plan (e.g. number of SKUs, bundles, etc…)?
• HW: What regulatory issues have you considered?
• HW: What is your naming plan?

---

I’ve put a Word doc version of this here so you can have access to the Word template I like using (that includes line numbers and consistent formatting): Working Backwards Narratives.docx