When Customer Questions Need a Routing Layer Before They Become Engineering Work
The questionnaire was already in the customer's hands when we realized some of the questions would make engineering look unprepared. Half were missing-API questions, half were product decisions in disguise, and sending them as one list would have exported our confusion straight to the customer. The fix was not another meeting or a better spreadsheet. We needed a classification and routing step between field discovery and engineering work, so every customer question was categorized, contextualized, and tied to a decision before anyone sent it across the wall.
TL;DR
Ambiguous customer discovery becomes noisy engineering work without a classification step first. Categorize each question as engineering, product, access, architecture, or internal-only, attach the context already known, name the decision it unlocks, and hold back anything that should not be shared externally. This protects customer trust while giving engineering questions they can actually answer.
Customer questions are not raw material for engineering until someone has processed them. In field delivery work, that processing is part of the job. Skipping it is how a half-known system, a nervous customer, and an impatient implementation team turn one missing API answer into three weeks of circular motion.
Why this classification work belongs in field delivery
The customer had reasonable anxiety. Some systems were already being used without enough visibility, which meant work could be duplicated or rejected later because it violated a constraint nobody surfaced early. The delivery team had reasonable pressure: they needed access, API details, and architectural clarity to move implementation forward.
Those two pressures look compatible until they meet in a shared document.
A raw questionnaire flattens everything. A question about authentication sits next to a question about roadmap ownership. A request for an endpoint sits next to a request for product intent. A vendor-specific implementation detail sits next to a customer architectural decision. To the document, they are all rows. To the relationship, they are very different objects.
The problem was not that the engineering team was unwilling to help. We were about to ask them questions that mixed five categories of work:
| Category | What it really asks | Who should answer first |
|---|---|---|
| Engineering | How does this system behave? | Customer engineering or implementation engineers |
| Product | Should the product work this way? | Product owner or internal lead |
| Access | Can we inspect or call this system? | Customer sponsor or platform owner |
| Architecture | What boundary should the new build respect? | Engineering leadership and field delivery |
| Internal-only | What do we need to decide before asking? | Delivery team |
That table became the quiet center of the work. Not fancy. Just the difference between asking for help and exporting confusion.
The routing template that changed the conversation
The template we used was deliberately small. A large process would have failed here because the team needed to clean up an already-shared document quickly. The useful unit was one question at a time.
For each question, we added four pieces of information:
- The category: engineering, product, access, architecture, or internal-only.
- The known context: what we already knew from calls, docs, vendor systems, or app review.
- The decision it unlocked: what we could do once the answer arrived.
- The sharing boundary: customer engineering, customer product, internal team, or hold.
That last field mattered most. A question can be technically valid and still be wrong to share with engineering. If the team is still learning a vendor-built app, asking the customer engineering team to explain every app-specific detail signals that the delivery team has not done its homework. That signal is sometimes accurate. Broadcasting it before checking the docs and the running app is still bad form.
Classification does not dissolve the uncertainty; it makes the uncertainty actionable. A question like "Where is the order status API?" breaks into several sharper possibilities:
| Routed question | Category | Decision unlocked |
|---|---|---|
Which endpoint returns order status for /orders/{id}? | Engineering | Implement status sync |
| Who owns the customer-facing status language? | Product | Avoid copying backend states into UI |
| Can we get read-only staging access for order flows? | Access | Verify behavior without guessing |
| Should the new service depend on the store backend or shared CMS? | Architecture | Choose integration boundary |
Those are not the same question. Treating them as one is how teams end up with polite answers that do not move the build.
Question lifecycle and state
Beyond the four fields above, a question moves through identifiable states before it closes. Tracking that explicitly keeps the list from accumulating stale rows.
| State | Meaning | Next step |
|---|---|---|
| Open | Captured but not yet classified | Classify and assign owner |
| Routed | Category and owner assigned | Owner investigates or escalates |
| Blocked | Waiting on access, docs, or a product decision | Note the blocker; set a review date |
| Ready | Context attached, decision named, sharing boundary set | Move to appropriate external artifact |
| Closed | Answer received and recorded | Archive; reference in ADR if architecture question |
| Retired | No longer relevant (scope changed, assumption validated) | Remove from active list; note why |
The "Retired" state matters more than it looks. Questions that linger past their usefulness collect context that was true at one moment and misleads anyone who reads the list later. A two-week-old access request that got resolved informally should be retired with a note, not left open as evidence of a problem that no longer exists.
The customer trust problem hiding inside API discovery
Incomplete API documentation is usually described as a technical blocker. It is partly that. In customer engineering work, incomplete docs also create a trust problem.
When both teams have the same incomplete information, repeatedly asking for more access without showing what you already tried sounds like fishing. The customer hears "we need another thing." The delivery team means "we are trying not to build the wrong thing." The gap between those sentences is where relationships get expensive.
Attaching context before asking closes that gap. Not an essay. Just enough to show that the question came from work already done:
| Weak ask | Routed ask |
|---|---|
| Can you share the API docs? | We reviewed the web API doc and found missing response fields for /stores/nearby. Is there a newer contract or should we infer from staging responses? |
| Can we get access? | We need read-only staging access to verify checkout state transitions before drafting the ADR. Who can approve that scope? |
| How does the app work? | For the vendor-built mobile flow, should the new service preserve the current booking boundary or replace it? |
Context says: we are narrowing the unknown. Lack of context says: please absorb our unknown.
Why ADRs helped, but only after classification
The team had already agreed that new builds should use architecture decision records. That was the right instinct. ADRs are good at capturing decisions, constraints, and tradeoffs once the decision space is clear enough to write down. They are less useful as a dumping ground for unresolved discovery.
Raw customer questions sent straight into ADRs turn the document into a shrine to indecision. It will contain product uncertainty, access requests, vendor archaeology, and genuine architecture choices in the same voice. Later, someone will read it and assume every paragraph had equal authority. A temporary uncertainty becomes a permanent constraint with formatting.
Classification came first because it separated discovery from decision. Only architecture questions with enough context and a real implementation consequence deserved to become ADR inputs. Product questions needed product handling. Access questions needed ownership. Internal-only questions needed cleanup before they became anyone else's problem.
The sharp edge: classification can become gatekeeping
A classification step can become a place where hard questions go to become slow questions. If one person owns all categorization, the team gets a bottleneck with a nicer name. If every question needs ceremony, people stop asking in the open and start improvising in side channels, which is worse.
Keeping the artifact thin and the criteria visible is the countermeasure. No committee required. Just a shared habit:
| Rule | Why it matters |
|---|---|
| If the question names implementation behavior, attach observed evidence. | Engineering can confirm or correct instead of starting from zero. |
| If the question asks what should happen, send it to product first. | Engineering should not accidentally decide roadmap or customer policy. |
| If the question asks for a resource, state what work it unlocks. | Access requests are easier to approve when the scope is concrete. |
| If the question exposes internal uncertainty, clean it up first. | The customer should see the work product, not the backstage scramble. |
The goal is not to sanitize reality. It is to expose the right reality to the right audience at the right time. Field delivery has to be honest without being indiscriminate. That is a narrower skill than transparency and a harder one to practice under schedule pressure.
How I would run it next time
I would introduce the classification step before the first shared questionnaire exists. Retrofitting discipline onto an external document is possible, but the effort is real and the emotional cost is higher than doing it early.
I would also make ownership explicit in the first customer communication plan:
| Artifact | Owner | Shared with customer? | Purpose |
|---|---|---|---|
| Raw discovery notes | Field team | No | Capture uncertainty fast |
| Routed question list | Field lead | Sometimes | Prepare clean asks |
| Engineering questionnaire | Field and technical lead | Yes | Get specific answers |
| ADR | Technical lead | Yes, when ready | Record implementation decisions |
| Product question list | Product owner | Selectively | Resolve intended behavior |
That split keeps the team from pretending one document can serve every audience. It also protects engineering from becoming the default recipient of every unanswered thing. Engineers are good at answering technical questions. They are not a compost bin for organizational ambiguity.
In customer-facing technical work, the handoff from discovery to engineering is itself a system boundary. Design it deliberately, or it will form on its own: out of repeated requests, missing context, and a customer who cannot tell whether the delivery team knows what it is doing.
FAQ
Why is a customer engineering questionnaire unreliable without routing?
Because a raw questionnaire mixes engineering, product, access, architecture, and internal uncertainty. The receiving team cannot tell which questions require facts, decisions, permissions, or cleanup.
Where should I capture product questions during technical discovery?
Capture them in the same intake, but route them separately before sharing with engineering. Product questions ask what should be true, while engineering questions ask what is true in the system today.
How do I stop repeated API access requests from creating friction?
Attach context to every request: what was reviewed, what is missing, and what decision the access unlocks. Repetition feels different when the customer can see the investigation narrowing.
When should discovery questions become ADR inputs?
Only after they point to an architecture decision with enough context to evaluate tradeoffs. Raw uncertainty belongs in discovery notes or a routed question list, not directly in an ADR.
What is the field delivery role in question routing?
Field delivery translates messy customer reality into scoped work without exposing every internal uncertainty. That translation protects trust and gives engineering a cleaner problem to solve.