Introduction
Welcome back to The R2D Method!
In our last lesson we defined product planning as:
Activities that are directly informed by business strategy and goals, and that provide direction for which work should be prioritized, why that work is needed, and some high-level details on how the work should be delivered.
We also examined the first essential product planning activity: roadmapping.
If you missed lesson one, we suggest you read it here first.
Roadmapping starts with inputs, which we collect from various sources ongoing.
The analysis of those inputs informs annual or quarterly objectives, which, when linked to quantifiable or qualifiable outcomes (i.e OKRs), can inspire the right project initiatives to put on your roadmap.
Today we’ll talk about the first step in bringing a roadmap project to life:
Feature Briefs.
Lesson 2: Feature Briefs
Feature Briefs are somewhat synonymous with the term, Project Brief, and we may use these terms interchangeably throughout this lesson.
Here’s how we’ll define (and distinguish) them:
A project brief is an introduction to any project on your roadmap. Think of it as a document that translates strategic plans (often conceived in tighter-knit leadership circles or in altogether different departments) to the delivery team.
Project briefs capture the desired outcome of the project (which your roadmap should also and already communicate) as well as the context for why the project is important (“why now?”) and any relevant details that may already be known or decided about the project.
If little or no details are known or decided about the project (or even if some are), the goal of the project brief is to more clearly define the problem or opportunity space, and to inspire the solution.
The details of the solution get fleshed out in the release plan, which is the topic of the next lesson.
A feature brief serves the same goal as a project brief, but is more appropriate for businesses (and roadmaps) oriented toward ongoing innovation for products, rather than operations, sales, and marketing activities.
Another relevant distinction is that the feature brief begins as a standalone document, but is later integrated into product documentation, whereas project briefs are generally archived or discarded once the project is complete.
The goal of the feature brief is to more clearly define the problem or opportunity space and to inspire the solution.
Here are the attributes of a feature brief that you should commit to memory:
- They should be more data-driven than creative
- They should be more heavily weighted toward problems and opportunities than solutions and the specifics thereof
- They should be prepared by department or team leaders
Why We Need Feature Briefs and Who Should Write Them?
Feature briefs make project kickoffs more successful because they provide a consistent, shareable point of entry for all project contributors.
When we put in writing the key questions and considerations for a new project, we ensure that everybody can get briefed consistently, and we enable the kind of asynchronous communication that’s needed for work-from-home organizations / distributed teams to thrive.
Feature briefs also serve as wayfinders back to why the project is important, which is easily and often forgotten as you progress further into production.
For this reason, it’s typical that feature briefs are prepared by department or team leaders; the senior individuals in the organization who are at once strategists and decision-makers but also directors and supervisors to more tactical team members. The split perspective of such an individual serves the task of translating strategic objectives into the scaffolding for actionable plans far better than somebody more junior, whose role is primarily tactical and therefore tends to be more solutions-oriented in their thinking and in their day-to-day.
In any case, feature briefs are living documents that will surely evolve through conversations. So when we talk about “who should write the feature brief” what we really mean is that the first draft should come from leadership.
What to Cover in Your Feature Brief
Feature Briefs are used to document requirements for a new feature or project.
Once an initiative has been identified on the roadmap, the department or team leader should create a feature brief to begin telling the story of why the feature is needed, who it will be for, and how it should generally work.
The process of drafting a feature brief should incorporate goals, known requirements, and data insights gathered from key stakeholders and resources in other departments such as sales, marketing, customer service, and engineering. Because of this, feature briefs should be recognized as inherently iterative, and not an activity that gets completed in a single sitting.
Feature briefs should focus on fully identifying and clearly articulating problems and opportunities, rather than describe the solution or final output. In the film business, screenwriters are taught “don’t try to direct the movie through the script.” In product we say, “don’t try to design or build the solution through the feature brief.”
Feature briefs precede release plans, user stories and all coding or production activities. These are the activities where solutions are developed and refined, and we’ll be discussing them more throughout the rest of this series!
As a final note for our readers who may be preparing to write your first feature or project brief:
Own what you don’t know!
The feature brief is meant to ask questions and facilitate conversations, not to be an unassailable artifact of one person’s expertise (which could never possibly cover all the perspectives needed to create great solutions).
By “own what you don’t know” what we mean is don’t try to know more about APIs and database schemas than your engineers if you’re not one, just raise the questions you’d like for experts on your team to weigh in on.
Here are some suggested sections to include in your feature briefs:
- Background. Use this section to provide context for why this feature or project was identified and prioritized on the roadmap.
- Problem or Opportunity. What pain points is this initiative trying to solve for or what market gaps have been identified? Include specific qualitative and quantitative data that validates this information or identify the key assumptions that must be proved as part of the project.
- Proposed Solution & Value Proposition. Describe the solution or feature at a high level. Focus more on how the solution will solve the problem or how the user will benefit rather than how features will specifically look or work.
- Customer / User Persona. Indicate who will benefit from this solution. Is it your customer? Your employees? Is it a specific segment of users from within a larger group? If your marketing or user research teams have developed persona documents, here is a good place to reference them or link to them.
- Competitive / Considered Solutions. Are there any competitive solutions in market to reference? How should this solution be different from what exists already? Were other solutions previously considered? Why were those ideas rejected?
- Success Criteria. How will the success of this project or feature be determined? What desired outcomes are already assigned to this project or, more broadly, to the department or company sponsoring this initiative?
- Functional Requirements. If you have some known details or initial ideas for how the solution will work, you can list them here or include a workflow diagram or sketch. Just don’t be too attached to any ideas at this stage.
- Non-Functional Requirements. Describe how the solution might or should look or which user interface elements and guidelines should be followed, if applicable. Include links to visual references such as wireframes or mockups, or even embed reference images directly into this section. If you’re not a designer or a designer has not yet been involved in the process, this may not be necessary.
- System / Performance Requirements. Describe key performance criteria here. For example: page must load in less than 2 seconds, or site must be supported by Google Chrome version x or greater, or server must be able to handle as many as 100,000 concurrent users per session. Remember: play to your strengths and frame details you aren’t certain about as questions rather than requirements!
- Analytics Requirements. Just because your product or team already uses analytics tools such as Fullstory or Mixpanel doesn’t mean that the actions you’d like to track as part of this project are already being recorded. The brief is a great place to begin the conversation on data collection so that you can be sure you have a plan for collecting the information that will measure the success of the project.
Relating Your Feature Brief to Your Roadmap
Like with your roadmap, you’ll want to create your feature brief in an easy-to-edit, easy-to-access, easy-to-share place.
For smaller organizations and teams we love Nuclino for this.
For larger organizations we recommend Confluence.
Microsoft 365 and Google Docs will also suffice but are not as conducive to indexing and relating documents. This may not be as important if your organization archives or deletes briefs after delivery, but if you have a process for integrating your briefs into your more permanent documentation library, then you’ll want to steer clear of these tools.
Wherever your feature brief lives, it’s also a good practice to provide a link to it from the roadmap so that viewers can more easily toggle between the “all projects” roadmap view and the project specifics that the feature brief serves to initially communicate.
—
Keep an eye on your inbox next week for Lesson 3: Release Plans
Not yet registered for this course? Sign up here
Would you like to get started using our free Feature Brief Template? Request a copy