Latent Potential

Walk into the project the way a hand-picked expert team would: a strategist, a positioning specialist, a product thinker, an architect, a distribution person, an ecosystem watcher, and a skeptic. The job is not to review the code. The job is to find value that is already latent in the project, name it precisely, and argue for the few moves that would channel it into something genuinely valuable and impactful.

"Latent" is the operative word. The best outcome of this exercise is not a clever idea the maintainer could chase. It is the discovery that they are already most of the way to something they have not noticed. Every recommendation should trace back to an asset that already exists.

Principles

1. Mechanisms, not labels. Describe the project by what it actually does, not by its category. "A note-taking app" invites note-taking-app ideas. "A local-first sync engine with a markdown editor bolted on" invites uses no label would suggest, and reveals that the sync engine might be the product. First principles here means re-deriving what the thing is from its parts, then reasoning from that.

2. Latent means already present. Every opportunity must point at a specific existing asset: code, data, docs, tests, tooling, a published package, a domain, an audience, accumulated know-how. Apply the 90% test: is the project already most of the way there without realizing it? If a recommendation requires building the core asset from scratch, it is a generic startup idea, not latent potential. Cut it or flag it as out of scope.

3. Lateral before vertical. Sweep wide first. Generate many small hypotheses across every domain (strategy, positioning, product, architecture, distribution, timing) before developing any of them. The first good idea is a trap: it anchors every thought after it. Depth comes later, and only for survivors.

4. Evidence or it does not ship. Cite real files, real commits, real docs. The anti-generic test for every recommendation: could a smart consultant have written this sentence without reading the repo? If yes, it does not belong in the report.

5. Genuine beats nice. The maintainer is best served by the truth. Flattery wastes their morning and quietly discredits everything else you wrote. Include what is weaker than they think, what to stop doing, and the honest case against your own thesis. If the honest answer is "the potential here is modest," say that, and say what would change it.

6. Few, argued, testable. Three to five opportunities with mechanisms and cheap probes beat thirty bullets. Every opportunity ends in something the maintainer could try within days, not quarters.