Building the context

Customer feedback was scattered and slow to act on

Before Ripple, customer feedback at Ledgy had four problems:

• Scattered. It came in through calls, emails and Slack threads, and some of it ended up in Linear
• Slow to log. Sales, CX and anyone else talking to customers had to log in to Productboard, tag it, fill in forms and link it to the right feature
• Locked away. Productboard didn't connect to our own agents, so there was no single place to ask one question across all of it
• Hard to follow up. The source, the customer and the next step got lost, so people rarely heard back in time

Feedback goes in from wherever it was said

Nobody opens a new tool:

• Gong. Say "product feedback" on the call, and Ripple picks it up when the transcript is ready
• Slack. Type @Ripple in the thread
• Email. Forward it to Ripple's address
• Intercom. ⌘K, "Send to product"

A minute or two later, a feedback card lands in the feedback channel

A person decides, and keeps the context

We could automate this step. We didn't:

• People need the context too. Reading feedback is how product managers, designers and engineers learn what customers need, so they make better decisions
• People know what the agent can't. We were on the calls and talk to the teams, so we know the tone, the strategy and where the company is going. The agent only has the text
• The thread is where people collaborate. Engineers, sales and customer success ask follow-up questions, add "this customer wanted it too" and bring their own perspective, so the understanding gets richer

Feedback that nobody reads changes nothing

In Notion, it's the customer at the table

• Prioritization. One more source for the roadmap, in the customer's own voice
• Context for design. The customer's words, links and screenshots, and the exact moment in the call, often with their screen shared
• A starting point. An agent searches all the feedback for a first PRD draft, or to check a design or architecture decision
• Closing the loop. Feedback sits under its feature. When the feature ships, the people who raised it hear back and can tell the customer

On a big project, context never sits still

• Definitions depend on context. A term means different things by jurisdiction, market and type of company. We needed a domain model built from what we learned, not from Google
• The latest understanding is hard to find. Slack threads, discovery calls with partners and experts, and team meetings keep changing it, and design and architecture have to follow the latest version
• Questions end up everywhere. Discovery questions sit in meetings and threads, and keeping them current falls on the PM
• A plain agent builds the wrong context. Asked cold, it reads every document without judging what came first or what was superseded

So Carry, our project's wiki agent, keeps three things current: decisions (what we build, how, what we won't, and why), definitions, and open questions. Each links to its source, so when something feels off you check it instead of trusting the agent

Open questions are tracked, and close themselves

• What we don't know is tracked too. Open questions become the agenda for discovery and expert calls, or a note to customer success
• Answers close themselves. When the team decides in a call or a Slack thread, the question is marked answered and linked to the decision. Nobody has to maintain it

Every morning at 8:30, it catches everyone up

• Nobody falls behind. People go on holiday or work on other projects while decisions keep happening. The morning run folds them in
• Curated beats searched. A general agent reads everything and reasons from scratch. Carry answers from a wiki that is curated and current, with sources

An agent builds the wiki, and the agent that keeps it

The Wiki Builder turns a project's raw material into a wiki, then writes the instructions for the agent that keeps it current. Ours is Carry, named after our project

• 10 minutes to an hour. Most of it is collecting the sources, and better sources make a better wiki
• Choose the sources by hand. What you leave out matters as much as what you put in. Generated text drifts from how people really talk, one percent at a time
• Retire it when the code is the truth. Once the work ships, the wiki goes to the archive, so stale pages never read as current