Definition Playbook

Guest post by Rebecca Monfries, Head of Delivery at Terem Technologies, and Nathan Bruce, Lead Business Analyst at Terem Technologies.

Published in

Product Coalition

7 min readNov 10, 2021

Word from Scott: Over the years we’ve helped many different teams bridge the gap between discovering requirements and getting them ready for deployment. So I asked the team to share the playbook we’ve used to help prepare them to begin Definition. Read on for the Definition Playbook written by Rebecca Monfries and Nathan Bruce.

What is Definition?

Once you have completed enough discovery on your product or feature, the next stage is to prepare for the development process — to determine, in greater detail, the requirements and scope that you want to build. Hopefully you’ve already discovered the features that are going to give you a higher return on investment, so now is the time to break them down and understand them in more detail — to look at the current system architecture, consider the high-level solution and outline how you’re going to implement it.

During the Definition process, a series of workshops are conducted to review the specific problem to be solved (or Job-To-Be-Done), understand what can be done to fix it, design the physical and technical solution, and prepare for the development sprints to start. On completion of this phase, you will have a rough idea of the final estimates and timeline for completing development, and most excitingly, you will be ready to start building.

In some organisations, Definition is an isolated process completed all at once for multiple features or initiatives. In others, Definition is integrated into your continuous product development activities. Either way, the process of Definition will be similar and is still important to complete, to bridge the gap between discovering requirements and getting them ready to be implemented.

Why do Definition?

The Definition process is where we pin down our focus and start to make choices. During Discovery you have focused on gaining understanding; understanding of the problem, the market, your users etc. During Definition you want to focus on moving past the discovery concepts, making detailed choices (about tech, design and requirements) and obtaining enough clarity to start developing solutions.

Definition gives you an opportunity to make a plan for your prioritised Jobs-To-Be-Done, breaking them down into tasks, estimating with greater clarity and focusing on the action plan for delivery. Definition is the process that takes you from idea to action.

The process of Definition takes a more exhaustive look at the detail of what needs to be implemented to solve a problem, and assists in surfacing any risks to the implementation process. It may help (or not) in justifying a business case for proceeding with, or re-prioritising, a product or feature, through the confirmation of effort, risk and/or feasibility.

Lastly, the process of Definition continues the practice of promoting alignment and increasing communication across the business about your product development activities. Bringing stakeholders together to talk through the proposed solutions to problems that have been previously discovered, and moving forward to keep them informed throughout the implementation of those solutions.

Key Concepts

One key concept to keep in mind when going through Definition:

Double Diamond — this design process that is useful to use when going through product development. See this post for more information on the Double Diamond design process and when to use it.

Key Inputs

The key inputs for Definition are the outputs from Product Discovery.

You may or may not have all the outputs listed in the Discovery Playbook but hopefully you have a good justification that there is a market for your product/feature, verification that the solution meets the key outcome you are trying to achieve, and at least a high-level understanding of:

The problem and/or the Jobs-To-Be-Done — these are the problems you want to solve. By bringing your choices back to the original problem statement, and keeping the users’ pain points at the forefront of your decision making, you can be more certain you are making the right choices for your product
User Personas — ensuring a great understanding of your user personas can help give you empathy for their pain points and problems, and help you shed assumptions about how to solve them. You can read up on Truly Understanding Your Customer here
Your roadmap (features and their rough priority)
Low-fidelity wireframes to enable design and style guide definition
Access to information on any existing system architecture including integration points
Defined key success / failure metrics

Preparation

In order to start the Definition process, make sure your team understands the problem. At this point, the product team should be completely aligned on the problem to be solved (or Job-To-Be-Done) and why it needs solving. If the team is not aligned, start your preparation there.

To prepare for the best outcome, you will need to ensure you have the appropriate team members and stakeholders available. This could be the Product Trio of the Product Manager, Design Lead and Tech Lead, or it could include others depending on what you’re planning. If you’re planning to work on something that has highly specialised knowledge, such as third-party integrations or a specialised domain (e.g., accounting or taxation), find your Subject Matter Experts (SME’s). The modified adage “keep your stakeholders close and your Subject Matter Experts even closer” has ensured successful product development for many teams.

If anyone on your team is new to the product, organisation or industry/domain, onboard them as best you can. A comprehensive understanding of your organisational strategy and how it ties into the product development you are undertaking is foundational to clearing assumptions from the process.

In addition, making sure you have the right tools handy will make your Definition activities run smoothly and efficiently. At the minimum, we would suggest a whiteboard and pens (or a virtual whiteboard tool such as Miro).

Key Activities

The key activity streams, integral to successful definition outcomes, are:
Stakeholder Identification and Alignment

User Requirements
Technical Design and Integration
Product Design
Estimation and Planning

Stakeholder Identification and Alignment

The start to any product development processes should be the identification of your stakeholders. Making sure you’ve got the right people in the room, and keeping them informed along the way will maximise your chances of success by gaining continued alignment. To complete Definition well, ensure your stakeholders have sufficient availability to support the process, as well as a well-formed understanding of the things listed in the Key Inputs section above.

Alignment of stakeholders will be a consistent pursuit throughout your Definition activities.

User Requirements

Definition will usually involve one or a series of user requirement gathering workshops. The goal of these workshops is to understand in more detail, the user journey, pain points and user needs. You will likely outline the current user journey and the future state (a.k.a. As-Is and To-Be scenarios) as part of these workshops.

These requirements can then be defined as Features, Epics, and then broken down into User Stories. Ideally you will develop your user stories to a state where they are ready for development, but depending on your choices around roadmap and prioritisation, you may keep these stories fairly high-level and add the remaining detail later when the requirements are prioritised for development.

Technical Design and Integration

In parallel to user requirement gathering workshops, technical design and integration workshops should be conducted to get an understanding of existing system architecture (if it exists), any technical/architectural risks, and to make choices around the design of the new system architecture.

During these workshops you will need to take into consideration any factors that may make development riskier, or anything specific to your organisation or domain (e.g. compliance, legal etc).

You might also discover at this point that further tech spikes are necessary. There’s no time like the present to fill gaps in knowledge, or ascertain the technical feasibility of a feature, so spike away. You can read up on Tech Spikes here.

Product Design

Alongside your User Requirements and Technical Design activities, you will also work to analyse the User Journey and experience of the Product or Feature. This likely means moving to higher fidelity, more detailed wireframes and screens. This helps with visualising how the product or feature will look and will enable the team to make the right decisions for the product. It also helps when it comes to estimating your development effort and being ready for your sprints to start.

Planning for Development

Once you have completed the above activities to a point where your requirements are ready to be developed, there are some final planning activities to be done in order to round out your Definition. This may include the following:

Socialisation and Estimation
Sprint Planning
Further prioritisation (or even de-scoping) and backlog grooming

Outputs

In general, the outputs of the Definition process, you can expect:

Requirements that are ready for development
Estimations (even if they are still high-level)
A well prioritised and groomed product backlog
Architectural designs
Medium to high fidelity wireframes
Stakeholder plans
RACI log (Responsible, Accountable, Consulted, Informed)
Key issue/decisions log

Remember, depending on the product development framework your organisation uses you may have more or less outputs based on how much you are defining in one go.