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.

Navigating Nuance: Common Phrases & Pitfalls for Non-Native Speakers

Product discovery is a complex dance of understanding user needs, defining problems, and proposing solutions. For developers – particularly those whose first language isn’t English – the terminology can feel overwhelming, laden with subtle differences in meaning and usage. It’s not just about knowing what something means; it’s about using it correctly in context to communicate effectively within a team. Let’s look at some frequent pitfalls and how to approach them.

One common area of confusion stems from the difference between “problem” and “need.” Often, someone might say, “Users are having a problem with X.” While technically correct, it can sound overly critical or imply a fundamental flaw in the product’s design. A more constructive phrasing would be, “Users have expressed a need for Y – they’re struggling to accomplish Z.” Framing needs as opportunities for solutions is often received much better. Similarly, when discussing user journeys, avoid simply stating “users go here.” Instead, describe the intent behind their actions: “Users are attempting to achieve [goal] and encountering [obstacle].” This highlights the underlying motivation and allows for more targeted interventions. Another frequent issue arises with overly technical language during discussions about non-technical users. It’s crucial to translate technical jargon into accessible terms – think “bandwidth” versus “data usage,” or “latency” versus “speed.”

Furthermore, be mindful of the level of formality when communicating. Slack messages should generally be more casual than a PR description. A Slack message like, “Fix this bug!” is direct but potentially abrasive. A better approach would be: “Hey team, could we investigate the reported issue with [specific functionality]? Let’s prioritize finding a solution.” Conversely, in a pull request description for a larger feature, precision and detail are paramount. Use active voice and clearly articulate why you’re making the changes – connect them back to the user need or opportunity identified during discovery. Pay attention to verbs – “implement” versus “build,” “resolve” versus “address.”

Finally, don’t be afraid to ask for clarification! It’s far better to admit you don’t understand something than to proceed based on a misinterpretation. Most teams are genuinely supportive and willing to explain things further. A simple question like “Could you elaborate on what you mean by ‘low-hanging fruit’ in this context?” can be incredibly valuable.

# Example: Analyzing user session data with Amplitude
amplitude hit track 'user_login' -event_name 'login_success' -properties {'session_duration': 120}

This command demonstrates a common scenario – tracking user behavior to understand how users are interacting with the product and identify areas for improvement. The key vocabulary here – “track,” “event,” “properties” – is frequently used when discussing data-driven decision making in product discovery.