In my last few articles I introduced Gears, a modular framework for adaptive product development. Those articles touched on how work is delegated and how alignment is achieved between departments. But buried in the DNA of those Gears is a universal building block that drives the entire framework. It exists in each assignment, each task and all the way down to the basic interactions in your ordinary workflow.

I’m talking about the atomic feedback loop.

What is an Atomic Feedback Loop?

You probably ran one this morning. You opened your AI tool, gave it a prompt, read the response. Something was off, so you sent corrections. The back-and-forth continued until you had what you needed. You might not notice it. But this small exchange has a shape, and the shape repeats everywhere.

You'll run hundreds of these exchanges per day. Thousands per assignment. It's so common that most people run them every day without realizing it. Every exchange of information between you and a person, or you and an agent, is an atomic feedback loop that's building on accumulated knowledge, piece-by-piece, until both parties reach an acceptable outcome.

In this article, we'll take a closer look at the loop itself: what it is and when it's done, how to run it well, what to watch for when it breaks down, the pairings it runs in, and how it scales into bigger feedback loops across teams and into larger initiatives.

So what exactly is it, and when is it done?

To put it precisely, an atomic feedback loop occurs when two parties exchange information back and forth, refining as they go, until both sides reach an acceptable state. One gives feedback or context. The other processes it and responds. The cycle continues until both agree they've achieved the shared goal.

It’s atomic because it can’t be broken down further. One party has no one to exchange with, and a single message with no reply isn’t a loop.

This is where domain specialists are still highly valued and someone with a blurred role may be a liability. AI agents lower the bar on many tasks, but they don't replace domain expertise, and they certainly don’t replace human judgment.

By embracing the distinct characteristics of Product, Research, Design, and Engineering, we allow specialists to excel in their domains.

• Product Managers are more effective building PRDs and roadmaps than performing research

• Researchers are more effective developing research plans than mapping out UI patterns and micro-interactions based on competitive layouts

• Designers are more effective prioritizing user needs than building the front-end

• Engineers are more effective building the security infrastructure than choosing accessible, on-brand color palettes

Every gear has a framework. It's a checklist or workflow each role follows to know when work meets the minimum qualifications to advance. There's subjectivity in every loop, of course, and human judgment is paramount. The specialist checks the work against their framework, brings their own opinion, and confirms the work is ready to move on.

How to run a good loop, and what breaks it

Running one well isn't complicated. A few things matter.

The first is the goal. The more clearly you've defined what you're trying to reach, the more success you'll have reaching it. Vague goals make vague loops.

The second is context, and how you deliver it. Agents do okay with text or visual alone, but they're far more performant with both. That's not unique to agents. Speaking to a person is one thing. Speaking to them, handing them a one-sheeter, and showing them a video that says the same thing is another. They grasp it faster. Agents work the same way: the more they have to analyze, the smarter they are in return. It doesn't matter how you provide context; it matters that you do from more than one angle. And it goes both ways: expect the agent to hand context back to you in more than a wall of text too.

Here's what that looks like in practice. You give the agent context, through text and sometimes images. It responds with text, sometimes visuals like a graphic or an artifact. You read what comes back, find what's wrong, send new feedback and repeat until the work clears the bar.

That's a good loop.

Bad loops

Bad loops feel like they never end. Three failure modes show up most often.

The first is timing. Loop too soon and you're getting feedback on an unprocessed idea. You may be pulled toward something that isn't what you were actually thinking. Loop too late and you've already over-invested in the decision before testing it. You need to be able to articulate your thoughts clearly before seeking feedback. Otherwise you get led astray.

The second is scoping. A loop that drags forever is usually too big. The agent gets confused, your own feedback pivots too much, nothing converges. It’s better to have a more defined goal than it is to ask the agent to do too much.

The third is on the agent's side. The loop breaks down when the agent gets overconfident or misguides you. Usually it's because the agent doesn't know its role or doesn't have the context to act on the information you've given it. This one is harder to spot because confident-sounding output looks like a working loop.

This is where you remember you're the specialist. You set the standard, not the agent. The agent's output is a draft. Your job is to judge whether it meets the bar. In a Human/Agent loop, the final judgment is yours.

The three pairings

So far we have mainly discussed the Human/Agent pairing, but the atomic loop holds for Human/Human interactions and Agent/Agent interactions.

