Discovery Phase

Before you commit to building a product or service, the team needs to understand the problem that needs to be solved and who it needs to be solved for.

That means learning about:

who your various sets of users are - for example, a business stakeholder who is receiving the data processed by your tool, which is owned by the inventory team
your users and their goals
the underlying policy intent you’ve been set up to address - commonly, the client’s contract objectives
constraints you may face making changes to how the product or service is run - for example, because of technology or legislation
what work has been done before - for example, has there been research into this problem space before?
opportunities to improve process and collaborate - by sharing data with other teams, for example

While there are many activities that can take place during discovery, the following activities are foundational:

Exploratory research, where we gain a deep understanding of:
- business needs
- user goals
- technical needs of a proposed product
Evaluative research, where we test and prioritize solutions through deep empathy for business, users, and technology.

You should not start building your service in discovery, but you can start laying the technical foundations of the service. Before doing so, however, it’s important to be aware of any compliance requirements and understand potential integrations with the client’s existing technical solutions.

What you learn during discovery can help you work out whether you want to move forward to a prototyping phase where you are evaluating possible solutions or hypotheses to solve the problem you identified in discovery.

How Long Should an Initial Discovery Take

There’s not a prescribed time period for an initial discovery phase, as the scope and complexity of the problems you are trying to solve and project constraints will impact how long you spend on discovery. Depending on the project, the initial discovery phase may last a few weeks or a few months. However, if there is a significant constraint on time due to contractual obligations or client expectations, it’s vital to discuss how that and other constraints will affect the scope of research and to set reasonable expectations upfront.

Factors that impact the length of discovery:

Size and makeup of your team
Client’s ability and comfort level enabling discovery
Knowledge of the problem space
Existing research (or lack thereof)
Number of known stakeholders and users who will be involved in discovery
Ease of access or scheduling
External and internal conditions outside of your control (ex. sudden policy changes)

Examples of lengths of discovery we’ve had:

6 month discovery in a 12 month base contract with 12 month option year
3 month discovery in a 9 month base contract with 12 month option year
5 weeks of discovery in a 12 week contract solely focused on discovery and prototyping

Although you will repeat discovery continuously throughout a product lifecycle, it’s important to timebox it in the initial phase.

Set a Goal for Your Discovery

It’s useful to start by setting a clear goal for your discovery. This will help you scope your discovery appropriately and work out when it’s finished.

How to Set Goals

As a team, determine goals for discovery, including when discovery is “done”. These may flex a bit over the course of discovery, but seek to set clear, achievable goals. For example, one goal or definition of done might be:

We understand the types of problems end-users have with paper forms.
We have a picture of the range of complexity across paper forms.

Note: discovery is a continuous process throughout the product development lifecycle as we will be looking to respond to changing user needs, business goals, and the product landscape. The goal of this initial discovery is to ask ourselves “what does the team need to learn in order to make research-informed decisions on how to move forward?” and “how can we deliver and test ideas with users?”

Define the Problem

At the start of your discovery, you might be presented with a pre-defined solution by a client stakeholder. For example, the problem is not: “We need to build an interactive map to show people where our offices are.” It’s probably something like: “People have a hard time finding the offices nearest to them when they need to book face-to-face appointments.”

Before you start your research, you’ll need to interrogate that solution and reframe it as a problem to be solved. This will help you better understand what your team has been set up to achieve.

Break down assumptions and ask lots of questions. Reframing the problem also includes agreeing what is not part of the problem.

So start by defining the problem you’re working on. The better you define it, the better the potential solutions you’ll end up with.

Also consider quantifying the value/impact of solving the problem you’ve been set up to address. During discovery, that means understanding how much the problem is currently costing or impacting the users, workflows, and/or systems. Understanding this and aligning across teams, stakeholders, and clients, will help focus everyone on how to weigh the trade-offs you uncover during our research and development.

Here are some helpful resources to guide setting goals:

The Actual Problems to be Solved by Kate Tarling
An in depth guide to measuring the benefits of your service from gov.uk

What to Find Out in Discovery

Once you’ve set a goal for your discovery and understand the problem you’re looking into, you’re ready to define research questions and begin research. Read more about the difference between research and interview questions.

Research Questions

Research questions will articulate the key questions the team seeks to answer during the discovery phase, in service of the client/project goals.

