Reference
Glossary
Short definitions of the terms that keep showing up across falkster. Opinionated, not neutral. This is how I use these words , other practitioners draw the lines in different places.
Product Builder
A PM redefined for the AI era. Ships working software, not specs.
A Product Builder is the evolution of the product manager role in the AI era. Instead of translating between business and engineering through documents, a Product Builder prototypes in hours, designs AI workflows end-to-end, owns evals and unit economics, and ships alongside engineering. The job is still customer value; the medium changed from documents to working software.
Read the deeper playbook →Rapid Prototyping
Idea to working prototype in under four hours.
Rapid Prototyping is the practice of building a real, testable product in hours using tools like Claude Code — not a mockup or a spec, but something a user can click. This collapses the discovery-to-delivery loop and replaces the PRD as the primary artifact a Product Builder hands off. The breakthrough skill of the Product Builder OS; everything else is downstream.
Read the deeper playbook →Customer Proximity
AI compressed build time toward zero. Insight is the only durable edge.
Customer Proximity is the discipline of staying close to customer signal — sales calls, support queues, onboarding shadows, churn interviews, in-app feedback — every week, not every quarter. As AI compresses build time, the only durable edge is whoever understands the customer best. Product Builders own this loop daily, not the research team quarterly.
Read the deeper playbook →AI Fluency
You don't design RAG. You decide whether you need it.
AI Fluency is the discipline of deciding which AI primitive — rules, single model call, RAG, an agent with tools, fine-tuning — fits a workflow, and defending the choice in five minutes. Product Builders don't build retrieval pipelines or tune embeddings; engineering does. The Product Builder owns the decision and the workflow the primitive lives inside.
Read the deeper playbook →Outcomes Thinking
Did the spec ship? Wrong question. Did the customer behavior change?
Outcomes Thinking is the discipline of defining the customer behavior change you'll cause — and the signal that proves it — before the team starts building. Evals are one tool inside this skill (they're the outcome contract for an AI feature), but the broader practice is naming the outcome, instrumenting the proof, and refusing to count tickets as progress.
Read the deeper playbook →Storytelling & Distribution
Great products lose to mediocre products with better stories.
Storytelling & Distribution is the joint discipline of naming the work, writing the launch headline, picking the channels, and personally running rollout to the first 100 customers. AI has commoditized building, so the differentiator collapses to whoever can land the story and place it where customers actually find it. Product Builders write the tweet before the spec.
Read the deeper playbook →End-to-End Ownership
Insight to prototype to launch to gross margin to next iteration.
End-to-End Ownership is the meta-skill of holding the whole arc — customer signal → prototype → ship → launch narrative → gross margin → next iteration — in one head. The builder/PM/founder/GTM line is collapsing. Product Builders who only own delivery own a shrinking slice; the ones who own the full arc define the role.
Read the deeper playbook →Prototype-First Development
Prototypes replace specs as the primary product artifact.
Prototype-First Development is the pillar practice of building a clickable, testable prototype before writing a PRD or running a sprint planning. The prototype becomes the shared source of truth for customers, engineering, and leadership, far more informative than any document.
Read the deeper playbook →Continuous Discovery
Weekly customer conversations, OSTs, and assumption testing, on autopilot.
Continuous Discovery is the practice of running customer research every week, not every quarter, with Opportunity Solution Trees mapping what you are learning and assumption-testing before building anything. In the AI era, agents handle the mechanical overhead, scheduling, transcription, synthesis, so PMs can spend their time on judgment.
Read the deeper playbook →Impact Loop
OKRs tied to behavior change, not feature launches.
The Impact Loop is the planning pattern where outcomes are measured as behavior changes in customers, not as features shipped. If engagement, retention, or revenue does not move, the feature did not ship. This is the only scoreboard that matters.
Read the deeper playbook →AI Agent Fleet
The set of production agents a PM operates daily.
An AI Agent Fleet is the collection of specialized agents a Product Builder runs in production, for daily focus, product health monitoring, competitive intel, roadmap tracking, release readiness, and more. The Product Builder's job shifts from writing tickets to tuning the fleet.
Read the deeper playbook →Product Operating Model
How product orgs actually run now, before and after AI.
The Product Operating Model is the full pattern of how a product organization works: who decides what, how discovery and delivery connect, how AI agents fit into the org chart, and how quality is measured. The before/after AI version is the load-bearing frame for the handbook.
Read the deeper playbook →Vibe Coding
Building software by describing what you want and iterating with an AI.
Vibe Coding is the practice of writing software by describing intent to an AI coding assistant (Claude Code, Cursor, Windsurf) and iterating on the result until it works, rather than writing every line by hand. It is the core skill that makes Rapid Prototyping possible for non-engineering PMs.
Opportunity Solution Tree (OST)
Teresa Torres's tree for mapping outcomes, opportunities, and solutions.
An Opportunity Solution Tree is a visual model, popularized by Teresa Torres, that links a product outcome to the customer opportunities that would move it, and the experiments that would test each opportunity. It is the backbone of modern discovery practice.
Read the deeper playbook →Trust Ledger
A running log of every commitment a new leader makes in the first 90 days.
A Trust Ledger is a file a new executive keeps from hour one of a new role: every commitment made, to whom, by when, and its status, reviewed every Friday. New leaders bleed credibility through small dropped promises they never noticed making; the ledger makes the bleed visible and turns trust at day 90 into compound interest on a four-minute daily habit.
Read the deeper playbook →Listening Ledger
The structured replacement for the executive listening tour.
A Listening Ledger replaces the 40-coffee-chats listening tour with structured interviews logged as falsifiable claims, each with a source, a confidence score, and the claims it contradicts. The contradictions between functions, sales versus engineering versus customer success, are the real signal a new leader is hired to find. A tour produces a word cloud; a ledger produces evidence.
Read the deeper playbook →Decision Archaeology
Reconstructing the last 90 days of decisions before forming opinions.
Decision Archaeology is the practice of reconstructing the recent decisions in a product area you just inherited: merged PRs, launch posts, killed projects, escalations, pricing changes, and for each, who raised it, where it was debated, and what evidence was in the room. It is the fastest way for a new PM or CPO to learn how the org actually works, as opposed to how the wiki says it works.
Read the deeper playbook →Signal Map
Where truth enters the building. The replacement for the stakeholder map.
A Signal Map documents every place customer truth enters a company, support queues, sales call recordings, churn surveys, product analytics, community channels, the engineer who quietly knows everything, and whether each source is captured, synthesized, and routed to anyone. A stakeholder map tells you who has power; a signal map tells you where the evidence lives. The gaps in it are a new PM's first real findings.
Read the deeper playbook →Manager Contract
A one-page expectations doc co-written with your manager in week one.
The Manager Contract is a one-page document a new PM co-writes with their manager in the first week: what I own, what good looks like at day 90, how decisions get made between us, and what you are silently worried about. Most onboarding failures are expectation mismatches that were never written down. The contract converts an ambient vibe into an editable artifact, and the day-90 note closes it.
Read the deeper playbook →Day-90 Readout
The real deliverable of an executive's first 90 days. SCQA-shaped.
The Day-90 Readout is a memo a new product leader delivers at the end of the first quarter: where the product actually is, the constraints that matter, the bets and explicit anti-bets, the kill list, and the scoreboard to be judged on for the next year. Structured as SCQA (situation, complication, question, answer) and written to be read, not presented. It is the artifact the board quotes back for a year.
Read the deeper playbook →Skill Stack
The five layers of skills that decide PM and CPO careers now.
The Skill Stack is the post-AI map of product skills in five layers: judgment (problem selection, decision quality, taste), expression (storytelling, writing for machines, prototyping), systems (evals, agent orchestration, signal architecture), economics (unit economics, pricing), and leadership (coalition building, killing things well). Execution coordination, the old core PM skill, dropped out of the stack because agents absorbed it.
Read the deeper playbook →Judgment Reps
Training decision quality deliberately, with a log and a scorecard.
Judgment Reps is the practice of treating decisions as bets and training on them: log each significant decision with the evidence at the time and a confidence percentage, set a review date, then score decision quality separately from outcome quality (Annie Duke's distinction). Most PMs make hundreds of decisions and learn from none, because nothing was recorded. The decision log is the gym.
Read the deeper playbook →Writing for Machines
Half your readers are now agents. Write so they execute faithfully.
Writing for Machines is the craft of producing documents whose primary readers are AI systems: specs that coding agents implement (labeled examples beat adjectives), content that answer engines can extract and cite (short-version blocks, FAQ pairs, named entities), and briefs that keep an agent fleet stable. The only eval that matters is the cold-read test: run your document through a model with no verbal context and score the gap.
Read the deeper playbook →Using a term differently? Think I'm drawing the line in the wrong place? Tell me.
Send a note →