We should use briefs, pitches, and roadmaps when making things.

Why should we use briefs, pitches, and roadmaps?

• When trying to shape our goals and ambitions, there’s a lot of chaos from all the different thoughts being summoned into existence.

• We naturally try to gather these thoughts into decisions, while making lists of upcoming todos, but these lists only outline an idealistic path, they do not explore the landscape of our vision.

• Without this exploration, we may not have enough practical context to know how our creations will fit within our world view.

• As we explore the ideas related to our vision, we can begin to shape a narrative around what we want, how we will achieve it, and when that will happen.

• With this approach, briefs, pitches, and roadmaps are tools for ideation and are intended to help describe the different phases of thought for developing our ideas.

What is a brief?

• In practice, a brief is a form of documentation that is designed to help us understand a goal before continuing with the next steps.

• This kind of documentation helps us prepare for upcoming activities and serves as an introduction into a shared rationale of what is important.

• The brief is there to suggest a general direction and curiosity about what we find to be meaningful or relevant at the time.

How do we use a brief?

• When we have a brief, we’ll have a draft of our initial thoughts and ideas which guide us towards an outcome.

• A brief can distill our intuition or analysis, but it will not have a clear picture of many important details. And without these details being explored, we cannot be assured that pursuing these outcomes is worth the risk of effort or time.

• We still need a way to examine the details and compare the possibilities before placing our bets. This is where we can benefit from having a process for documenting the exploration and examination of a brief. And by the end of this process we’ll have aimed to produce a pitch.

What is a pitch?

• In practice, a pitch is a form of documentation that explores the premise of a brief and records the initial discoveries.

• The structure of a pitch will likely follow a rhythm of clearly defined benefits and costs of the ideas within the brief. And a pitch will attempt to weigh the pros and cons of the different ways we can fulfil the brief.

• For example, a pitch will try to find the common misunderstandings related to our ideas, and will attempt to reveal known pitfalls on our path to pursuing our goals.

• Additionally, a pitch will try to enrich the proposal of the brief into a well-defined outline of a plan that considers the amount of effort and time that we can spare.

• In summary, a pitch is a document that will explore the context of a brief, and propose a potential strategy for fulfilling the premise of the brief, or raise any issues that the brief does not address.

How do we use a pitch?

• A pitch is used in two phases. The first phase is when we’re developing the pitch, and the second phase is after we’ve created the pitch and have moved on to reviewing the plan of the pitch.

• In the first phase, we use a pitch as a document where we can think about and collect all the necessary knowledge required to make official decisions.

• Initially, we leverage the documentation of a brief by thinking through the fundamentals and limitations of the brief to reveal a big-picture view with all the necessary context.

• During the first phase, the pitch becomes an iterative document where we develop the thoughts and ideas around the brief.

• The pitch can be nurtured with multiple perspectives, allowing for an interactive experience while crafting a well-defined plan. This phase also allows for some light experimentation to gauge the complexity or plausibility of the pitch.

• At the end of this phase, the resulting document will present a narrative outlining the exploration of the brief, and providing a proposed strategy for pursuing the desired outcomes.

• In the second phase, the documentation of the pitch will be reviewed as a potential plan to enact. There could be multiple pitches for one brief, or several unrelated pitches that need to be prioritised.

• At some point, the pitch is reviewed from the perspective of those responsible for the overall planning and scheduling of these ideas. Those responsible can mark the pitch as approved if they’re satisfied with the plan within the pitch and think we are ready to begin.

• Once a pitch is approved, we can begin assembling the next form of documentation by leveraging the plan within the pitch into a format that can be easily scheduled with multiple teams or departments. This form of documentation is referred to as a roadmap.

What is a roadmap?

• In practice, a roadmap is a form of documentation that manages a series of checkpoints. These checkpoints are derived from the vision of the brief and the plan within the pitch.

• Each of these checkpoints described in the roadmap can be thought of as the necessary milestones along our way to enacting our plan.

• Additionally, a roadmap will attempt to handle the day-to-day situations that arise when trying to enact the plan. If we need to make any adjustments, we can use the roadmap as a place to organise and prioritise the changes to continue our efforts.

• In summary, a roadmap will leverage the vision of the brief, the plan within the pitch, and transform those into a set of steps towards the end-goal.

How do we use a roadmap?

• We can visualise a roadmap as documentation that defines the checkpoints we must reach before we can consider our plan fulfilled.

• For example, a team with designers and programers can attempt to untangle their efforts as much as possible by focusing on the fundamentals pieces of their solutions.

• The programmers could focus on developing the portions of the functionality that is not directly dependent on the design. While the designers could focus on crafting portions of the experience that do not need insights from the technical implementation.

• However, these two teams would likely describe some of their implementations as being dependent on each other. Which means that the roadmap will be used as a way to describe these dependencies.

• Continuing the example, if a designer needs to understand the technical limitations of a system before completing a design, that dependency should be documented and prioritised for the programmers to assist.

• And if a programmer has unanswered questions about the user experience, or needs new pieces of a design-system, that dependency should be documented and prioritised for the designers to assist.

• This means that we use a roadmap as a collaborative document between the involved teams. And that the purpose of a roadmap is to maintain a clear picture of the different paths of effort and all the dependencies between each of the steps.

What happens next?

• Once we have understood why each of these documents can be useful, it can become clear how they are designed to progress a thought process into an actioning process.

• The downsides of not following a process like this is that we can find ourselves with a lack of cohesion when collaborating together as a team.

• This can be seen in the way that some projects for teams are not designed or documented in a way where the shared context and rationale is clear to everyone.

• In many situations, the important details or decisions are made in meetings that do not produce notes or in private conversations that aren’t propagated to the rest of the collaborators.

• The meaning behind decisions can be lost and it can become difficult to remember why we’ve done things in the first place as members of the team will change over time and some members of the team will be replaced.

• With these tools we can plan for future iterations of strategy that guide us closer to our greatest ideal. And hopefully, as we make progress our teams can sense the convergence towards those ideals, and begin to feel a sense of trust about the path we are travelling.

• Along the way, we’ll have ways to reassess and realign because we have adopted these ways of documenting our ideas. And we’ll be able to review our initial premise and see if our theories were valid.

• And if they were invalid, we can then create a new series of documents that describe how the theory was wrong, why we need to have a different focus, and how this is going to help.

Where can we learn more about these concepts?

• The tools described are derivative from the Shape Up framework, and inspired by the “shaping” process.