How We Turn Customer Feedback into Product Without Losing Context

We've all been in this loop: a meeting to discuss an idea, a wait for feedback, an email to follow up, then another meeting to confirm what the last one decided. Each delay seems small. Together, they're one of the largest costs in building anything. In financial products, that cost lands on customers, who need the product to keep up with how they operate. But every change can also affect money, permissions, and data. Without clear controls, shipping faster simply means making mistakes faster.

Recently, during a meeting with a customer, they told us our approval workflow wasn't as smooth as they expected and shared a few suggestions. Right after the meeting, our product manager opened Workbench, our AI development environment, and started iterating on the experience based on that feedback. No PRD, no design handoff, no engineering ticket. The team reviewed it, tested it, and shipped the improved experience within hours.

Speed was just the result. The biggest bottleneck in product development isn't coding. It's context loss. Here's how we've rebuilt our workflow around that as a months-old company, and what we'd pass on to other teams.

Every handoff loses information

A traditional product development process translates the same idea again and again:

PRD → Figma → Engineering ticket → Code → QA → Bug ticket

A product manager writes the requirement, a designer turns it into an interface, an engineer turns that into code, and problems after launch become new tickets. Each translation loses some context and adds another round of meetings, emails, and follow-ups. For the customer waiting on the change, each step is just more time.

In the approval example, our product manager skipped the handoffs entirely. I think this is the most important shift AI brings to product teams: product managers can become builders. The person closest to the customer no longer has to translate what they heard into a document and wait for it to come back as software. That's what shortens the distance between customer feedback and an actual product improvement.

In PRDs Are Dead. Figma Is Next., I proposed that the product itself could become the specification. At Reah, this is now how we work every day.

Where context gets lost, and what we changed

A written requirement can't be tested. So we start from the product instead. Workbench is shared between our product and engineering teams and can read our codebase. When a new idea comes in, it builds a working prototype from the existing product, so the team clicks through something that already looks and behaves like Reah instead of debating a description.

Feedback gets scattered across screenshots and chat threads. So we keep it on the product. In SpecDock, a tool we built for prototypes, the team leaves comments directly on specific pages and interactions. Workbench reads those comments, updates the prototype, and carries the approved version and its decision history into implementation.

Problems in the live product get reported far from where they happen. So we let people flag them in place. With Pinpoint, anyone on the team can mark a bug or suggested change right on the page, and Workbench sees exactly where and in what state it occurred. Often, the report comes down to one instruction:

@Workbench, fix it.

A proposed fix can be ready for review within minutes. Voilà.

When a number looks wrong

This matters most where money is involved. A number that looks off on one page may sit on top of several underlying data flows.

In the past, a small accounting or reporting issue could take a data product manager and an engineer several days to investigate. Today, with the appropriate permissions, Workbench can trace the underlying data and locate the anomaly. In one of our fastest cases, it took around five minutes.

For a business relying on those numbers, that's the difference between waiting days for an answer and getting one the same day.

Fast doesn't mean unreviewed

None of this means AI ships changes on its own. Every change, including the ones Workbench writes, goes through testing and review before it's merged. Code is verified on staging first, and nothing reaches production without an approved release.

Engineers guide direction, review implementation, and protect system boundaries. Product judgment, access control, and final decisions stay with people.

What we'd tell any team bringing AI into its workflow

Give AI the context once, and keep it there. It's tempting to brief AI from scratch every time. The bigger gains come when your code, decisions, and feedback live where AI can read them.

Put feedback where the problem is. A comment attached to the exact button or number that's wrong carries more context than a screenshot in a message thread, for people and for AI.

Let AI propose, and let people decide. Shorter loops still need checkpoints. The faster AI can draft a change, the more important it is that someone with judgment reviews it.

For our customers, the result is simple: the time between giving feedback and seeing an improvement can shrink from months to days, and sometimes to hours. You can see what that looks like in our weekly product updates.

The next competitive advantage in software isn't how fast you write code. It's how fast your organization learns.

– Axel Zou