1. Direction failures

• Customer disconnect: Optimizing for measurements, or pursuing intellectual curiosities without knowing or caring about actual customer needs, producing work no-one cares about or finds useful.
• Customer overfitting: The opposite failure. Solving one customer’s problem so specifically that the solution doesn’t generalize across the business. The work ships, but only one customer benefits.
• Tunnel vision: Framing a project by its solution space (“use AI to improve caching”) rather than by an outcome or benchmark (“improve performance on B”). A solution-space framing has no natural exit: if the approach doesn’t work, there’s no signal to stop, and the team can’t pivot to an adjacent win it stumbles into. Outcome-framed projects leave room for serendipity, where work on problem X reveals a shippable solution to related problem Y.
• No kill-switch: Without explicit kill criteria, projects out-live their usefulness but continue to drain time and energy due to sunk-cost fallacy.
• Moonshot drift: Projects expand in scope and ambition towards interesting rather than useful, and time horizons creep outwards. Horizons for work that was mid-term becomes long-term, then indefinite, and the team loses connection with the product.
• Portfolio concentration: All active projects share the same underlying assumptions, and when that assumption turns out to be wrong, all efforts fail at once. Even if projects individually are not risky, the portfolio as a whole is.

2. Execution failures

• No measurement discipline: Progress can only be described qualitatively, in vibes, rather than numbers. Without a fixed baseline and a benchmark, improvements, trade-offs, and regressions cannot be verified or compared across configurations, and opinions replace evidence.
• Measurements as gospel: The counterpoint. Measurements are proxies for customer success, but not customer success itself. A team that forgets this fact optimizes the metric instead of the underlying thing the metric was meant to capture, and ships work that moves numbers without moving the business.
• Blurry phases: Projects don’t reach a clear conclusion. Phases of a project blend into each other without explicit gates. Findings don’t crystallize into artifacts that would otherwise serve as gate-keepers. Team is always “almost done” but never actually done with a project.
• Unshipped work: Research produces knowledge, prototypes, and findings that never become product capabilities. A common pattern is chasing the perfect solution past the point where an imperfect version is already shippable, with the next improvement always close enough to justify holding back. Other times the work is simply never handed off. Either way, the value never compounds because the work never reaches the product.
• Failure to support: Research hands artifacts off and disengages. Without ongoing engagement after the handoff, those who inherit the work are left to figure out something the team knows more about than they do, and the relationship between research and the rest of the company erodes one handoff at a time. Since the team understands these capabilities better than anyone, they should remain their steward.

3. Knowledge failures

• Institutional amnesia: Findings, decisions, and hard-won insights live in people’s minds rather than in permanent artifacts. When people leave or move to another project, the knowledge leaves with them.
• Rediscovering dead-ends: Negative results and failures are especially likely to go undocumented, because nobody wants to write up something that didn’t work. So we re-explore them and pay the cost again.
• Inert knowledge: Even when findings are written down, the corpus isn’t structured for retrieval or synthesis. Team members can’t just ask “what have we learned about X?” or check a hypothesis or assumption against the knowledge base. New team members can’t onboard quickly. The knowledge exists, but doesn’t help the team do work.

4. Organizational failures

• Invisibility: The rest of the company doesn’t know what the research team is doing, or why it matters. Research becomes a black box of knowledge that consumes resources and maybe produces occasional announcements. Over time, trust erodes, and budget pressures create a bad environment for innovation.
• Credibility gap: Prior research failures cast a shadow over current work. Stakeholders view new projects with skepticism regardless of the quality or merit.
• Identity crisis: The team doesn’t have a clear answer for what kind of a team it is, whether an engineering team, or a research team, or something else. This produces inconsistent prioritization, inconsistent success criteria, and inconsistent expectations from the rest of the company.

5. Structural failures

• Short-term bias: Pressure to show results drives resources and energy towards short-term projects. Long-term bets are perpetually de-prioritized and don’t get to mature. The team becomes indistinguishable from product engineering, and the moat does not deepen.
• Long-term bias: The opposite failure mode. A “protected” research team drifts towards existing as an end in itself. Long-horizon projects are insulated from accountability, no forcing function exists to connect them to the product, and the moat does not deepen.
• Key-person risk: Specialized knowledge of a topic lives with one or two people. Their departure also means losing years of accumulated knowledge and understanding, which takes time to accumulate again. The moat becomes shallower.
• Hammer and nail: Projects get chosen because they fit the expertise the team happens to have, rather than because they’re what most needs working on. The work looks productive (people are doing what they’re good at), but the portfolio drifts toward what’s convenient to staff rather than what deepens the moat. Over time, the team’s shape determines the company’s research agenda, when the agenda should be shaping how the team grows.