Data‑flywheel friction

The part of the artificial intelligence product “flywheel” that sounds easiest on paper is often the one that breaks in practice: writing down what just happened. Teams can usually run the customer interview, build the prototype, or ship the feature; the stall comes one step later, when someone has to turn scattered session notes into a shared artifact the next team member can actually reuse. (martinfowler.com) That stall matters because the whole promise of a flywheel is compounding. In a healthy loop, one customer conversation improves the next prompt, one failed prototype improves the next design brief, and one debugging session improves the next runbook. When those lessons stay in a person’s head or in a chat transcript, the loop stops spinning and the team starts each cycle half from scratch. (martinfowler.com) The term “data flywheel” usually describes a self-reinforcing system: users generate activity, activity creates signals, signals improve the product, and the improved product attracts more use. In artificial intelligence teams, those signals are not just clicks and ratings; they also include prompts that worked, missing context that caused failures, and the exact instructions that finally got a useful result. (developer.nvidia.com) (martinfowler.com) That is why documentation has become the awkward middle gear in many modern product teams. Capturing raw activity is easy because software logs it automatically, and turning a decision into the next engineering ticket is familiar because teams already have backlog tools. The hard part is the translation layer in between: deciding what was learned, what is reusable, and where that learning belongs so it changes future work instead of disappearing after delivery. (notion.com) (blog.logrocket.com) In product discovery, the official goal is not just to collect ideas but to understand customer needs and validate them before building. Atlassian describes product discovery as a continuous, collaborative process tied to delivery rather than a separate exercise, and that linkage is exactly where undocumented learnings create drag. If discovery outputs never become durable context, teams keep rediscovering the same facts with new meetings and new tickets. (atlassian.com) Writers on knowledge management keep returning to the same failure mode: insight capture is not the same thing as insight management. LogRocket describes insight management as the process of capturing, processing, sharing, and storing insights across an organization, and notes that mature teams use it to reduce waste, speed decisions, and improve alignment. The gap between “we learned something” and “the organization can now act on it” is where many flywheels lose momentum. (blog.logrocket.com) The same pattern shows up in engineering teams using artificial intelligence coding tools. Rahul Garg’s recent “Feedback Flywheel” essay argues that many teams plateau after adopting these tools because individual developers build personal intuition that never transfers into team infrastructure such as wikis, runbooks, and code review checklists. In his framing, the problem is not that the tools stop improving; it is that the team has no routine for feeding experience back into shared practice. (martinfowler.com) Travel products make this especially visible because the work is unusually fragmented. Microsoft’s April 2026 case study on Global Travel Collection says advisors often use 10 or more resources for a single itinerary, and that planning and booking complex trips had been taking six to eight hours each. When a workflow spans that many systems, every undocumented workaround becomes expensive because the next person has to relearn the same maze. (microsoft.com) Global Travel Collection’s response was to build Atlas, an artificial intelligence system that unified those sources behind one interface. Microsoft says the system is saving nearly 2,000 advisors more than 1.5 million hours annually and about three hours per trip on average. Those numbers describe a classic flywheel ambition: reduce search friction, collect better usage signals, and make the next trip-planning session faster than the last. (microsoft.com) But even in that kind of high-signal environment, faster systems do not automatically create shared knowledge. A team can centralize search and still fail to preserve the lesson that one hotel data source is consistently stale, one customer segment always needs a visa check earlier, or one prompt format gets better supplier summaries. The machine can gather activity at scale, but humans still have to decide which patterns deserve promotion into a playbook, a checklist, or a product requirement. That is an inference drawn from how these systems are described by product documentation and feedback-flywheel sources. (microsoft.com) (martinfowler.com) (notion.com) This is why teams often complain less about collecting feedback than about “closing the loop.” Notion’s product documentation guide says key decisions often end up scattered across old documents, chat threads, and half-updated requirements, producing repeated conversations and slower progress. In other words, the organization has the facts, but not in a form that changes future behavior. (notion.com) Once that happens, the next ticket becomes a kind of trap. The team feels productive because a concrete task moved forward, but the learning that produced the task never becomes portable. A bug gets fixed without updating the runbook, a prompt gets improved without updating the template, and a customer objection gets handled without updating the positioning document. The backlog advances while the institution stays the same. (martinfowler.com) (notion.com) The shared complaint in the story you pointed to is really about that conversion step. Not “did we learn something,” and not “did we ship something,” but “did we turn what we learned into an artifact that survives the meeting, the sprint, and the employee who happened to be there.” Teams building artificial intelligence and travel products are dealing with different surfaces, but they are running into the same bottleneck: the flywheel only compounds after someone does the unglamorous editorial work of making tacit knowledge explicit. (martinfowler.com) (blog.logrocket.com) (atlassian.com) That makes the story less about documentation as bureaucracy and more about documentation as infrastructure. A good artifact is not a diary entry and not a compliance checkbox; it is a reusable part that changes the next decision. When teams say the hardest part of the flywheel is documenting what was learned, they are really saying that compounding improvement depends on turning one-off effort into something the organization can remember. (martinfowler.com) (notion.com)