Conduct Discovery

Discovery gives the Product Engineer enough understanding to define a useful product and avoid asking coding agents to solve the wrong problem. It should identify the outcome sought, the people and processes involved, material constraints, and important open decisions. The goal is a clear starting point, not an exhaustive document before anyone can explore working software.

Responsible role: Product Engineer.
Participants: Business stakeholders, intended users, domain experts; architect and UX designer when needed.
Inputs: Initial request, available process material, existing product context, known enterprise constraints.
Outputs: Problem and outcome statement, identified users/stakeholders, initial scope, major workflows, open questions, and preliminary objectives.

The Product Engineer can use a conversational AI assistant to work through a business problem while gathering information from stakeholders. Rather than starting with a long questionnaire or treating an initial feature request as complete, the Product Engineer can explain the current workflow, ask the assistant to identify assumptions, explore alternatives, and test whether the proposed solution addresses the actual problem.

The assistant may organize scattered notes into tentative workflows, surface actors who were overlooked, suggest realistic exceptions, and identify decisions that have not been made. Its contributions are proposals for investigation, not authoritative requirements. The Product Engineer validates factual claims and brings business-policy decisions back to the authorized owner.

The conversation may be spoken or typed and can continue across several sessions. Material outcomes should be preserved in project objectives, decisions, and feature specifications rather than depending on an agent's conversational memory.

A completed discovery document need not receive formal sign-off before ordinary prototyping. Begin with enough intent and appropriate technical boundaries for a useful increment; let agents maintain the record while the PE inspects outcomes. Clarify consequential unknowns with their owners before dependent risky decisions. Discovery continues through actual product feedback.

Incremental implementation is the default: agree a bounded capability, inspect the working result, and adjust before expanding. Define creative/UX, structural, functional, and content latitude explicitly, including what stays outside scope. Broad experiments and reversible prototypes can justify wider latitude when deliberately agreed. Read Defining Agentic Latitude.

1. Understand the request and actual problem. Clarify what prompted the request, who is affected, what breaks today, and why the proposed feature is thought to help.
2. Explore the workflow conversationally. Use stakeholder discussion and, where useful, a conversational AI assistant to map the normal path, decisions, handoffs, and relevant exceptions. Ask the assistant to challenge missing assumptions and compare plausible approaches.
3. Define intended outcomes. Describe what would change for the people doing the work and how success could be observed without inventing unsupported metrics.
4. Identify actors, data, and constraints. Determine permissions, external dependencies, sensitive information, existing enterprise standards, and important nonfunctional limits.
5. Separate agreed rules from open questions. Use AI to identify ambiguities, but assign consequential policy decisions to actual decision-makers. Record assumptions explicitly.
6. Summarize and validate. Turn the discussion into a concise problem statement, initial scope, outcomes, workflows, exclusions, and decision log. Confirm the consequential points with relevant stakeholders.
7. Pass validated intent into feature specification work. Maintain the clarified product knowledge in durable artifacts; do not treat the chat transcript itself as the specification.

A stakeholder requests an approval dashboard. The Product Engineer asks a conversational AI assistant to help reason through the underlying process. The assistant suggests that the actual problem may be untracked approval decisions rather than an absence of charts. It also asks who can approve, whether approvers can approve their own requests, whether rejection reasons are required, and how a requester learns the outcome.

The Product Engineer confirms these questions with stakeholders. The agreed result may be a small request-and-decision workflow without an analytics dashboard. The implementation agent should not decide approval permissions or rejection policy independently.

• What work is being performed today, and why does it need to change?
• Who initiates the process? Who may approve, reject, or correct it?
• What makes a successful outcome for the person doing the work?
• What happens when required information is missing or invalid?
• Which external systems or existing records must be involved?
• What is explicitly excluded from the initial release?
• Which decisions must be made by policy owners rather than by the development team?
• What should a stakeholder be able to demonstrate during UAT?

Discovery is sufficient to begin specification work when the business problem and intended outcomes are clear, the principal actors, workflows, and initial scope are understood, and material unresolved decisions are recorded with their responsible owners. Conversational AI may help identify assumptions and clarify options, but it does not replace stakeholder agreement or durable project documentation. Discovery can continue as working software reveals new information.

Treating a requested interface as the business objective; accepting contradictory stakeholder rules without clarification; specifying large volumes of incidental detail that working-software feedback would resolve more effectively; and assuming that a technically plausible default is an authorized policy choice.