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.