Make the product decision clear before the agent builds.
Define the problem, review the proposed behavior, and resolve the choices that matter. Carry the agreed decision into implementation—and revisit it when new evidence appears.
Illustrative scenario · all numbers and product context are synthetic
Make address entry easier—or ask for it later?
The request is “Reduce signup abandonment at the address step.” The agent proposes autocomplete. Before approving it, the product owner needs to decide whether that is the right change to test.
The request
Reduce abandonment at the address step.
Agent proposes
“Add autocomplete.”
A proposed implementation
Product owner asks
“Do we need the address now?”
Remove it
How would we arrange the shipment without a delivery address?
Ask later
Shorter signup. Another step to complete before shipment.
Chosen experiment
Make entry easier
Try address suggestions. Keep manual entry as a fallback.
Try this first. Revisit if abandonment doesn’t improve.
What the observations suggest
- E1 · Funnel summary: 35% of users leave at step 3, the address form.
- E2 · Usability summary: 6 of 8 participants hesitate while entering six address fields.
Entry effort may contribute to abandonment. These observations do not prove that autocomplete will solve it.
What the owner brings to the review
In this scenario, signup includes arranging a first shipment. A delivery address is required before that shipment can proceed, and the product already has an address lookup service.
This context informs the choice. It is an illustrative product rule, not a universal reason to collect addresses at signup.
The owner’s decision and reasoning
Try address suggestions with an editable manual fallback. In this illustrative product, a delivery address is required for the first shipment, and an address lookup service already exists. The owner chooses to test reducing entry effort while preserving address collection. Deferring collection remains an option if this does not help.
Reopen the decision: if entry becomes easier but abandonment does not improve, investigate whether collecting the address at this point is itself the problem.
See the resulting intent.md
Illustrative targets and checks, not measured results or authorization to implement.
- Objective
- Reduce abandonment at the address step. The hypothesis is that manual entry effort contributes to drop-off; the observations do not establish the cause.
- Outcomes
- Users can select an address suggestion, correct it, or complete the step manually. Test a relative 40% reduction in step-3 drop-off: from an illustrative 35% baseline to 21% or less.
- Evidence
- E1: synthetic funnel summary, 35% step-3 drop-off. E2: synthetic usability summary, hesitation in 6 of 8 sessions. These are illustrative inputs, not customer results. Real private sources stay outside Git; use safe summaries and references.
- Constraints
- Keep manual address entry available. Do not change authentication or payment behavior.
- Scope
- In scope: address entry, suggestion selection, manual fallback, and step-3 measurement. Out of scope: other signup steps and changes to when a delivery address is required.
- Edge cases
- If lookup times out, fails, or returns no match, users can finish manually without losing entered text. PO boxes remain enterable.
- Health metrics
- Monitor completion of steps 1–2 and the rate of addresses needing correction before shipment. The rollout should not worsen either compared with the control group.
- Verification
- Test suggestion selection and editing: the submitted address matches the user’s final input. Test lookup failure and no-match responses: manual submission still succeeds and entered text remains. In a controlled rollout, compare step-3 drop-off and health metrics before deciding whether to expand.
What to record in an IntentSpec
Make consequential product decisions explicit. Keep implementation questions and new findings visible as the work develops.
Objective
The user problem and why it matters. Distinguish observations from your explanation of them.
Outcomes
Observable changes that would indicate success. Mark targets as targets, not measured results.
Evidence
The source or assumption behind a claim. Keep private material outside Git and carry safe references.
Constraints
Hard boundaries the implementation must respect.
Scope
What the implementation may change and what it must leave alone.
Edge cases
Failure modes and boundary conditions that need an explicit behavior.
Health metrics
What must not worsen while you pursue the outcome.
Verification
Checks with expected results, plus measurements of the outcome after shipping.
Alongside these fields, keep the chosen approach, alternatives, reasons, and unresolved questions. A draft can be useful before every answer is known.
From proposal to an agreed build
- 1
Start with the request
Keep the brief in your existing ticket, document, or thread. Include relevant evidence or label assumptions. Your engineer gives the request to the coding agent, which drafts a proposal and attaches the original request for review.
- 2
Review and resolve the choices
The product decision-maker compares the proposed behavior with the original need. Discuss alternatives, explain trade-offs, and send corrections back to the engineer’s agent. A question can come from anyone in the team.
- 3
Approve the revised proposal
Review the updated proposal before authorizing implementation. In Pathmode’s repository workflow, approval identifies the person and exact proposal revision. Sending a correction is not approval; a material change needs a fresh decision.
- 4
Check the build and revisit the decision
Implementation findings can reopen an assumption or choice. With GitHub connected and the pull request linked, Pathmode reviews the merged changes against the spec. That check is advisory. Measurements after shipping help establish whether the user outcome improved.
A passing implementation check does not establish that the product decision was right. The team still judges the result and decides what to change next.
Complementary questions for building with AI
These practices overlap. Use them together to make the request, context, specified behavior, and reasons easier to understand.
| Practice | A useful question |
|---|---|
| Prompt engineering | How should we ask? |
| Context engineering | What information does the agent need? |
| Spec-driven development | What behavior and constraints are we specifying? |
| Product judgment | Why this change, which trade-offs, and who agrees? |
Questions before you start
- Can I start with an idea and no evidence?
- Yes. Record the idea as a hypothesis and say what you do not yet know. Evidence can help you judge the proposal when it is available; it is not required to enter review. An attached ticket or an AI recommendation does not prove that a solution will work.
- Do I need a tool to do intent engineering?
- No. You can review a proposal in a document and keep the agreed decisions in intent.md. The template on this page is a starting point. Pathmode connects the original request, proposal, corrections, and approval so the team can see which version was agreed.
- What does an IntentSpec include?
- The eight areas shown here are objective, outcomes, evidence, constraints, scope, edge cases, health metrics, and verification. Record the choices and unresolved questions behind them too. These are prompts for a useful review, not a guarantee that every question has been answered.
- Who makes the product decision?
- The person responsible for the intended behavior makes the call, with input from design, research, and engineering. The engineer and coding agent can draft the proposal. The product decision-maker reviews it, resolves consequential choices, and approves the revised proposal before implementation.
Try it on a decision you’re facing
Use the template to record the decision and open questions. The free preflight can flag missing or unconfirmed information; it does not decide whether your choice is right.
Review the proposal with your team
Pathmode puts the original request beside the agent’s proposal. Resolve the choices, send corrections back, and approve the revised proposal before implementation.
Create your account