Field Guides

Everything here is live and public. Browse the Field Guides portal, or go straight into The Product Manager’s Atlas.

The problem

Useful knowledge is rarely in one place. On any topic and inside any organization, it is scattered across wikis, docs, web pages, PDFs, threads, Jira/Linear, and people’s heads. The information usually exists, but folks often resort to pinging their colleague for the tenth time on “where to find the most up-to-date thing.” The cost shows up as unnecessary coordination effort, errors from stale documentation, and suboptimal onboarding that drags on for months. People need a single source of truth: deep enough to trust, and fast enough that checking it beats pinging a colleague.

Who it’s for, and why it matters

Anyone who has to turn sprawl into something usable: a new hire getting up to speed, a team or Product Manager drowning in Confluence/Jira, Drive/SharePoint and Slack, or someone going deep on a subject worth knowing well (… or something they love). The topics here range from my own profession, product management, to things I just enjoy, like coffee and beer. I believe in spending less time searching and more time thinking.

What I built

Deep, interlinked knowledge bases (“field guides”) that pull an entire domain into one readable, navigable reference. Three so far, all built with the same repeatable method (read: Claude skills) rather than hand-crafted one-offs:

• The Product Manager’s Atlas: 126 notes, 2,316 verified links. My own field, product management, is mapped as a competency system from APM to CPO, plus a domain on how AI is reshaping the craft. (Field Guide 01)
• The Pour Over Knowledge Base: 147 notes, 2,920 verified links. Manual coffee brewing, from a first V60 to extraction theory and competition recipes. (Field Guide 02)
• The IPA Knowledge Base: 154 notes, 3,163 verified links. The India Pale Ale, from its contested origins to the modern hazy frontier. (Field Guide 03)

Browse all three guides →

The newest one is the one that matters most here. The Atlas is not just compiled from public sources. I folded the frameworks I have built and used to level and coach PMs into community-vetted best practice. The result is a field guide that is personal and specific, yet grounded in what the field agrees on. I believe this is how internal knowledge bases will be organized in the future, an organization’s proprietary knowledge, data, and insights, bundled with industry-wide information, in one place that aligns each individual on the way forward. Answers should be one or two clicks away, for everyone.

How it works

1. Architect first. Map the domain into an information architecture, the sections, categories, and atomic notes, before writing a word of content. This is where Claude and I go back and forth on structure, breadth, and depth. Adding some level of expert domain curation is a critical step to ensure the guide’s coverage and flow are on point.
2. Generate in parallel. Draft the notes with parallel Claude agents, using my voice or a predefined one. Each note is generated independently and cross-linked to the others via wikilinks for easy navigation.
3. Verify integrity. Review text for tone and syntax rules. Programmatically check every link: no dead ends, no orphan notes. Trust is the whole point of a reference, and it should read and work as if it were my own.
4. Generate assets. Produce custom visual assets to add a layer of personality and design aesthetic to the site. These are not critical and are imperfect, but they do the job they are built for.
5. Publish. Ship it as a fast static site.

The value is in the architecture and the integrity, not the word count.

Ask the Guide

A reference is only as good as how quickly you can get an answer from it. When I tested the guides with friends and family, it became clear that not everyone has time to scour a knowledge base. Expectations have moved too: in an AI world, search means an informed answer, not a page of links. So I built ‘Ask the Guide’.

Ask in plain language, “What does a Senior PM need that a PM doesn’t?”, “What grind size for a V60?” and get a short, direct answer drawn only from that guide’s own notes, with links to the exact notes it used if you want to go deeper.

The grounding is the whole point. The assistant answers strictly from the guide’s verified content; when the guide does not cover something, it says so instead of guessing. Every answer cites its sources. That is the line between “AI that might be right” and “AI that shows its work”, and it only holds because the notes underneath were already checked for integrity.

