此页面暂未提供您所用语言的版本。 经审校的译文正在准备中，您当前浏览的是英文版本。
概览
The most expensive software defect is a product nobody needs. Discovery exists to find that out early, while changing direction costs a conversation rather than a rewrite. It examines who the users are, what jobs they are trying to get done, and where current tools and processes fail them.
Our discovery work combines interviews, jobs-to-be-done analysis, service blueprinting and rapid prototyping with feasibility checks from engineers on the same team. The outcome is a product direction stakeholders can commit to, with assumptions and risks stated plainly.
业务应用
- 01
New product validation
Test whether a proposed product addresses a real, frequent and valuable problem before funding a full build, using interviews, prototypes and behavioral signals from the intended users.
- 02
Service redesign
Map end-to-end journeys across customer touchpoints, staff workflows and back-office systems with service blueprints, exposing the handoffs, policy constraints and system gaps that actually cause friction.
- 03
Roadmap reset for an existing product
Reassess a mature product's roadmap against current user needs and usage evidence, separating features that matter from accumulated requests that add complexity without adding value.
- 04
AI and automation opportunity framing
Identify where intelligent automation could genuinely improve a workflow, testing concepts with users and checking data availability and quality before anyone commits budget to model development.
工程方法
- 01
Frame the problem and constraints
We align stakeholders on the problem, target users, business objectives and non-negotiable constraints, and record the assumptions that discovery needs to test.
- 02
Research jobs to be done
Interviews and contextual observation uncover the jobs users hire products to do, the circumstances that trigger those jobs and the workarounds people rely on today.
- 03
Blueprint the service
Service blueprints connect user actions to frontstage interactions, backstage processes and supporting systems, showing where experience problems originate in operations or technology.
- 04
Prototype and test
Prototypes, from rough to high fidelity, are tested with real users in moderated sessions, while engineers assess feasibility and integration complexity in parallel.
- 05
Shape strategy and roadmap
Findings become a product direction, prioritized opportunities and a sequenced roadmap, with success measures defined and open risks documented for leadership decisions.
技术与平台
Research and synthesis
- Dovetail
- Miro
- Lookback
- Maze
- Optimal Workshop
Prototyping
- Figma
- FigJam
- ProtoPie
- Framer
Methods and frameworks
- Jobs to be done
- Service blueprinting
- Opportunity solution trees
- Lean UX
Product analytics
- Amplitude
- Mixpanel
- PostHog
- Hotjar
文中提及的技术名称均为其各自所有者的商标，并不代表任何合作或背书关系。
交付成果
- Research synthesis with jobs-to-be-done and key insights
- Current-state and future-state service blueprints
- Tested interactive prototype
- Opportunity map and prioritized product backlog
- Technical feasibility notes and architecture options
- Product strategy brief with success measures and open risks
决策者关心的问题
How is discovery different from gathering requirements?
Requirements gathering records what stakeholders ask for. Discovery asks whether those requests address the underlying problem. It tests assumptions with real users and prototypes, so the resulting backlog reflects validated needs rather than the loudest opinions in the room.
What if discovery shows we should not build the product?
Then discovery has done its job. Stopping or redirecting an initiative early is a legitimate and valuable result. We report findings candidly, including the inconvenient ones, and usually identify a narrower or adjacent opportunity that is worth pursuing instead.
Do engineers take part in discovery?
Yes. Engineers join discovery to assess feasibility, integration effort and data availability while ideas are still fluid. Their involvement keeps promising concepts from collapsing later on technical constraints, and gives the delivery team context that documents alone cannot transfer.