AI product-market fit and market research

Customer and workflow research

Decide how the target workflow actually runs and where an AI product could fit

A product concept depends on assumptions about how a task is performed that nobody has checked. The decision is how the target workflow actually runs and where an AI product could fit. The work starts from the steps, the decisions, the inputs people gather informally and the consequences of each type of error and ends with a workflow model with observed decision points, exceptions and candidate intervention points. It is most relevant to product managers and designers grounding an AI product in real work. A useful result states what was examined, what remains uncertain and which decision the evidence can support.

Decide how the target workflow actually runs and where an AI product could fit

Starting pointObserved step
The starting condition this work depends on.
ExaminationDecision point
Where the consequence actually arises.
DecisionIntervention point
The finding and its open dependencies.
Proposed working model, not exhaustive coverage.

Decision

Frame the decision before scoping the work

Questions and the evidence each one needs

Question / evidenceObserved step
Inspect access to practitioners and their managers.
Question / evidenceDecision point
Inspect the documented process, where one exists.
Question / evidenceIntervention point
Inspect system records showing how the work actually flows.
Read each question against evidence already available.

The decision is how the target workflow actually runs and where an AI product could fit. This matters to product managers and designers grounding an AI product in real work when a product concept depends on assumptions about how a task is performed that nobody has checked. Name the affected proposition, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.

The specific failure hypothesis is that the documented process omits the judgement step where the practitioner’s real expertise is applied. It stays a hypothesis until it is examined in your own case. Existing research notes, usage data or customer records may already resolve it, so identify the uncovered question before commissioning further work.

Mechanism

Follow the relationship that carries the consequence

Where the boundary is actually crossed

SourceObserved step
The condition the design assumes.
CrossingDecision point
Where authority or information changes hands.
ConsequenceIntervention point
The effect the owner must answer for.
Evidence comes from what people did, not from the plan.

What this specialty examines

Customer and workflow research rests on the steps, the decisions, the inputs people gather informally and the consequences of each type of error. Work from what people actually did and said rather than from the plan’s description of them, and record where the two differ.

The examination draws on access to practitioners and their managers; the documented process, where one exists; and system records showing how the work actually flows. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.

The tradeoff to make explicit

The tradeoff here is automating the volume of routine cases against handling the exceptions that carry the cost. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.

Preparation

Connect the inputs to the boundary examined

Preparation record for the engagement

Illustrative working format

BasisAccess to practitioners and their managers
Bounds the context.
MaterialThe documented process, where one exists
Supplies the material examined.
ConditionSystem records showing how the work actually flows
Exposes conditions that qualify a result.
Illustrative record; availability and handling need confirmation.

Start with access to practitioners and their managers; the documented process, where one exists; and system records showing how the work actually flows. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.

The scope also needs product managers and designers grounding an AI product in real work with the authority to reach the relevant participants, and agreement on what evidence would distinguish the failure in which the documented process omits the judgement step where the practitioner’s real expertise is applied from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.

Working sequence

Carry the question through to an accountable finding

From scoped material to a decision record

  1. EstablishRecruit and prepare

    Set the conditions assumed.

  2. ExamineStudy the work

    Apply the scoped check.

  3. RetainModel the workflow

    Record evidence and the next decision.

Proposed sequence; resolve access gaps first.

Recruit and prepare

Select participants across experience levels and sites, agree consent and handling, and prepare a protocol that observes rather than leads. Record what is deliberately excluded.

Study the work

Walk through real cases, recording steps, tools, informal inputs, decision points, exceptions and the time each consumes. Keep an unreproducible observation in the record with its reason.

Model the workflow

Produce a workflow model that shows where judgement, verification and accountability sit, and where an AI step would need oversight. Hand the result over with its open dependencies attached.

Indicative artefact

Make the artefact usable by the person who owns the decision

A workflow model with observed decision points, exceptions and candidate intervention points

Illustrative working format

Annotated fieldParticipant selection and research protocol
What was examined, and under which assumptions.
Annotated fieldObserved steps, exceptions and informal inputs
Each observation, linked to evidence.
Annotated fieldCandidate intervention points with oversight requirements
The next decision, and its limits.
Illustrative structure, not a completed engagement.