Mechanically: a same-origin serverless function retrieves the few most relevant notes (plain keyword matching over each guide’s corpus, no vector database, which a 150-note guide does not need), then Claude Sonnet 4.6 writes a grounded answer that streams back as you read. The API key stays server-side, and given this is an exploratory project, a hard $5/month spend ceiling is the real backstop, with per-visitor and global rate limits in front of it. If a limit is hit, the box falls back to keyword search so the guide never breaks.

Stack & architecture

Claude for research and drafting; an Obsidian-style Markdown vault as the source of truth; a wikilink graph as the connective tissue; an automated link-verification pass; static-site generation deployed on Vercel. On top of the static site, a single same-origin serverless function (/api/ask) powers the assistant: keyword retrieval over a per-guide corpus, then a grounded, streamed answer from Claude Sonnet 4.6, with the API key kept server-side.

How I measure success

The primary measure of success is answer-success rate. Does the guide answer the question or provide the avenue to retrieve the answer you are looking for? Given that this is not a truly measurable signal, feedback from users and click-throughs to individual notes are the best proxies. Bounce rate is not a feasible metric for a product where users may find what they are looking for and leave the site.

In addition to answer-success rate, other success indicators are:

• Coverage: does it actually span the domain end to end? For example, the PM Atlas runs from what the job is, through all twelve competencies, to a full career ladder from APM to CPO. However, product management is an evolving field with evolving roles and new insights need to be folded in over time to avoid becoming stale.
• Link integrity: a reference people cannot trust is worthless, so ensuring that each link takes users to the right place is important. All three guides pass an automated check: every one of the 2,316, 2,920, and 3,163 wikilinks resolves to a real note, and not a single note is left orphaned.
• Time-to-answer: can someone find and understand a thing quickly? The Ask the Guide assistant attacks this head-on: ask a question, get a grounded, cited answer instead of navigating notes by hand. This is a logical extension to optimize the answer-success rate.
• Grounded accuracy: the assistant answers only from verified notes and admits when the guide does not cover something. No hallucinated facts is the bar; citations make every answer checkable. These guides may not be perfect, but the aim is to be as close as possible.
• User reusability: do users come back for repeated use? This signals that the guides provided user value and can be trusted as a source for additional queries.
• Site reusability: the same pipeline produced three guides across unrelated domains, including my own profession. This is more of a measure of scalability, but it indicates that creating these guides is not overly costly and can be applied across different topics.

Product takeaways

• Designing this process to be transferable across topics improves efficiency and is where the value lies. This is the same problem every organization or person has: knowledge is fragmented across systems and sources, whether the domain is a hobby or a profession. Define the information architecture, automate the consolidation, and verify integrity so people can actually rely on the result. It scales to any area where you catch yourself asking the same question five times in five different ways.
• Connectivity beats volume. A well-structured, relationship-based, trustworthy set of 126 notes is worth more than 500 disconnected ones.
• Verified content is what makes an AI answer trustworthy. Grounding the assistant on a corpus already proven connected and correct turns “AI that might be wrong” into “AI that cites its source”. The integrity work pays off twice.
• Ease of use is as important as depth in an endless sea of answers. Adding in the ‘Ask the Guide’ feature helped solve a real problem of information density. Sometimes the job-to-be-done is to develop a comprehensive understanding, and a well-structured knowledge base does this. Other times, it is to answer a question as quickly as possible. Adding a function to address the second use case was valuable in extending the usefulness of the guides.

What’s next

• Expand the use-case to other Product-related domains. Can I build a guide for an industry, product type, or business model? How does the auto-generated process perform and scale when applied to other areas a Product Manager may experience in their day-to-day?
• Explore adding additional auto-generated visuals. Not all information is best conveyed via text, and not all people consume information the same way. Can these guides inject more visual-based content to better convey certain information? Could a dataset be connected to display graphs and other data-based diagrams?
• Personalization of guides. Are you a Senior Product Manager and want to prioritize SPM-level content and competencies over others? Can I save specific recipes for coffee brewing? There is an opportunity to add a level of personalization to these guides based on the user’s context, thus closing the gap between the guides’ breadth and depth and the easy-to-use but ephemeral ‘Ask the Guide’.

More of the guides