Help us improve the Project Team Playbook: 02 Discover
When you’re in the Discovery phase, here’s what you want to figure out:
- Design your study + gather data
- Analyze data + synthesize what you’ve learned
- Start mapping user flows
- Identify security risks
- Align on which problem you want to solve first (start defining MVP Scope)
- Draft a Product Brief
Discovery is done when:
- You’ve answered the research questions identified in Planning for discovery to the extent possible, given available time and resources.
- You know what’s MVP and what’s not - and why.
- You’ve identified key success criteria (what success looks like) and potential risks (what failure looks like).
- You’ve synthesized the research to the point where you feel comfortable proceeding with solution explorations.
1. Design your study(s) + gather data
This is where we look at all of our assumptions and questions from the research questions and Knowledge Gap exercise, and use several research methods to close those gaps.
✋ Accountable
Product + Design
📝 Outputs
- Determine what kind of research methods help you gather useful data to drive decision-making: stakeholder interviews, user Interviews, data Analysis, etc.
- A team steeped in the research findings (because they’ve been participating all along)
🌟 Activities to try
Start by asking what do you need to know, and by when? Use those constraints to design your research study. Make it flow with however decisions are being made. The methods required and the amount of things we’re discovering will determine the time needed.
- Research methods include but are not limited to:
- User Interviews
- Stakeholder Interviews
- SME Interviews
- Usability tests
- Card Sorting Activities
- Data Analysis
- Review the Design Method Cards for additional exercises and activities
✨ Tips
- After each round of inquiry, reflect on how it went. Share out what you’d do different next time. Remember that talking about learning helps keep everyone current (no one wants to make decisions based on stale information, like planning today’s trip using last Saturday’s traffic conditions).
- Help future stakeholders by marking old documents and artifacts as “Out of date” and linking to the new source of truth as you create it (like your Product Brief, described below). Pause to consider how inclusive your study design is, including understanding who isn’t in the study and why, and how your team will manage bias.
2. Analyze data and synthesize what you have learned
The next step is to synthesize and then summarize our research findings so that they can be used to make product and design decisions.
What does the data tell you? What insights are emerging? Have you answered your research questions? Sometimes your research analysis begins inside a research tool like Dovetail, before moving into a sensemaking tool like Miro, before becoming a summary write-up in a tool like Confluence, a Google document or presentation, or even a summary of key findings posted in Slack.
In addition, sharing out the research findings throughout Discovery is important to help the team gain and maintain a sense of direction for the project, to build cross-team awareness of moving parts, timelines, and interdependencies, and, most importantly, to share stories about the users or customers as humans.
Truss teams have a variety of best practices in place, including making a regular weekly time to share out and discuss what they’ve learned during discovery, and writing up a brief summary of the key takeaways above a tagged interview transcript or synthesis document. The important thing is being intentional about making those share-outs and summaries happen so the team understands the big picture insights along with the small human moments, too.
Moreover, it is rare for Discovery to be perfectly linear, so recording what discoveries and subsequent decisions were made along the way helps future Trussels understand what happened and why. Projects progress and sometimes pivot – and sometimes documentation and artifacts are decipherable, and sometimes not. Investing time to capture information and summarize decisions in a way current (and future) teammates can find and use is helpful for both current and future teammates.
✋ Accountable
Product + Design
📝 Outputs
- Research report with observations, insights, and recommendations.
- Insights from research should be connected to established assumptions and research questions, or must be linked to new hypothesis
- User insights should also be added and cited with our knowledge base for our user archetypes/personas
🌟 Activities to try
- Clustering / affinity mapping
- Review the Design Method Cards for additional exercises and activities
✨ Tips
- Research Synthesis will vary depending on the research method used (e.g. interviews might use affinity mapping, while surveys might use a statistical analysis)
3. Start mapping user flows
After establishing the overall product vision, the Design & Research team can use studio time to create potential user task flows.
In its most basic form, user flow mapping or journey mapping starts by compiling a series of user actions into a timeline. The timeline is then fleshed out with user thoughts and emotions in order to create a narrative. This narrative is condensed and polished, ultimately leading to a visualization.
A journey map is used as an individual actor (a singular customer or user of a product) and specific scenario (of a product or service) to deeply understand a particular business or product in a very focused way. The process of creating a map forces conversation and an aligned mental model for the whole team and the shared artifact can be used to communicate an understanding of your user or service to all involved.
✋ Accountable
Design
📝 Outputs
A diagram outlining all key workflows.
🌟 Activities to try
- Project toolkit: Workflows and Task Flows
- Exercise: Jobs to be done
- Exercise: Service Blueprint
- Exercise: Identify the Customer(s)
- Identify whom a product or feature is targeted at to help maintain full focus on these customers.
- Insights about the customer and their needs
- Who is this for?
- Who are we targeting?
- Who are the primary users? Secondary users?
- What are the demographics?
- What are their behaviors?
- What matters to them?
- What are their needs?
- What are their pain points?
- Who are the Stakeholders?
- Who asked for this feature? Where is this request coming from?
- Who wants it? Why?
- How will they benefit if this is implemented?
4. Identify security risks
Identify any required changes that would impact the ATO or general security of the system and make plans to address those changes. This may very well change by the time that a solution is implemented, so this is not a set-in-stone time. This is just about as early in the process as seems reasonable to be able to predict anything we would need to do to continue to maintain the ATO.
✋ Accountable
Design
📝 Outputs
New Jira tickets that capture any changes needed.
👀 Resources
The Steel Cable definition
5. Align on which problem to solve first (start defining MVP Scope)
There are a lot of possible problems the team could solve. Which one should you solve for first? The exercises at this stage are oriented towards helping the group decide which possible path to take, and why – in other words, starting to define your MVP scope – before beginning to explore the many possible solutions to the problem.
✋ Accountable
Product
📝 Outputs
Team agreement on which problem to solve for first
🌟 Activities to try
- 2x2 prioritization exercise
- You have $100, which problems do you use your money to solve” exercise
- Equity-centered exercises: what features/fixes would definitely benefit historically marginalized populations (which would raise the value of the product for everyone else, too)?
6. Draft a Product Brief
The Product Brief is a source of truth that contains the answers to definitions of what we’re building. It is a living document: as you triangulate between stakeholders, you’ll define and refine the product’s goals, qualities, and specifications – all the information the whole team needs to know as you build a new feature or product. The brief can also highlight how the product vision connects with pertinent contractual obligations. In addition, the product brief can establish a clear and observable definition of success. During the Discovery phrase, the draft Product Brief serves as a continually-updated document containing critical information about the product direction. The expectation is that this will be a very dynamic document as you discover new information and begin to refine the scope.
✋ Accountable
Product
📝 Outputs
- Draft product brief stored in Confluence or other documentation tool of the team’s choice
- Product brief contains a list of success criteria.
- Client has signed off on success criteria
🌟 Activities to try
- 5W’s & H: Understand the value in having the product: What / Who / Why / When / Where / How
- What is it? What will building this feature improve?
- Who is this important to?
- Who requested this?
- Who will benefit?
- Who will use the feature?
- Why is this important?
- Why do we need this feature?
- Why does the client care about this?
- Generating more money/capacity, or saving the company money/time – Increasing revenue, or increasing loyalty of the customer?
- When do the users need to access this functionality? When will it be available?
- Where will it be available? Where will this be accessed by the users?
- How do we know it’s important?
- Is it based on customer evidence or data?
- Are there needs that are currently unmet?
- Will this make it easier for customers to do {whatever it is they’re doing}?
- How will this feature be built?
- What does success look like?
- What’s out of scope?
👀 Resources
✨ Tips
- Consider distinguishing success criteria that will: 1) fulfill contractual obligations; 2) ensure a useful and usable user experience; and 3) promote system health and maintainability.
- For each criterion, consider including a list of user events or system activity we’ll need to track in order to measure our performance. What signals will let you know you’ve met your success criteria?
- Reminder: the client will want to know why we’re working on what we’re working on, so the Product Brief is the documentation that will help the team explain their thinking