The proposed decision artefact is a workflow model with observed decision points, exceptions and candidate intervention points. Depending on the agreed scope, the pack may include:

  • Participant selection and research protocol. Basis: the definitions, boundaries and assumptions another reviewer would need.

  • Observed steps, exceptions and informal inputs. Observation: the findings and their interpretation, preserving adverse results and disagreement.

  • Candidate intervention points with oversight requirements. Decision: what the owner could do next, and what change would justify revisiting it.

Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.

Illustrative scenario

Examine the question through a constructed case

A constructed case and its decision paths

Illustrative scenario

  1. SituationObserved step

    A documented three-step approval turns out to involve a phone call that resolves most ambiguous cases.

  2. Question to examineDecision point

    What information does that call surface, and could any product step replace or support it?

  3. Conditional next actionIntervention point

    Design around the call rather than around the documented process.

Fictional example; no engagement or outcome is implied.

Consider an illustrative situation: a documented three-step approval turns out to involve a phone call that resolves most ambiguous cases. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.

The question to examine is what information does that call surface, and could any product step replace or support it. A reasonable next action would be to design around the call rather than around the documented process. The decision record should state which configuration was accepted and which limitations came with it.

Scope and next action

Keep the conclusion inside the agreed boundary

Confirm fit before the next commitment

Included boundaryObserved step
Limited to the agreed scope and sample.
PrerequisiteAccess to practitioners and their managers
The owner confirms access and conditions.
Claim limitIntervention point
Workflow research describes the cases and participants observed. It does not establish how the whole population works.
Bring the triggering change and the evidence you hold.

Workflow research describes the cases and participants observed. It does not establish how the whole population works. Any engagement depends on an agreed scope, a qualified team and authorised access.

Bring the proposition, the decision you face and the evidence you already hold. The scope question follows from the situation in which a product concept depends on assumptions about how a task is performed that nobody has checked. Confirm which missing observation would change the owner’s next action.

A little more clarity

Questions to consider.

Start with the questions that shape a better decision.

When is customer and workflow research the right work?

It suits product managers and designers grounding an AI product in real work when a product concept depends on assumptions about how a task is performed that nobody has checked. Stated plainly, the decision it supports is how the target workflow actually runs and where an AI product could fit. If none of that applies yet, a shorter framing conversation is more useful than a scoped engagement.

What would our team need to provide?

Start with access to practitioners and their managers; the documented process, where one exists; system records showing how the work actually flows; and the exceptions, escalations and rework the team already tracks. Identify the owner, revision and operating context of each. A missing input should be recorded as an evidence gap rather than assumed to be satisfactory.

How is the scope bounded?

The work examines the steps, the decisions, the inputs people gather informally and the consequences of each type of error within an agreed boundary. Workflow research describes the cases and participants observed. It does not establish how the whole population works. State the boundary in writing before the work starts, so a later reader can distinguish what was excluded from what was missed.

What does the engagement produce?

The proposed artefact is a workflow model with observed decision points, exceptions and candidate intervention points. It carries participant selection and research protocol; observed steps, exceptions and informal inputs; and candidate intervention points with oversight requirements, with the open dependencies still attached so the owner can see what the evidence does not cover.

What if our existing evidence already answers this?

Review its scope, provenance and configuration first. Work already done by product managers and designers grounding an AI product in real work may be sufficient. Record the decision, the unresolved limitations and the change that would require another look. Further work should address a real gap.

What tradeoff should we expect to decide?

The recurring tradeoff is automating the volume of routine cases against handling the exceptions that carry the cost. Neither side is universally correct. The engagement makes the difference explicit and leaves the choice with the owner who carries its consequence.

What would make the findings inconclusive?

Missing access to practitioners and their managers; the documented process, where one exists; and system records showing how the work actually flows can prevent a reliable interpretation. Record the specific missing observation and its implication. The owner can supply the evidence, narrow the claim or defer the dependent decision; an incomplete case should not silently count as a pass.

Start with the decision you need to make.

Tell us about the agent workflow you want reviewed, and where you need greater clarity. Scope and availability are confirmed together.

Connected disciplines