Discovery has to go beyond the AI prototype

A working prototype can change the tone of a meeting. Once people can click through a proposed product, the conversation often becomes more specific. They notice missing information, question a sequence, or suggest a better way to complete a task. That is one of the reasons I value prototyping.

AI-assisted development makes it possible to reach that point sooner. It also makes a prototype easier to mistake for evidence about demand. The team has shown that an idea can take a visible form. It still needs to understand whether the idea belongs in someone's working life.

I want discovery to keep those questions separate. A prototype can help test an assumption, but the team should know which assumption it addresses. Otherwise, we can move quickly through a demonstration and emerge with more confidence than the evidence supports.

Write down what the prototype cannot tell you

Imagine a prototype that turns a rough project description into a task plan. The experience may feel impressive. It can create organized sections, suggest dependencies, and make the next step look obvious.

What has the team learned? It may have learned that the concept is understandable and that a generated plan can fit a particular interface. It has not necessarily learned whether the plan reflects the user's actual commitments, whether important constraints are missing, or whether the user would rely on it during real work.

I would record those unanswered questions beside the prototype. This is a simple way to keep feasibility, usability, and value from becoming one vague judgment. It also helps stakeholders contribute more precise feedback.

The GOV.UK discovery guidance emphasizes understanding users, their goals, and constraints before committing to a service. I find that orientation useful when a proposed solution arrives before a clear account of the problem.

Look at the work before asking for reactions

Asking someone whether they like a proposed feature can produce an enthusiastic conversation with little decision value. People can imagine using many things. I want to understand what they currently do when the relevant situation occurs.

For the task-plan example, I would ask about a recent planning activity. What information was available? What changed after the initial plan? Which decisions needed another person? Where did the planner go to check a detail? What happened when the plan was incomplete?

These questions do not require the user to become a product designer. They give the team a view of the existing workflow and its practical constraints. The prototype can then be introduced as a specific possibility to examine against that context.

This sequence also makes disagreement more useful. A user who rejects the prototype may be identifying a real mismatch rather than resisting a new tool. Understanding that mismatch can be more valuable than collecting positive reactions.

Investigate both sides of a connected experience

Eyecandi involved a concept connecting online eyewear browsing with a visit to a local practice. My role included product strategy, research, UX direction, and technical planning with the team. The work remained a concept-validation engagement.

The product had to make sense for consumers and participating practices. Helping someone shortlist eyewear online would mean little if the next step created confusion or unsupported manual work at the practice. That relationship shaped the initial scope around discovery, shortlisting, and a useful visit.

The same consideration applies to AI opportunities. A tool may save time for the person generating an output while creating more verification work for the person receiving it. An automatically drafted task plan may need review by a manager who lacks the context to check it efficiently.

I would include those downstream participants in discovery. Their work helps define whether the proposed improvement holds across the service, and whether a smaller intervention would fit better.

Test the assumption with the highest decision value

A team can spend a long time refining a prototype that addresses a relatively minor uncertainty. It might polish the interaction before finding out whether the required source information exists or whether the proposed workflow has a responsible owner.

I would list the assumptions that could change the product decision and choose an appropriate way to investigate each. Some need observation or interviews. Others need an engineering investigation, a content audit, or a simple manual trial. A prototype is one method among those choices.

For the hypothetical planning tool, the most important early question might be whether users can provide enough reliable context. A small exercise using fictional but realistic project material could reveal the missing inputs. That finding might lead to a structured intake flow before any generated plan.

The experiment needs a decision attached to it. If the source information is too incomplete, do we narrow the task, change the input, or stop? Without that connection, discovery can produce observations that never affect the product.

Keep the evidence separate from the performance

A demonstration is usually arranged to communicate an idea clearly. Research needs room for hesitation, unexpected behavior, and failure. Mixing the two can hide what the team needs to learn.

I would avoid helping participants through every difficult moment. If a user cannot tell what the feature has done, that matters. If they accept a generated plan without understanding its assumptions, that matters too. The team needs to observe the behavior rather than explain it away.

Afterward, I would distinguish what happened from my interpretation. “The participant opened the source twice before accepting the plan” is an observation. “The source link increased trust” is an interpretation that may need further investigation. The distinction keeps a small study from carrying a larger claim than it can support.

AI can help organize notes or generate questions, but the team remains responsible for checking those outputs against the original material. Discovery evidence should retain a clear connection to what people actually said and did.

Let discovery change the proposed product

The point of discovery is to improve the decision. Sometimes that leads to an AI feature. Sometimes it leads to a simpler workflow, clearer content, or a different problem worth addressing first.

I would look for a concise explanation of the next commitment: who the product serves, what difficulty it addresses, what the team has learned, and what remains uncertain. The initial release should reflect that evidence. It should not carry every capability shown in an early prototype just because those screens already exist.

That approach fits how I think about product work more broadly. Research, design, technical planning, and delivery inform one another. A prototype helps those conversations become concrete, but its value depends on the question it helps answer.

AI gives teams more ways to explore an idea quickly. Discovery gives that exploration direction. The useful result is a clearer understanding of what deserves to be built and a more honest account of why.