Discovery
Current state analysis
Map how the work happens today — end users and their pain points, the other people with a stake, and the systems that hold the work — with a research plan for anything still assumed.
Pre-requisites
- A clear challenge statement or outcome to scope against
- Any existing research about how the work happens today
What you'll get
- Research findings covering end users, internal users and decision makers
- A challenge statement framing the problem
- A user research plan aimed at your biggest assumptions
- An environmental scan with cited sources
Starting Discovery
A good solution has to work on three fronts at once: user desirability (people actually want it), technology feasibility (you can realistically build it), and organizational viability (your organization can fund, run, and sustain it).
The trap is looking through only the lens you know best. Technical people can assume the tech is the whole game; policy people can fixate on organizational constraints. Either way, it's easy to miss the forest for the trees. Holding all three together is the goal of product management. In AI Workbench, we'll guide you through the full product management process.
Most failed technology projects skipped this step: they designed a solution for how someone imagined the work happens, not how it actually happens. This activity builds the evidence base — in three passes.
End users — the people the service exists for. What are they trying to get done, and where does today's process hurt? Just as important: who gets excluded by the current way of working.
Other interest holders — the staff who run the service, the people who can approve or kill a project, the technical folks, operations. A solution end users love can still die because a decision maker was never brought along or the operations team can't run it.
Current technology — the tools that hold the work today. Whatever gets built next has to live alongside (or replace) them, so we list them now, while it's cheap.
Known vs. assumed
Throughout, we keep one honest distinction: what do we know (someone actually asked) versus what do we assume? Assumptions aren't failures — they become a research plan you can go run: who to talk to, what to ask, what answer would change our direction. Come back with what you heard and we'll fold it in.
Further Reading
- - Shows how to research, map, validate, and communicate the current user experience.
- - Identifies decision makers, affected groups, power dynamics, priorities, and engagement needs.
- - Inventories current systems, dependencies, risks, skills, contracts, costs, and maintenance capacity.
- - Gives a semi-structured interview method for understanding roles, needs, assumptions, and success measures.
- - Uses observation at work to uncover hidden needs and interactions between tools.
- - Maps people, forces, relationships, evidence gaps, and opportunities within a complex system.
- - Structures an environmental scan of related agencies, services, patterns, gaps, and opportunities.
- - Covers likely users, current behaviours, pain points, service providers, evidence, and inclusive research.
- - Maps service landscapes and user experiences to expose gaps, duplication, dead ends, and ownership boundaries.
- - Connects early research, journey maps, accessibility, inclusion, testing, and evidence-based decisions.
- - Understanding user needs, building good services, sustaining technology teams.
- - Identifies exclusion caused by mismatched experiences and uses human diversity to expose unmet needs.
- - Defines criteria for assessing open software, data, AI systems, and content during an environmental scan.
- - Links a proposed change to an expected outcome, measurable signal, experiment, and potential harm.
- - Frames success through user needs, iteration, accessibility, trust, stewardship, collaboration, and openness.