Product Discovery English: Workshops, User Journeys, and Problem Framing

Introduction

Product discovery is the process of figuring out what to build before you build it. Engineers who participate in discovery workshops, write problem statements, or collaborate closely with product managers need to understand the English vocabulary of this domain. Terms like user journey, pain point, jobs to be done, and opportunity space appear regularly in cross-functional meetings. Understanding them helps you contribute more effectively and advocate for user-centred approaches to technical decisions.

Problem Framing

Good discovery starts by defining the problem clearly. The vocabulary:

• problem statement — a clear articulation of the problem to be solved; “we need to write a problem statement before exploring solutions”
• frame the problem — decide how to define and bound the problem; “are we framing this as a search problem or a recommendation problem?”
• root cause — the underlying reason a problem occurs; “the root cause is that users cannot find the right filter combination, not that the filters themselves are wrong”
• symptom vs root cause — an important distinction; “high churn in the first week is a symptom; the root cause is that users don’t reach their ‘aha moment’”
• scope — the boundaries of what the team is trying to solve; “we need to be clear about the scope — are we solving this for mobile users only, or all platforms?”
• how might we… — a design thinking prompt for generating solutions; “how might we make onboarding faster for technical users?”

Engineers often push to jump to solutions before the problem is well-defined. The phrase “let’s make sure we agree on the problem before discussing solutions” is a valuable contribution to any discovery meeting.

User Research Vocabulary

Discovery involves learning about users:

• user interview — a structured conversation with a user to understand their needs and behaviours
• persona — a fictional representative user based on research; “this feature is designed for our developer persona, not the business analyst persona”
• user journey (or customer journey) — a map of the steps a user goes through to accomplish a goal; “we mapped the user journey from first sign-up to first successful API call”
• pain point — a specific problem or frustration a user experiences; “a major pain point is that users have to copy-paste credentials manually”
• jobs to be done (JTBD) — a framework that describes what users are trying to accomplish; “the job to be done is ‘get my data into the system without manual effort’”
• empathy map — a visual tool for understanding a user’s thoughts, feelings, and behaviours

The phrase “what job is the user hiring this product to do?” is the classic jobs-to-be-done question. Practising this framing helps engineers think from a user perspective rather than a technical one.

Opportunity Mapping

After research, teams identify opportunities:

• opportunity — a user need or problem that a product could address; “we identified three opportunities from the research”
• opportunity space — the range of possible opportunities; “we need to prioritise within the opportunity space”
• impact vs effort — a common prioritisation framework; “we plot opportunities on an impact vs effort matrix to decide where to focus”
• opportunity sizing — estimating how many users are affected and how significant the problem is; “we need to size this opportunity before committing resources”
• desirability, feasibility, viability — three lenses for evaluating opportunities: does the user want it, can we build it, does it make business sense?

In discovery workshops, you will hear: “Before we commit to this opportunity, let’s make sure we have validated desirability — do users actually want this, or are we assuming they do?”

Workshop Facilitation

Discovery often happens in structured workshops:

• facilitator — the person who runs the workshop and manages the process
• time-box — limit a discussion to a fixed time; “we time-box the ideation phase to 15 minutes”
• affinity mapping — grouping similar ideas or observations into clusters; “we did an affinity mapping exercise to group the research findings”
• dot voting — each participant places a limited number of dots on options they favour; a quick prioritisation technique
• diverge then converge — first generate many ideas, then narrow down to the best ones; the fundamental workshop rhythm

Key Vocabulary

Term	Definition
problem statement	A clear articulation of the problem to be solved
user journey	A map of the steps a user takes to accomplish a goal
pain point	A specific frustration or difficulty a user experiences
jobs to be done	A framework describing what outcome the user is trying to achieve
persona	A fictional representative user profile based on research
opportunity	A validated user need that a product could address
opportunity sizing	Estimating the scale and significance of an opportunity
desirability	Whether users actually want the proposed solution
time-box	Limiting a discussion or activity to a fixed duration
affinity mapping	Grouping similar items to identify patterns in research data

Practice Tips

1. Practice the “how might we” framing. Before a planning meeting, rewrite each item on your backlog as a “how might we” statement: “How might we reduce the time it takes for a new developer to make their first API call?” This forces you to think about the user goal, not just the feature.

2. Learn to use “pain point” precisely. A pain point is a specific, observable frustration — not a vague dissatisfaction. Practise describing pain points with evidence: “Users told us in interviews that copying API keys from the console is error-prone and takes several minutes — this is a significant pain point.”

3. Participate actively in discovery workshops. Use the vocabulary out loud: “I think we should time-box this discussion,” or “Can we do a dot vote to prioritise?” Using the vocabulary signals engagement and helps move meetings forward.

4. Read Teresa Torres’ “Continuous Discovery Habits.” This book is a clear, well-written English introduction to modern product discovery. It will teach you vocabulary like opportunity mapping, assumption testing, and interview techniques in the context of real product teams.

Conclusion

Product discovery vocabulary — problem statement, user journey, pain point, jobs to be done, opportunity sizing — helps engineers bridge the gap between technical work and user needs. When engineers understand and use this vocabulary, they contribute more effectively to cross-functional teams and make better decisions about what to build. The shift from “what should we build?” to “what problem are we solving?” is a fundamental one, and these terms help you articulate and navigate it.