Humans and agents process information differently. So naturally, there is some tradeoff in the inputs and outputs that each party can send and receive.

Shared across all pairings is the idea that one party's output becomes the other party's starting point.

Human/Human loops

Humans have access to signals that agents don't, such as feelings, tone, pacing, body language and non-verbal cues that accompany words. Humans also bring human limits, like bounded attention, imperfect memory and mental models that color judgment. When two humans interact in a feedback loop, both sides have significantly more signals available to work with than an agent does.

In the Gears framework, I call this exchange a connection point, because it's where the two specialists align and pass work from one gear to the next. Completion is mutual agreement, as both parties hold the standard for their own gear. As such, the work only advances when both parties are satisfied.

Agent/Agent loops

Agents are the inverse of humans. They work from their training data and from the explicit context you provide them. They can't read a room, but they won't get tired or forget what you told them twenty minutes ago either.

The Agent/Agent pairing has the fewest signals to work with, as it can only process context that has been explicitly provided. In this pairing, judgment is rule-bound, so agents close these loops against the predefined criteria, such as a checklist, depending on the workflow.

While different pairings change which signals are available and how the exchange feels, the shape doesn't change. It's still an atomic loop.

Same shape, every scale

In each domain, there are several artifacts that must be generated to accept, scope, plan, produce and deliver work.

Atomic feedback loops can be sequenced together to create larger feedback loops, where a domain specialist accepts an assignment from another specialist, produces the work, and then returns an output to the requester. That’s a full rotation of a gear. If work is rejected or needs iteration, the gear can rotate again. That’s a feedback loop.

To better understand this concept, let’s look at an example using the Research gear.

Let’s say that a Product Manager wants to understand how customers are acclimating to a new feature. The PM will submit a research request, which will be converted to a Research Brief for the researcher (me) to pick up. This transfer of information is the first connection point in a Human/Human loop.

As the researcher, my job is to complete one rotation of the Research gear, using atomic feedback loops to create different artifacts.

1. After reading the brief, I'll have to develop a research plan. I work with an agent to explore the ideas in the brief, using my judgment as a researcher to decide the right hypothesis, experiments, methodologies and more. We'll refine through a feedback loop until I have a publishable plan.

2. Let's say the plan calls for participant interviews, so I'll also need to develop a screener survey. That will require another feedback loop with an agent to develop that artifact.

3. Then I need to develop an interview guide with questions to ask participants. That's a third artifact and another feedback loop.

4. Once interviews are done, I'll work with an agent to synthesize the data and capture the insights that will be presented in a final report. This is another feedback loop to create that artifact.

That's four feedback loops to complete the core work of the Research gear.

Once the report is complete, I connect with the Product Manager who requested it and present my findings. That connection point is the return in the Human/Human loop, transferring new knowledge back to the originating party.

This is just an example. Some assignments need fewer loops, some need more. The count varies with the work, and so do the two parties. In this example, a researcher and a PM exchanged feedback at the connection points. In another gear, it could be a designer and an engineer. The shape is the same.

When all the gears work together, they form a bigger feedback loop, called an engine. The engine that takes an idea from concept to shipped product is itself a loop. The team and its customers exchange context and feedback with each other for continuous refinement: the team ships, customers respond, the team improves and ships again.

The shape doesn't change as you zoom out, only the scale does.

Now you'll see the loops everywhere

You were already running these loops, every day, probably without noticing. Now you have a name for them, and you'll start seeing them everywhere.

The same shape runs a single exchange with an agent, a full rotation of a gear, and the engine that carries an idea from concept to shipped product. It doesn't change as you zoom out. Only the scale does.

That's what makes the loop worth your attention. Everything you build is made of it. The feedback loop is inescapable.

The loop itself is where your effort pays off. Run the unit well: a clear goal, context from more than one angle, the judgment to know when the work is done. Refine the loop, and you refine everything.

Simple. Quality. UX & Product Design is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Subscribe now

In my previous article, I introduced the Gears framework—a structure that lets Product, Research, Design, and Development teams work at their own rhythms while staying connected at critical moments. Each department operates as its own gear, turning at its own pace, engaging at connection points where one team’s work becomes another’s starting point.

But there’s one gear that works differently from all the others: Product.

