Organizational Memory
Products card, MethodKit for Memory & Reminiscence
Card 50 of 66 · MethodKit for Memory & Reminiscence
  • ThemeProduct & Offering
  • CardCard 50 of 66
  • Questions5 to explore
Product & Offering

Products

Development, features, pricing & roadmap

Product knowledge is not just features and roadmaps: it includes the decisions behind them, the trade-offs made along the way, and the understanding of why the product works the way it does.

The most fragile product knowledge is not what was built but why. Feature lists and roadmaps are usually documented somewhere. The reasoning behind them, the customer problems they were meant to solve, the alternatives that were considered and rejected, that knowledge tends to live only in the heads of the people who made the decisions.

When product teams change or grow, this reasoning gets reconstructed imperfectly. New team members make decisions that conflict with earlier ones, not because they are wrong but because they are missing context. The same debates get had again. The same mistakes get made.

Product documentation at its most useful captures current state (what the product is and does), recent history (what changed and why), and the principles that guide future decisions. It is a working reference, not an archive.

What to capture

For this part of the company brain, what is worth writing down and keeping current. The goal is not a complete archive but a living record that new people can read and returning people can trust.

Product overview & scope

Write down what the product is, who it is for, and what it does and does not do. Include the version or release that is current, and where to find the changelog or release history.

Roadmap & priorities

Capture where the product is heading and why those priorities were chosen. This does not need to be a detailed backlog: a short narrative of the next two to three focus areas and the reasoning is more durable.

Key decisions & trade-offs

For the most significant product decisions (scope choices, architectural decisions, feature cuts), note what was decided and what drove the decision. Include what was deprioritized and why.

Product principles

If the team has working principles for what the product should and should not be, write them down. These are the things that should stay stable even as the roadmap changes.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

  1. Where does a new product team member go to understand not just what the product does but why it works the way it does?

  2. Are there decisions made in the last year that, if the people who made them left, would be impossible to reconstruct?

  3. How is the current roadmap documented, and is the reasoning behind it as accessible as the list itself?

  4. What product debates does the team keep having that could be resolved by writing down a principle or a past decision?

  5. How does product knowledge currently flow between product, engineering, design, and customer-facing teams?

Things to notice

  • A roadmap is not product memory. It describes what is planned, not why it was chosen or what was learned when earlier versions shipped.
  • Product principles stated only in onboarding materials or annual all-hands presentations are not really principles: they need to be findable at the moment a decision is being made.
  • The people who built the earliest versions of a product hold context that is almost impossible to recover after they leave. Interview them while they are still there.