Problem Discovery

“The work you do to decide what to build”

Teresa Torres

Objective¶

Build an in-depth understanding of the stated problem and it’s context. This may include, but will not be limited to:

who does the problem affect?
what is the extent of the problem?
is the stated problem the right problem?
what assumptions are inherent in the stated problem?
what value might solving the problem bring?
what risks does solving the problem present?
what dependencies are inherent in the problem or pathways to a solution?
the viability of existing solution ideas.

Discovery Planning¶

In an ideal world, discovery runs continuously alongside design and implementation. When done effectively, continuous discovery informs problem definition and prioritisation iteratively, and on an ongoing basis.

In practice, problems often arise which take work to understand. Planning how you will go about understanding the problem, who will contribute, and how you will measure the results of your discovery activities are all essential steps that need to happen before you can start effectively planning a solution.

We strongly recommend planning discovery with colleagues who can bring different perspectives and expertise to the conversation. Consider forming a product trio – a Product Manager, a UX Designer and a Software Engineer – to build an understanding of what you’re trying to achieve, together. Depending on the problem you’re trying to solve, it may also be effective to extend the trio and bring in a colleague from another part of the business.

Discovery activities should be selected based on what information you’re looking to acquire, and the viable avenues open to you. Some activities result in qualitative feedback, some quantitative, some offer subjectivity, some objectivity, and some are tools for sorting known information.

Discovery activities you may wish to consider include:

stakeholder workshops
surveys
user interviews
usability testing
A/B tests
customer journey mapping
assumption mapping
competitor analyses
customer visits
reviewing usability metrics
reviewing Support feedback
root cause analysis
opportunity solution trees

Discovery Outputs¶

Any documentation you create as part of your discovery activities, along with your findings, should be saved centrally and shared with identified stakeholders. Your findings should be used to inform both your problem definition and solution requirements.

Responsibilities¶

Owner	Responsibility
Problem Owner	The person accountable for ensuring effective discovery is conducted
Product Lead	The person responsible for conducting discovery activities to understand business and customer needs
UX Lead	The person responsible for conducting discovery activities to understand user needs (this may be the Product Lead where UX resource is limited)
Engineering Owner	The person responsible for conducting technical discovery, e.g. understanding the limitations of current solutions, and exploring new technologies

Triggers¶

Discovery should never be limited to a single point in time, however it is essential to ensure effective discovery has been conducted before:

Finalising the problem definition and defining your success measures
Attempting to describe requirements or begin solution design
Implementing solution design (use discovery activities to check your solution will be effective first)

Tooling¶

Toolkit