While Research, Design, and Development each have their own specialized workflows, Product operates as the coordinating force that powers the entire system. It’s the gear that determines what gets built, why it matters, and how deeply teams should engage to explore it. From wild ideas submitted by customers to production-ready features shipped to users, Product ensures that every rotation—every assignment—adds value back to the product and the people who use it.

Unlike other gears in the framework, Product doesn’t operate as a single workflow. Instead, it functions as a gear train—a series of three connected gears that progress work from idea to observable outcome: Intake, Manage, and Observe.

This article explores how the Product gear train works, with particular focus on the Intake process—the critical first rotation where ideas are captured, screened, and formed into structured assignments. Because without a disciplined way to vet and shape incoming requests, even the best product teams drown in noise.

The Product Gear Train

Unlike Research, Design, and Development—which each operate as individual gears with their own workflows—Product functions as a gear train. A gear train is a series of connected gears working in sequence, where each gear must complete its rotation before the next can begin. This sequential structure ensures that every assignment moves through the system with intention, and that no gear spins without purpose.

The Product gear train consists of three gears: Intake, Manage, and Observe.

Intake is the small gear that initiates everything. It captures ideas from across your organization and community, vets them against your product vision, and routes approved concepts forward. Without Intake turning first, nothing else moves—it’s the deliberate starting point that prevents the system from spinning on unvetted ideas or getting stuck sorting through noise.

Manage is the large central gear that coordinates cross-functional work. Once Intake hands off an approved idea, Manage takes over to develop it into something tangible. This is where Product works with Research, Design, and Development to turn a vetted concept into reality—whether that’s validating an assumption, building a prototype, or shipping production-ready code.

What makes Manage unique is its ability to operate at variable depths. Not every idea requires the same level of investment. Some assignments need lightweight discovery to test an assumption, others require working prototypes to validate with users, and some demand full production effort to deliver. This flexibility allows teams to match their engagement to what the work actually requires, rather than forcing every idea through the same heavyweight process.

Observe is the output gear that ensures value delivery. After Manage completes its work—whether that’s shipping a feature or concluding an exploration—Observe measures the outcome against the goals established at the start. Every rotation produces learning, even when the output isn’t what we expected. This closes the loop and ensures nothing is wasted.

Together, these three gears create a system where ideas flow through a deliberate sequence: capture and vet, coordinate and build, measure and learn. Each gear depends on the one before it, and each contributes to the whole. The small Intake gear powers the large Manage gear, which in turn powers the small Observe gear—a mechanical progression that keeps the entire Product system moving forward.

The Intake Gear

Intake is where every product assignment begins. Its purpose is to ensure that ideas—no matter where they come from—are captured systematically, assessed fairly, and routed to the right outcome. The process consists of three phases: Capture, Screen, and Route.

Capture: Gathering Ideas with Context

Product requests rarely arrive polished and ready. They start as wild thoughts—nebulous, unrefined, and scattered across conversations. A customer mentions frustration in a support ticket. A teammate spots an opportunity during a demo. A stakeholder raises a concern in Slack. Without a system to collect these inputs, valuable ideas disappear while others get pursued simply because they were the loudest or most recent.

The Capture Box solves this by providing a single, accessible entry point where anyone in your community—customers, collaborators, internal teammates—can submit feedback and ideas through a simple form. But capturing the idea itself isn’t enough. The form is designed to gather context alongside the request:

• What problem is this person experiencing?

• What were they trying to accomplish?

• Who is affected?

This context matters because users often propose solutions rather than articulating problems. Someone might request “better filtering” when their actual need is faster access to recent items. Or they might ask for “a button to do X” when the underlying issue is that the current workflow requires too many steps. Capturing context helps Product teams understand the need behind the request, not just the suggested solution.

Once submitted, each idea is logged as an issue in a repository, creating a record that can be tracked, referenced, and analyzed over time.

Screen: Systematic Assessment at Scale

With ideas flowing in from multiple sources, Product teams face a volume problem. Manually reviewing every submission is time-consuming and inconsistent—different people assess ideas differently, patterns get missed, and duplicates slip through. This is where systematic screening creates efficiency.

Each logged issue goes through what we call a Fit Check—a rapid assessment that evaluates how the idea aligns with your product vision and strategy, its potential impact on customers, the urgency of implementation, and the effort required to address it. At Khaos, we use an AI agent to perform these Fit Checks, processing high volumes of requests with consistency while documenting the rationale behind each assessment.