Here are examples of research questions:

Research Questions are Not Interview Questions by Erika Hall

As you articulate your research questions, be sure to focus on areas such as the following:

learning about your users and their context
understanding the constraints that affect your problem (e.g. technical, policy, people, etc.)
unpacking the wider context, including existing systems, programs, competitors, etc. that impact your users and goals
identifying opportunities and barriers

While discovery is most effective when there is cross-practice participation, there may be certain practices or skill sets best suited to leading certain areas of inquiry. For example:

Understanding user needs is often led by design
Understanding the market, product/business landscape, and product analytics is often led by product. This includes understanding policy requirements and competitors, and developing product analytics
Understanding the technical landscape is often led by engineering. This may include learning how to deploy a guide-wire app in the client environment, documenting other neighboring apps and integration points, or gathering security requirements (ex. Authority to Operate).

Understanding Users and Their Context

Start by learning about your users and their context. This means understanding what the user’s trying to achieve and how they go about doing it.

When you dig into this, you’ll often find the thing you’re working on is part of a bigger process or user journey.

Understanding context includes developing a picture of what that wider journey looks like - for example, by creating a service design blueprint of a user’s journey and the systems and programs that exist in a wider context.

As you build out your map, you’ll probably notice that the problem spans across multiple departments, people, and systems. Spend some time during discovery learning from those other teams and organizations.

Accessibility and Inclusion Practices

You’ll also need to learn enough about your users’ accessibility requirements to let you work out whether the problem space you’re looking at presents any particular challenges from an inclusion point of view. Government clients require section 508 compliance for all government software. We strive to maintain a minimum level of accessibility for all products delivered from Truss.

Bear in mind that, in the US, 1 in 4 people have some kind of disability. And that accessibility covers a range of other needs for people who do not have a disability. When you design for disabilities, you make things better for everyone in the process.

You’ll also need to think about things like your users’ digital skills, devices they have access to, and internet access (i.e. in rural US, “nearly one fourth of the population lack access to fixed broadband service at threshold speeds”).

Fill out an initial Accessibility Scorecard as part of your discovery. Re-evaluate the scorecard each quarter thereafter.

Understanding Constraints

You’ll need to understand any constraints you’re likely to come up against if you were to move on to the prototyping phase. This includes constraints due to:

users
legislation/policy
contractual obligations (such as imposed milestones or deliverables)
legacy technology or technical requirements
existing processes and systems
client staffing or skill set constraints (such as for maintaining a product or service in future)

There are multiple kinds of constraints: hard and soft.

You will not be able to do much about hard constraints. For example, congressional legislation is not something that can easily be changed. But as you move on to other phases, you’d need to find a way of delivering a service that still works for your users.

Soft constraints may be changeable. For instance, if existing processes (for example, an existing technical stack requirement) are preventing you from delivering the best version of your service, you’ll need to work to change those processes - not just work around them and think “it’ll work out.”

Understanding constraints is helpful for two main reasons. First, it helps you work out how to continue to future phases. If there’s a hard constraint which means you are not able to improve on the solution that’s currently available, this is crucial to communicate with your team and client to determine how to move forward.

The second reason is that it can help you prioritize your risky assumptions as you continue on. For example, if a service will only be viable if you can change an existing process or structure, you’d want to focus on ways of doing that.

You could also look at related or similar services, to understand the constraints they face and how they dealt with them.

How to Identify Constraints

Unlike risks, constraints have a clear impact on your work. A risk might happen and you need to assess how likely that is to occur, the potential impact if it does, and what you might do in case it happens (i.e. mitigation plans). Constraints can be identified and will shape your solution ideas and help the team understand what might be more/less feasible, valuable or impactful.

An exercise that will help your team explore what are hard and soft constraints is the Sphere of Influence exercise in the Project Toolkit.

Identify Improvements You Might Be Able to Make

One of the benefits of understanding the user’s wider journey and who’s involved in delivering it is that you can spot things that could be improved. You could take these improvements on to later development phases and raise them to major stakeholders.

For example, your discovery research might reveal that another part of the company or government is already collecting the personal information you need from your users. If you decide to go ahead and build a service, reusing that data would prevent users from having to provide the same information multiple times.

