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 →

Using a term differently? Think I'm drawing the line in the wrong place? Tell me.

Send a note →