The agent doesn’t just evaluate individual ideas—it builds institutional knowledge. By maintaining a Fit Summary that tracks which ideas have been approved, rejected, or identified as duplicates, the agent improves its screening ability over time and helps identify patterns across feedback. Multiple requests for similar functionality become visible. Recurring pain points emerge. The screening process becomes smarter with each assessment.

The goal isn’t to replace human judgment—it’s to handle the volume so Product Managers can focus their time on decision-making rather than sorting and cataloging.

Route: From Assessment to Action

Once screened, issues move into a triage dashboard where Product Managers review the requests and their Fit Checks. This is where strategy meets execution. The Product Team considers how each idea aligns with current roadmaps, evaluates priority in context of other work, and determines the appropriate path forward.

Some ideas are approved—these transfer to the Product repository where they’ll enter the Manage gear and begin the Formation process of becoming Product Briefs. Others are rejected and closed with documented reasoning explaining why they don’t fit the current direction. In both cases, the decision is recorded and transparent.

What matters is that nothing disappears. Every idea receives a clear outcome. Every decision is documented. And when an approved issue transfers to the Product repository, Intake completes its rotation—the small gear has turned, and it’s ready to power the larger work ahead.

How We Built Intake at Khaos

Building Intake at Khaos meant translating these concepts into actual tools and workflows. We use GitHub as our foundation—issues for tracking, projects for organization, and workflows and actions for automation.

Read more

When the field of UX was developing in the late 2010s, there was heavy emphasis on design thinking and “process.” Schools and bootcamps taught it, employers wanted you to demonstrate it, and teams pushed for it to drive innovation.

Yet as companies rushed to build Product and Design teams, the rules of “the process” were never really universally agreed upon. What emerged instead was a confusing mush of design-guided thinking wrapped in corporate red tape. What was meant to unlock creativity, ended up flushing it away.

When I entered the field, I learned Stanford's Design Thinking Process, the Double Diamond, NN/g's Design Thinking and IBM's Design Loop. These design frameworks all offered strong guidance on the steps a design team should take to develop an idea, but these frameworks always collapsed on the job site.

Why? Because developing software requires collaboration with other teams like Product, Research, and Engineering—each following their own frameworks and workflows. The problem is that these frameworks are typically designed in isolation. So when these workflows inevitably intersect, they don’t gently flow into each other, they crash!

This unresolved interdependency often results in a variety of issues:

• Product teams that define UX problems before understanding their users

• Research that confirms decisions rather than informs them

• Design work that’s disconnected from technical realities

• and handoffs that feel like a messy exchange of fragmented ideas rather than a smooth delivery of accumulated knowledge

Multiply this with things like employee turnover, tight deadlines, and limited budgets and resources, and companies end up with their unique patchwork “process” shaped by their own culture and constraints.

These aren't growing pains of the maturing field of design — they're structural failures in how we approach product development.

Different teams have different rhythms

In a product development environment, there’s a basic truth: everyone has a different rhythm, expertise, and need.

Embracing the distinct operating characteristics of Product, Research, Design and Engineering will allow each group to apply their domain expertise and help the entire group maximize their collective knowledge. When we refine the connection points between these groups is when see improvements in how the full group brings products from idea to reality.

Think about a classic wristwatch. Inside are different sized gears moving at different speeds. Some make quick, tiny ticks while others make big, slow turns. But they all work in unison to tell time.

This is possible because each gear has a job. They connect at specific points and transfer energy to make the whole greater than the sum of its parts.

Product Development teams work the same way. Each department has its own expertise and way of working. The magic happens when they connect at the right moments to move the system towards its goal.

Gears are meant to turn each other

In the Gears framework, each department has its own unique workflow cycle — called a gear. As the team completes their tasks, the gear turns and eventually arrives at a connection point, to align with the departments.

These connection points are the critical moments where one team's work becomes another team's starting point.

At the connection point is where:

• Teams share work that others can build upon—whether that's research insights, design specifications, or code

• Everyone understands exactly what information they need to provide to the next team

• Key decisions and their rationales are documented

• Teams hold each other accountable for maintaining momentum

These connection points are the teeth of the gears. As one department’s gear turns, it also turns the connecting department’s gear at the right moment and with the right information.

