Define a Feature

You're reading the page five of the product development handbook.
What's in a feature?
Feature Specs are nested inside Briefs. For example, a feature spec may be "Add new goal" under the "Goals" Brief. A Feature is nested under a brief or workstream and is documented in a Feature Spec.
Feature Specs are nested under a Brief, adding a Feature Spec might mean updating the content of a Brief. Before you can complete a Feature Spec you need to pick a solution and track the ones that were not picked and why. Then you are ready to start filling out the Feature Spec.
Pick the solution
Before you can complete a feature spec you have to have already chosen a solution. The process for picking a solution involves working with many team members, sorting options based on impact vs effort. You can start by filling out the problem, writing the outcome, and thinking of success criteria. Then you need to pick the solution.
How to pick a solution?
1. Make a solution table
Who owns the work: UX Designer Who's Involved: Product Manager, UI Designer, Business Development, Tech Lead
Solution Tables are a concept, and visual representation, for teams to compare possible solutions and pick their favourite one. The best-designed solution, with the impactful user experience, is often the most effort for the development team to build. There may be other ways to achieve the same outcome with less effort. Solution Tables help cut through the noise.
This is the first introduction of a prioritisation framework or technique. Because Solution Tables are for picking one solution to one problem, the prioritisation method is simple. More prioritisation methods will be discussed on the next page: Prioritise. Picking a Solution is a ceremony or meeting, that can be a held synchronously or asynchronously.
Don't confuse this step on the process with the agile "three amigo's meeting." Instead, the goal is to discuss a problem that has enough customer validation that you will work on solving it and start preparing a solution. In SCRUM there is a concept of a "three amigo's meeting" where you bring three perspectives into a room to refine user stories to estimate them. Those three voices are usually customer voice, technical voice, and test voice. If you follow SCRUM, and the first time these three voices in a room are at a three-amigos meeting to estimate user stories, you've waited too long. A three amigo's meeting is way too late in the life cycle of building a feature for it to be valuable for building product features. SCRUM is like mini waterfall project delivery and doesn't bring all voices together for solution design upfront.
Start by giving every solution option a name and make a table with the list of options. Then work with the entire team to put an impact and effort rating on each option.
Impact - How well does this solution solve the problem? Does it offer a great or mediocre user experience? Is it an actual solution or just a workaround?
Effort - The amount of perceived difficulty it takes to accomplish building the solution. Effort is in relation to other solution options that you are comparing it to. Effort is not an estimate of time or even a tool to track burn down. Instead, they are used to help decide which solution is the most optimal.
The effort is not an estimate of time Effort is not a ranking of time. Effort and relative effort are used to track the amount of work involved with a potential solution, but also recognises how impossible it is to give timeframes around deliverables for something that is not explicitly defined yet.
2. White-board drawing
Who owns the work: UX Designer Who's Involved: Product Manager, UI Designer, Tech Lead
Work through all possible solution to the problem. First, you identify the outcome that needs to be achieved by focusing on the relevant job stories. Then, draw and visually communicate the possible solutions.
You can communicate your solutions using a:
paper with a felt tip pen,
a drawing app on your tablet, or
in writing.
Draw all of the possible solution options. Workshop these with a dev team to review and add more options.
Don't use high-fidelity mockups for this stage. They aren't worth the time investment, and theoretically every solution except for one will be put on hold or thrown away as an option. It can be disheartening to the design team to go through the effort of designing a high-fidelity mockup for a solution option, only to hear a room full of people explain why that is a bad solution and it should be binned.
Sometimes solutions options will not have any visual design because best-designed solution may not have any interaction design in the app.
To learn more about about how solutions don't have to be designed in an app, check out this book → The Best Interface Is No Interface: The simple path to brilliant technology
3. Pick the 🌶 spiciest solution
This is called calculating the Spice Factor. For every Solution Option, give each solution a value and effort rating relative. Keep these ratings relative to each other. Then pick the one with the greatest effort for the value
The Spice Factor is the highest impact for the lowest effort solution out of all of the options
Spice Factor = Effort / Impact
It's good to track all of the Solution Options and keep them in your brief under discarded solution so that anyone can review that information. Make sure to explain why the solutions were discarded. These Solution Options and their ratings are valuable for future work. You can always prioritise to a more impactful solution later.
2. Write a Feature Spec
Who owns the work: UX Designer Who's Involved: Product Manager, UI Designer, Tech Lead
A Feature Spec is the key documentation for a Feature that is written in collaboration with the team. Here's a template for what should be included in a Feature Spec. A Solution Option becomes a Feature when it is selected to move forwards. Features are single deliverable units of value that can be tracked by the team.
🤖 Feature Spec Template
Describe the feature with an easy to understand name.
List all of the properties that are being tracked for this feature.
Relationship to briefs: which brief or briefs does this feature spec belong to
Status: [backlog, in progress, done, deprecated]
In the context documentation (e.g. Briefs), you listed outcomes that need to be achieved to contribute to solving the wider problem. For this feature spec, which outcomes are you seeking to solve? This could be just listed the relevant job stories from the Brief. Job stores are outcome-focused, where user stories are action-focused. Job stories follow this format:
When... I want... So that...
These job will likely be a nested list.
Redefine what the problem is for this one outcome only.
Make a process checklist of all things your team needs to do to complete this feature spec. With living documentation, document's like this feature spec may get shared in a draft state. Make it clear what is ready and what is still a todo.
Overview of solution
A brief description of the solution and the goals of the solution.
Success Criteria - Indicators or Metrics
List the metrics that you will use to measure if this Feature was successful. They could also be the hypothesis you want to test. (e.g. a 5% reduction of customer churn, or a decrease of time to first achievement.)
Link to all relevant designs
Write the requirements of this feature. Requirements can be written any way that achieves the goal of communicating what should be build.
Feature: ... Scenario: ... Given ... When ... Then ...
List any integrations, API contracts, or information needed to complete this feature.
3. Update the briefs for this feature
As this Feature Fpec is going into the delivery pipeline. Make sure that it's related Brief has up-to-date information about the status of this Feature.
4. Design, Spec, & Spike
Who owns the work: UI Designer, Developer Who's Involved: Product Manager, UX Designer, Developer Lead
Design - make high fidelity mockups, components, and think through interaction.
Spec - write up the requirements and expectations.
Spike - if there is a particularly complicated or undecided technical part of this feature, start development on it in a time-boxed environment to be able to make more informed decisions based on your learnings.
Writing specs and making the design is a parallel process. You do not do designs then write the specs - the same way that it is hard to write all the specs without visualising how it will work.

go to next page


How do you build a roadmap?
Like this handbook and want to see more?