Nobody on the team has talked to a customer
Your engineers build what the ticket says, accurately and fast, and nobody on the team has met the person who will use it. This page has the six questions that reveal the gap and the discovery cadence agreement, both free to copy. The worked example at the bottom is a squad finding out its real constraint was never willingness.
Building it right without knowing what is right
In a lot of organizations, discovery and delivery got separated cleanly. Someone else works out what should exist, writes it down, and the team implements it well. On paper this is efficient. In practice it puts every judgement about value on one side of a wall and all the implementation knowledge on the other.
The obvious cost is that wrong things get built correctly. The larger one is that the people who could have proposed a cheaper way to solve the same problem never saw the problem, only the proposed solution. Agents sharpened it: when building is cheap, the ratio between deciding and building shifts hard toward deciding, and a team that can build anything but talks to no one produces more of whatever it was handed.
An engineer who has never met the user can only judge whether the ticket was implemented correctly.
Six questions that reveal a team building blind
Ask your own team, in a room, and let the silences do the work. The uncomfortable ones are the informative ones.
- When did someone on this team last watch a user do the thing we built? Watching counts; a summary of what users said does not. If the honest answer is measured in quarters, every estimate the team gives is about effort and none of it is about value.
- Who decided this was worth building, and can we go and ask them why? The point is to find out whether the reasoning survives contact with the people implementing it, which is the cheapest review a decision ever gets.
- What do we believe about the user that we have not checked? Every ticket carries assumptions. Naming two of them takes a minute and often reveals that the expensive part of the build rests on the least certain one.
- If this turns out to be unused, when would we find out? A team that cannot answer has no feedback loop, only a delivery pipeline. The honest answer ‘we would not’ is common and worth saying out loud, because it is exactly the gap between output and outcome.
- What have you argued against building, and what happened? Tests whether disagreement has a route. If nobody can remember arguing, that is either a very good backlog or a team that learned objecting is not worth it. What the second case measures is psychological safety.
- Given the same problem, what would you build instead? The question that recovers what the team can already see. Engineers get asked to estimate the proposed solution and almost never get asked about the problem behind it. Years of only estimating is a reliable route to senior engineers resigning.
The discovery cadence agreement
Six fields, agreed with whoever owns the product decisions. Deliberately the smallest version that changes anything.
- Who goes, on a rotation One person per cycle, rotating through everyone who writes code, so the understanding spreads instead of concentrating in whoever likes customer calls.
- How often, and how small Two conversations a month beats a research programme that never starts. Small and boring survives a busy quarter; ambitious does not.
- What comes back, and to whom Five minutes at an existing meeting, not a document nobody reads. If it needs a written report, it will stop within two months.
- What we do when something surprises us Name the person who hears it and the decision it is allowed to reach, before anything surprising happens. A surprise with nowhere to go teaches the team that looking was pointless.
- What we stop doing to make room Discovery added on top of a full sprint is discovery that gets dropped first. Name the hours it replaces and where they come from, or accept that the sprint plan will absorb them.
- When we revisit this A date, ninety days out, in the calendar today. Most cadences fail slowly rather than visibly, and a scheduled check is what turns ‘we stopped’ into a decision rather than a drift.
Fill it in with the product owner in the room, not afterwards. Filling in all six takes twenty minutes face to face; the same six by email takes a month and comes back vaguer.
What is dual-track agile?
Running discovery and delivery as two continuous tracks in the same team rather than as sequential phases. Discovery works out what is worth building and whether it will work; delivery builds it. Marty Cagan popularised the model, and Teresa Torres developed the habit-level practice in Continuous Discovery Habits. The point of the word ‘dual’ is that neither track stops: discovery is not a phase that finishes before engineering starts.
How often should engineers talk to customers?
Less often than a product manager and far more often than never. A rotation where one engineer joins a customer conversation every couple of weeks is enough to keep the team’s mental model current, and it is small enough to survive a busy quarter. The cadence matters less than the rotation: understanding that sits with one person is a dependency, not a capability.
Is discovery not the product manager’s job?
The decisions are, and this does not take them away. What changes is who has the context to make an implementation decision well. An engineer who has watched someone struggle with the current version builds a different thing than one working from a ticket, usually a cheaper thing.
What is validation theater?
Discovery activities that run after the decision is already committed, so nothing they find can change anything: a user test whose result lands once the build has started, an ‘insight’ field filled in on every ticket, a research summary nobody reads before scoping. The test is simple. Name one thing discovery changed last quarter. If nobody can name it, the activities are documentation, not discovery.
From ticket transcription to a cadence: a worked example
Simulated team · Real product output The target is a team that can argue about what to build, not only about how long it takes. Watch it happen on one team: the Storefront Squad at Lingon & Co, a fictional consumer e-commerce company of about 200 people. Seven people on the browse-to-checkout funnel, shipping constantly, and no engineer on the squad has watched a user in three years; the testing that exists runs after the decision is made. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Every team member answers structured questions in their own words, and can take any thread further with the coach in a check-in. The answers roll up into one analysis that scores each area of how the team works.
Product discovery, scored two of five
Each area is scored one to five, shown as filled dots. Product Discovery and Development came back at two, and the same panel credits what already works here: A/B testing, some prototyping, and a squad that already knows what dual-track practice is. The score is low because that testing runs after the decision, not because there is none.
What the rotation actually costs
A senior engineer asks how a team gets from transcribing tickets back to discovery, then pushes for the week-to-week mechanics. The answer is a number, not a principle: 2 to 4 hours per sprint for whoever is on rotation, joining the product manager or designer for that week's activity, planned the way on-call is planned. The last message names who else has to move. The product manager schedules discovery on a predictable date instead of ad hoc, and the engineering manager defends that capacity in planning.
Discovery that changes nothing
The designer's version: two hallway usability tests failed, the feature shipped unchanged, because the date was already fixed. The coach names that pattern validation theater and refuses the process tweak. Either discovery moves forward to before dates get attached, or it is pre-launch preparation and the squad should stop pretending user feedback will influence the build.
2Recommend, refine, commit
The low scores come with recommendations, and the recommendations become concrete suggestions the team votes on and commits to. The AI informs the decision, it does not make it.
General advice, made specific
The suggestion for this squad is a weekly customer contact rhythm, two to three conversations a week. Read the Context field, then the Relevance field next to it. Context gives the reason: customer access was rated one of five, lower than the discovery score above, and for a consumer storefront squad the distance between the team and the people it serves limits every discovery practice. Relevance argues from what this team already has: psychological safety and cross-functional collaboration are strong, so the constraint is access and habit, not willingness. Below that, the template arrives mostly filled: four action steps that start from channels the team can reach this week, success metrics like customer insights showing up in half of sprint planning discussions, and a four-week time box. The cadence agreement above tells any team to pick a rhythm; two-to-three a week is the number that fell out of this team's own scores.
3Execute and re-evaluate
The team runs the rotation in its own context, and the next analysis shows whether it held through a busy sprint. The Storefront Squad has run one period, so the trend view starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the questions and the cadence agreement above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.