ISSUE #19 - JULY 29, 2023
Backward Working Documents: What are they, and why should you use them
In this post, you can learn what are Backward Working Documents, how and when to create them, and what are the benefits of using them.
Backward Working Documents (BWDs) are used for quite a long time now by companies like Amazon - who invented the concept - and are an important tool for them when starting new projects. Teams of any function can use them, but in this particular context, we'll discuss the benefits of using them in a product team. I have been using BWDs with my teams for more than a year and in this post, I'll give you an intro on when to use one, how to form a good BWD and the benefits of doing so.
What is a Backward Working Document?
As their name suggests, with BWDs you work starting at the end. Product teams practically issue an internal-only press release announcing the product's release in its final form. As implied, crafting the BWD is a collaborative process. The product manager can write its draft; however, it's polished and iterated based on the feedback of the product team. Creating a BWD helps the team focus more on the product benefits rather than the features the product is consisted of.
Typically, a BWD consists of the following sections:
- Press Release: The fundamental elements that should be found in the press release are the product's name, the target customer, the problem to be solved by the product, the benefits for the customers, and a quote by someone from the company elaborating on why you are building the product. Most importantly, though, a press release should include customer quotes. Those quotes should encapsulate what you wish your customers will be saying once they use the product.
- FAQ Section: This is where you shed light on business or tactical questions about the product you will build. Pro-tip: To avoid having the same questions repeatedly (although this will be happening to some degree), share the press release with your team and ask them to add their questions based on that. Then use those questions to populate this section. It will be way more meaningful and valuable for the whole company.
- Appendix: As part of the last section, you may add any visual aids like wireframes or mockups (if applicable) or even diagrams to help the reader better understand what you intend to build.
When to use a BWD?
In general, BWDs are tools that enhance clarity, and team alignment, while they help with planning as well as decision-making (more on their benefits later in the post), so to take the most out of them, it's better to create one at the beginning of a project. However, not all projects qualify for a BWD. There are small and contained projects and others that are big in scope and duration. BWDs will help you with the latter. The heuristic I'm using to evaluate if I need to write a BWD is that the project should be estimated to take more than two work weeks for at least one person. If this is the case, I go ahead and write a BWD.
What are the benefits of using a BWD?
Helps you ensure you put the user in front
Writing a press release unavoidably puts you in the shoes of the client. Either when trying to figure out the best way to explain the problem or even when trying to think about how you envision your clients would feel while using it. After all, one of your goals while issuing this internal press release is to convince the readers (your colleagues) about the value of building this product, which gets us to the next point.
It's a good initial assessment of the product viability
Crafting the BWD puts you in a position to think hard about what you expect from this product release, how it will solve your user's problems, and how they will benefit from it. Also, by sharing this release with the rest of the team, you get valuable feedback on your initial thoughts, which helps you identify significant gaps or risks you haven't thought of. Of course, it's only a gut check - as the real validation comes only from user research and hard data.
Enables goal-oriented planning
By focusing on the end goal first, product teams can develop a more effective and purposeful plan to reach that goal. This approach ensures that every decision made during the product development process serves a specific purpose in achieving the ultimate objective.
Helps technical speccing, provisioning and minimizes development risk
By sharing your final vision with the rest of your team, especially the engineers, you allow them to plan how they want to work effectively. Most importantly, by letting them know what comes later, they can provision for that from early on in terms of technical trade-offs. They can discover potential roadblocks that significantly affect delivery later on, so this saves you significant time further down the line and minimizes the risk.
Enhances collaborative teamwork and alignment with the rest of the company
Unfortunately, silos exist in companies more often than not. There are cases where the rest of the company learns about a release alongside the public. By definition, BWDs require input from stakeholders and the rest of the company, which enhances collaboration and fosters teamwork. On top of that, you ensure that everyone is aware of what's coming, and they can better understand what the product team is building and why.
A great way to check if BWDs are the right tool for you and your team would be to try them. Find a relatively contained initiative - however big enough to justify writing a BWD - and craft it out. Then, at the end of the project, discuss with your team whether using a BWD helped you be more effective with your work and how. If the results are good, you can gradually start incorporating them into your product development process.
Past Newsletters
ISSUE #18 - JUNE 20, 2023
Reflection Documents: Before crafting your next quarter's plan
Over the years, "reflection documents" have helped me and my teams improve how we set goals, create plans and collaborate as a team.
ISSUE #17 - MAY 25, 2023
Pre-PMF: Prioritizing the right items to work on
In this post, I am not talking about prioritization frameworks. I aim to present you with some of my learnings about pre-PMF prioritization, most of which I had to..
ISSUE #16 - APRIL 19, 2023
Don't rely on NPS to make decisions for your product. Here's why.
NPS is flawed by nature as a product metric. In this post, I'm showcasing why it's not a good idea for product leaders to use it as a metric based on which they..
The Product Notebook by Manos Kyr.
Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.
Latest Newsletters
ISSUE #25
What to do when you don't know what to do next
ISSUE #24
When good docs go bad: Learning from a PM's misstep
Copyright © Manos Kyriakakis