In that case, you could spend part of your framing process evaluating the technical and legal challenges of reusing that data in your product or service rather than the challenges of collecting it.

Your research might also lead you to consider alternatives to building a service. For example, you might be able to solve the problem more effectively (or less expensively) by publishing website content, giving improved information to face-to-face advisors or making data or an Application Programming Interface (API) available to third parties. This is a good time to align with your team and clients to determine how you move forward.

How You’ll Measure Success

Early on, you should establish how your client defines success and work with your client to identify measurable success metrics that align with their goals. This will enable you to measure success when you are ready to start validating potential solutions.

During the discovery phase, try to establish baselines for their current products, services, or processes for those success metrics so that you have a starting point from which to measure success of your future prototyping and beta phases.

In addition, you’ll need to consider:

what data you’ll collect to measure service performance
what performance metrics you’ll use to understand if the service is working for users
what frameworks will work for you and the client

“Help people follow us” and “Build alliances” are two core Truss values. The way teams demonstrate this is to work openly and transparently both within our Truss teams and with our clients and partners. You can follow this by proactively sharing research, inviting participation, asking clarifying questions, and speaking candidly with kindness.

This is especially crucial during research phases. Not every team member can be in every single research activity; you will likely have multiple workstreams of discovery going at the same time. Team members should share what they’ve learned across the team to encourage a common understanding of the project. Share outs might include documentation, demos, synthesis sessions, or discussions. A benefit to sharing your work early and often is that is also helps your team develop trust and confidence with our users, stakeholders, clients, and Trussels. This all leads to “Make good coffee.”

At a minimum, you must share out work with your team and stakeholders.

Transparent Communication Examples

Post to internal client sites where clients can follow along. (See example from Managed Care Review where business owners across CMCS can view the project and progress)
Post findings publicly in shared Slack channels, etc. to work transparently and inform clients and other vendors
Utilize a centralized repository to hold all recorded interviews, workshops, document reviews, etc. in a tool like Dovetail or Confluence
Provide your team and clients with short readouts during discovery to share what we’re hearing
Create a Google Drive folder for shared documents in the Truss “Public” directory

Unless confidentiality issues mean you cannot, talk publicly about what you’re learning. You could do this by publishing blog posts or running open show and tells. You can usually ask your project’s delivery manager or client success manager about what information can be publicly shared.

This helps people across and outside your organization know what you’re doing and makes it easier to collaborate with the other organizations working in your problem space.

How You Know Discovery is Finished

You will want to develop a definitions of done for your initial period of discovery on a new project. For example, this will likely include that you:

understand the client’s business objectives and who the users are
have defined and validated the problem(s) you are trying to solve for your users
understand the wider context and know the other services, teams, competitors, and organizations working on similar problems
understand the technical landscape and the technical and policy constraints
have a list of solution ideas you’d like to test at alpha and an idea of which one you’d like to test first
identify how you’ll define and measure success to validate ideas during the alpha phase

Here is an exercise you can use to determine a definition of done for Discovery. Your initial round of discovery might conclude when you achieve your stated discovery goals and decide to validate and refine your solution ideas through alpha testing, but the discovery process does not end there for a project team. You should make discovery a continuous, repeatable process.

Access and Research into Systems

As contractors, access to client systems and documentation may be slow, and it’s best to start this process early.

Begin with organization wide systems, which may be hard constraints. For example, organizations may require use of a single sign-on solution (like login.gov). As discovery progresses, and problems become more defined, look deeper into the systems affecting those problems or ones that are adjacent. For example, you may require access to an existing data platform for use or migration. Starting this work early will allow you to get access in time to inform constraints and timelines for most effective solutions.

Preparing for Prototyping

Your initial discovery is finished when you’ve decided whether or not you are ready to move on to prototyping. There a few factors that play into this decision, including whether:

there’s a viable service you could build that would make it easier for users to do the thing they need to do
it’s cost effective to pursue the problem - this means weighing up how much it’d cost against how much of an improvement you think you could make
It’s not a failure to realize at the end of the discovery phase that your research shows what you were tasked with is not the best thing to do. This is a great time to align with the internal and client/partner teams to discuss what you have found and where to go from here.

## Related guides

You may find these guides useful:

Source Credit: This content is an edited reprint from the GOV.UK Service Manual under the terms of the Open Government Licence v3.0.