By focusing on these connection points rather than prescribing specific internal methods, it allows each team to work in the way that best suits their strengths and expertise while ensuring the gears turns smoothly to accomplish the collective goal.

Adaptability empowers teams

Gears was developed at Khaos to keep our workflows light and flexible, but adaptive for scale. It offers a way to maintain the specialized excellence that comes from letting experts be experts, while keeping the necessary connections to efficiently build products.

It adapts to the needs of the team, because:

• Not every project needs all gears to turn (sometimes you just need research or a quick design update)

• Teams often work in parallel, not just one after another

• Different projects need different rhythms and pacing

• a gear may need several rotations to get something right before the next team can start, and that’s okay

This flexibility lets you adapt to what the work actually needs instead of forcing it into a one-size-fits-all approach.

The important thing to remember is that the Gears framework is not a process. It's simply the structure that guides your process. However way you work between the connection points is the right way.

In upcoming articles, I'll dive deeper into each gear and the connection points that make them run. I’'ll discuss implementation strategies at Khaos and offer templates that helped me adapt Gears in my organization.

Subscribe now

Disclaimer: All thoughts are my own. Edited for clarity, consistency and accuracy using Claude3.7 Sonnet.

Once upon a time, the design software landscape was fragmented amongst a few minor players, all specializing in one thing well. For mockups, there was Sketch; for Prototyping, there was Principle; for inspecting design, the was Zeplin.

But then came a software that managed to aggregate all of those specialities into one, within a browser window. I’m talking of course, about Figma.

Since, then Figma has become ubiquitous with UX design, taking the crown from Sketch, fending off competitors from Adobe and InVision and then cornering the market by integrating even more features that matched Abstract, Mural and even Google Slides.

After shuttering xD, Adobe saw value in Figma and agreed to buy the company for $20 Billion in 2022, before the deal terminated over regulatory concerns in 2023.

It’s become unrecognizable since the early days, and as such, now costs a designer $144/yr and $35 for a Developer on an Enterprise plan.

But the value to a Developer raises questions. How valuable is it really?

The Design-Code Barrier

Each year, it seems like Figma unveils some interesting new features to bridge the gap between design and code. Yet, despite all that’s been done, design hits an inevitable dead end in Figma.

I can execute Discovery and collaboration sessions in FigJam. Then, I can spin up wireframes and mockups in Figma. I can then apply my design system and other variables to get to a near realistic prototype - but the buck stops there.

No matter how meticulously I engineer my file with reusable components, auto layouts or design tokens — the best an engineer will ever receive is a reference point to what needs to be built.

This means, despite all the Figma can do, its value as a handoff tool is only as good as the engineer picking up the work. If that engineer isn’t experienced on front-end, then your design won’t be built to spec, regardless of how neat your design file is.

From an engineer's perspective, there's a significant gap between referencing design specifications and being able to use the actual work product in the engineering process. Instead of leveraging what’s built in Figma, they must interpret design and manually recreate everything from scratch.

Figma acknowledges this limitation in their help docs, stating:

most of the code available involves only visual properties and spacing. No Javascript or other logic is exported.

https://www.figma.com/best-practices/tips-on-developer-handoff

So this begs the question. If Figma is just a communication tool, despite all that’s it does, is it really necessary in Design at all?

How we can build better

As we at Khaos are working to streamline our handoff process, we’ll continue to explore alternatives to make our design-to-code handoff as smooth as possible.

But as new text-to-code builders like Cursor and Tempo come to market - we’re experimenting with building our prototypes in code.

This allows us to hook up our APIs and an analytics platform like Amplitude - to capture more realistic user behavior from more realistic prototypes.

We are no longer hamstrung by having to develop ‘dumb’ prototypes in Figma, as we’re now able to rapidly generate personalized prototypes in a few hours.

We take it a step further by hosting our design system in Storybook.js, allowing us to use our production-level components in our prototypes.

If we ever want to adjust anything quickly for mockup purposes, we use a Figma Plug-in like Web-to-Figma to reimport our components, which we can then use to mockup some new designs.

But this is where we’re at currently. Figma is a mockup tool, that always ends without jump-starting production.

Until Figma figures out how to do it, it’s just the prettiest (and most expensive) mockup tool you can buy. But the clock is ticking as new front-end AI coders are rushing to market.