Product work is half context gathering. Not just the interesting kind. The kind where you spend two hours every morning combing through Slack, rewatching Gong calls, checking Pylon tickets, reading Google Meet notes, pulling up Linear, and catching up on the CS-to-Product call summaries that maybe got written down.
At Aampe, we had a name for this: The Pain Depot. It was a FigJam board. One person maintained it daily per sprint. I had a two-hour block in my calendar for it. There were columns per customer, sticky notes from every source, and a pile labelled “Uncategorized” that grew faster than we could triage it.
Initially, it wasn’t a bad system. It was just expensive energy & time wise to keep it alive and needed designers to catchup regularly to align.
What the problem actually was
The signal wasn’t missing. It was everywhere. Customer pain points showed up in Slack threads, support tickets, call recordings, and meeting notes all the time. The gap wasn’t data. It was pipeline.
Getting from raw signal to something usable required one person to hold all of it in their head, make sense of it, and translate it for whoever needed it next. CS needed a KB article. Engineering needed a PRD with evidence. Leadership needed a pattern, not a transcript.
That person was usually me 😅
The cross-customer patterns were the worst part. The same pain point would show up as three separate sticky notes in three separate columns. There was no system to see they were the same thing. You had to already know.
And everything I synthesized came with an asterisk. It was “Madhuri’s read on this” rather than something the team could verify. CS couldn’t cite it in a customer call. Engineering couldn’t point to it in a PRD.
It was institutional memory & tribal knowledge, which is just a nice way of saying it lived in one person’s head and left with them when they went on holiday or not part of the org anymore.
What we built
The replacement system has three parts.
The Slack exporter. I built a Chrome extension that searches Slack using your existing session and downloads results as structured JSON, including full thread replies. No bot token, no OAuth, no third-party server involved.
That last part matters because these channels contain real customer data. Account names, sensitive CS conversations, user behaviour signals. Any third-party integration would mean routing that data externally. We weren’t willing to do that. The extension acts as you, downloads to your machine, and the data never leaves the org. It takes two minutes to export a thousand messages. Previously that was an hour of reading.
The common notes repo. Before any synthesis happens, there’s a shared document the team maintains. It holds customer-specific context, known pain points and their status, product area background, and Aampe-specific terminology via custom Claude Cowork skills.
This is what makes the system cumulative. Each run starts from what the team already knows. Context builds instead of resetting.
The synthesis skills & session. The actual Claude Cowork session takes the JSON export, the notes repo, and a structured skill. Not “what are the pain points?” but: themes, severity, frequency, source citations, root cause if known, proposed solutions. The output is a KB article that cites every claim back to the original Slack message. You can click through. You can verify.
One session produces multiple outputs for different audiences: a PRD input for product, a field guide for CS, a roadmap summary for leadership. Same underlying synthesis, different format for whoever needs it.
What it changed
For the team, the biggest shift was traceability. The outputs stopped being “Madhuri says” and started being “here’s Christine at ThredUp, here’s Derek at ZenBusiness, here’s an internal thread from Schaun, all in the last 30 days.” CS could use it in a customer call. Engineering could point to it when scoping. Leadership could trace a decision back to the signal.
For new hires, the KBs replaced the onboarding sessions where someone had to sit with them and explain how the product worked. The knowledge was already written down.
For me, the two-hour daily block is gone. The context still arrives every morning. I just didn’t have to do the gathering.
The parts we didn’t automate
The synthesis is automated. The judgment isn’t.
Deciding which pain points are worth escalating to the roadmap versus deferring is still a human call. Figuring out which problem areas to synthesize in the first place requires knowing the product and the customers. The proposed solutions that come out of the KB are starting points, not decisions. Someone still has to QA the outputs before they go anywhere.
The system handles the reading, the clustering, the sourcing, and the formatting. The thinking about what to do next is still ours.
That’s the line we kept in mind when building this. AI is handling the part that required volume and attention. The part that requires context, judgment, and stakes is still done by people.
If you want to build something like this
Start with one question: where does your real signal actually live?
Not where it should live. Where it actually is. For us it was Slack, Gong, Pylon, Google Meet, Linear, and CS-to-Product calls. Six sources, all separate, no unified view.
Pick the two highest-signal ones. Figure out how to export them in a format an LLM can read without touching PII or violating your data policies. Build a context document that teaches the AI how your product works before you ask it to synthesize anything.
Then write a synthesis prompt that specifies the output structure. Not “summarize this” but “give me themes, severity, frequency, source citations, and proposed solutions.” The difference in output quality is significant.
The last step is the one people skip: ship something from every run. A synthesis that stays in your notes doesn’t help the team. The value is in getting it to CS, engineering, and leadership in a format they can use without having to ask you to explain it.
The system isn’t complicated. The setup takes time. But once it’s running, the daily context tax disappears, and the team has a shared knowledge base that actually gets used.
Madhuri Maram is a product designer and systems thinker. She was Head of Product and Design at Aampe.
If you’ve built something similar or are thinking about it, I’d love to hear how it works at your company.