01 Plan

When you’re in the Planning for Discovery phase, here’s what you want to figure out:

  1. Determine the goal (draft product vision)
  2. Define roles and responsibilities
  3. Form research questions + identify gaps in knowledge
  4. Make a timeline
  5. Hold a Discovery kickoff meeting

How do you know if the team is ready to move to the next phase?

Planning is done when:

  • Team leads and key client stakeholders are aligned on the desired high-level outcomes of the project.
  • You have clearly defined research questions to be answered during discovery.
  • There is an agreed-upon source of truth for all discovery work (such as a research repository like Dovetail, and later a product brief document) and for communications (usually Slack).
  • You have an agreed-upon place where you will store your data, analysis, and documentation.

1. Determine the goal for the product

What’s the team’s draft product vision? …Do you know, yet? Your team might have a rough idea of your product vision by the first week of the contract; but maybe not. That’s okay.

There are many ways that projects unfold – you might find yourself in a situation where your team has requirements and goals that are largely known, or, discovery might really be about problem exploration. If it’s the latter, stay focused on what you want to learn in order to get to a draft product vision. You’ll eventually want that north star vision, even if it’s too early to formulate it yet.

In the meantime, as the team begins to articulate goals and (potentially) a draft vision: how does that vision intersect with contractual obligations, customers served, user experience, and more? What questions do you still have? Getting to this alignment requires discussions with the full team.

✋ Accountable


📝 Output for this phase

A brief description of the goal, e.g. “MilMove can support moves with 1 household goods shipment.”

🌟 Activities to try

  • Rapidly generate a list of goals in a team brainstorming discussion: who are our users? What do we think we know about them, vs. what do we need to know? Then group those goals into themes and/or try to prioritize them. Collaboration is important here to begin getting to a shared reality.
  • Try the Anti-goals exercise as a group
  • Try a collaborative whiteboard activity like the Inception Workshop

2. Define roles and responsibilities

For small teams, assigning lead roles for Discovery may be a straightforward exercise! For larger teams or larger projects, each discovery effort needs clear assignment of ownership for the product’s product, tech, and design work.

✋ Accountable


📝 Outputs

  • There is a core discovery team
  • Everyone knows what they’re accountable for/contributing to

🌟 Activities to try

  • Talk through the Team Accountability Matrix for a high-level overview of Roles & Responsibilities
  • Lead, contribute, learn exercise
  • Workstream norming exercise

3. Identify gaps in knowledge + form research questions

What do you already know, and what don’t you know based on previous information? What questions do you need to explore during research?

Forming questions as a team is a lightweight and powerful way to uncover the problems you’re trying to solve. For example, five minutes of brainstorming questions in a shared document will quickly generate a lot of different angles of inquiry. Moreover, it’s an efficient way to take advantage of our different practices’ lenses on the problem space, too.

In addition, jointly brainstorming research questions sets the stage for subsequent conversations about how you might answer the top questions, which leads into deciding how many people you might need to talk to to find answers, by when, and how confident you need to be. Basically, you’ve involved the team in research design without making it a big thing.

Forming questions requires making a safe environment for people to be open about what they don’t know. For example, you might ask: “Based on X evidence, what do we really know about Y? What do we already know? When do we need insights by?” Good questions are specific, actionable, and practical. Moreover, thinking about questions also allows you to organize past research around questions, too.

Try evaluating your research questions with this checklist1:

  • Will answering the question give us the insights we need?
  • What type of data, and how much, will answer the question? Qualitative (descriptions) and/or quantitative (measurements)?
  • Do we have the means to answer it?
  • How do we know when we’re done answering it?

Categories of questions:

  • Generative: what is the problem?
  • Descriptive: what is going on and how does it happen? (you need descriptions not reactions)
  • Evaluative: how well does our solution work (to solve the problem) — evaluate, don’t validate. Validate usually means “prove i’m right”
  • Causal: why is this happening? Ex: something shows up in your metrics, need qualitative work to answer it

It’s also important to document this information in a shared space, which may require decisions on what type of information should be stored in which formats, and how the team will know where to find it.

✋ Accountable

Product + Design

📝 Outputs

  • A list of research questions to answer in discovery
  • A team of people poised to be information sponges: everyone is on the same page for what to watch for, and can come up with more (and better) questions
  • A place to store information and research data

🌟 Activities to try

  • Try using tools like Assumptions, Hypothesis, and Research Questions from the Project Toolkit. Ideally the client is involved in this conversation.
  • Scan any existing data, with the goal of forming research questions (you’re not at the analysis stage, yet)
    For projects that are already underway, consider creating an inventory of what’s already documented in Google Drive, Slack, Jira, etc. for easy reference later.
  • Run a brainstorming session where participants individually type responses to the prompt “What questions do you have?” before the group pauses to reflect and review the question bank. Which questions are more important, first? Which questions do you decide to set aside?
  • Begin creating a Stakeholder map

4. Make a timeline

The objective for this step is to get everyone aligned on expectations for the cadence and pace of discovery:

  • Allocate time for discovery research and framing: forming questions, gathering data, analyzing data, exploring solutions
  • Fit everything within the timeframe that you have

✨ TIP: Share this timeline with the client to help them understand what goes on in discovery and how much time it takes.

✋ Accountable


📝 Outputs

A timeline created with the team that includes key information:

  1. Estimated outcome kickoff date (when planning begins).
  2. All the discovery activities you want to do for this outcome + estimated time to complete.
  3. Scheduled check-ins.
  4. Scheduled PTO for all team members and stakeholders.

🌟 Activities to try

5. Hold a Discovery Kickoff Meeting

The objective for the discovery kickoff meeting is to gather the team and key stakeholders to:

  • Discuss the business goals of the product (impact of the product)
  • Align on research questions
  • Identify, prioritize and plan for knowledge gaps

✋ Accountable

Product + Design

📝 Outputs

  • A write-up of the business and product goals that everyone on the team understands
  • Research questions have been prioritized and assigned owners

🌟 Activities to try

Product and Design collaborate to create a kickoff slide deck and design the workshops.

✨ Tips

  • Consider starting with “What we’ve heard from you” to reflect back
  • Center the decision and reflect the needs and concerns and lived experiences of the people you’re working with

  1. From Erika Hall’s Let’s Do Design Research Right! workshop