Turning one product’s knowledge into answers for product, QA, and developers

1. 01

   Situation

   Knowledge of a large, long-lived WorkWave product lived in a few people's heads and in scattered documents. Product managers, QA, and developers kept bringing the same questions to engineers.

2. 02

   Constraints

   I built it alongside my regular engineering work, inside company-approved AI tooling. Proprietary code and customer data had to stay within company boundaries.

3. 03

   Decision

   Package the product knowledge as a Claude Code plugin: skills and reference files that hold what the product does and how it works. The assistant answers at the level of the person asking. Product managers get documents, QA gets testable detail, and developers get working code, all from the same knowledge.

4. 04

   Tradeoff

   One body of knowledge serves three audiences. It has to carry enough detail for developers without burying product managers, and the three levels have to stay consistent, so a document, its test cases, and its code describe the same behavior.

5. 05

   Outcome

   Fewer everyday product questions reach engineers, because the tool answers them. Product, QA, and development now work from the same answers, so documents, tests, and code agree.

6. 06

   Retrospective

   Nothing in the three-level pattern is specific to one product, so the next step is applying it to other WorkWave products.

Next case study: Giving a vendor-unsupported keypad a native Linux workflow →