<aside> ✨ You're reading the page 2 of the Product Development Handbook.

Next page: Welcome
**People and Roles
Collect Data
Capture Context → Define a Feature Prioritize Build Measure

</aside>

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

<aside> 🙋 Who owns the work: UX Designer Who's Involved: Product Manager, UI Designer, Business Development, Tech Lead

</aside>

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.

<aside> ✋ 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.

</aside>

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.

<aside> ✨ 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.

</aside>

2. White-board drawing