Nobody on the team has talked to a customer
Your engineers build what the ticket says, accurately and fast. The common problem: nobody on the team has met the person who will use it, so accuracy against the ticket is the only quality anyone on the team is able to judge. This page covers how Aurora Coach closes that gap, and ends with the questions and the cadence agreement, free.
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 less obvious cost is larger: the people who could have proposed a cheaper way to solve the same problem never saw the problem, only the proposed solution. An engineer who has watched someone struggle with the current version frequently knows a smaller thing that would do. They are only ever asked to estimate the bigger one.
There is a third cost that shows up in resignations rather than roadmaps. Working from tickets that arrive fully specified is one of the more reliable ways to lose senior engineers, who joined to solve problems and find themselves transcribing decisions. That one appears in the retention conversation months later, disconnected from its cause.
Agents made this sharper. 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 simply produces more of whatever it was handed.
An engineer who has never met the user can only judge whether the ticket was implemented correctly.
How Aurora Coach addresses it
The target is a team that can argue about what to build, not only about how long it takes. This lives in Aurora Coach's Product domain, discovery and development, which covers customer contact, prototyping, experimentation, and the outcome-focused measures that connect engineering effort to value. It is one of six domains of team effectiveness alongside Foundation, Engineering, Operations, Workflow, and Alignment.
- Sense + Analyze The whole team contributes context: the AI asks structured questions and each person answers in their own words. Engineers usually know which parts of the roadmap they doubt and are rarely asked directly. The AI synthesizes the collective picture into a strengths-and-gaps read grounded in the team’s actual situation.
- Recommend + Refine + Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote and the team lead refines to fit reality. The AI’s job is to inform the decision, not to make it. A discovery cadence becomes something the team committed to and owns, which matters, because this is exactly the kind of practice that gets dropped when it was imposed.
- Execute + Re-evaluate The team works differently alongside delivery. The next period’s analysis sees whether the cadence survived a busy sprint, whether anything the team learned changed what got built, and whether the surprises had somewhere to go. Context compounds across periods.
Free-text check-ins keep the sensing going between periods. If the team has the context and still cannot say whether the work mattered, that is output vs outcome. If engineers are not raising what they know, start with strategy alignment, and if they do not feel able to, with psychological safety.
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. It also happens to be one of the more reliable ways to keep senior engineers, who tend to leave roles where they transcribe decisions rather than shape them.
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, not hearing about. 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? Not to challenge it. 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 answer "we would not" is common and worth saying out loud.
- 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.
- Given the same problem, what would you build instead? The question that recovers the value you are missing. Engineers routinely see a cheaper solution to the underlying problem and are only ever asked about the proposed one.
The discovery cadence agreement
Six fields, agreed with whoever owns the product decisions. Deliberately the smallest version that changes anything, because the ambitious version is the one that gets dropped in week three.
- Who goes, on a rotation Not a permanent liaison. One person per cycle, rotating, 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 Agreed in advance: who hears it, and what can actually change as a result. 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 what it replaces, or accept that the plan absorbs it.
- When we revisit this A date. Most cadences fail slowly rather than visibly, and a scheduled check is what turns "we stopped" into a decision rather than a drift.
This is not an argument for engineers running product. The decisions stay where they are. It is an argument that the people building the thing should have met the person it is for, because it makes them better at the job they already have.
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.
You have the questions and the cadence agreement above, yours to keep and to run without buying anything. It is also generic, as any page has to be. What it cannot tell you is which of it applies to your team, in your situation, this quarter. That judgement is the actual work.
That judgement is what Aurora Coach does. Your team supplies the context through Coaching Sessions and check-ins, in its own words, every period. The AI works from that context rather than from a template, and recommends specific next steps with the reasoning and how you will know whether it worked. The team decides and commits. The next period shows whether it held. This page is one problem in the Product domain. The loop runs across all six, with every team, every period.
What it costs to run: one Coaching Session per person per period, fifteen to twenty minutes, and a period defaults to four weeks with the team setting its own. What the team writes stays private to that person. Only the team-level picture rolls up to leadership.
Both are free. No signup, about two minutes.