# The Falkster Corpus: AI Product Management How AI changes the product role: what compresses, what does not, and what replaces the PRD. Written from practice, not prediction. The claim: AI did not make product management harder. It collapsed the cost of the parts PMs were trained to be good at, and left the parts nobody trained for. Source: https://falkster.com/corpus · Built 2026-09-19 · Author: Falk Gottlob Contents: 73 pieces on this topic ## How to use this Paste this file into your assistant's project knowledge (Claude Projects, a ChatGPT project, a Cursor rule file, an AGENTS.md), then work normally. The point is not to ask it about the corpus. The point is that when you ask it to size a bet, write a brief, or decide what to kill, it answers the way this practice answers instead of the way the average of the internet answers. Every entry carries a canonical link. When something here matters to a decision, follow the link and read the argument. A summary is enough to act on and not enough to disagree with. ## Attribution Written by Falk Gottlob. Free to use for your own work and your team's. When it shows up in something public, cite it as: Falk Gottlob, falkster.com, with the canonical link. Not licensed for republication, resale, or model training. --- ## Everything on this topic (73 pieces) Each entry is the piece's own extractable summary. Follow the link for the argument. ### The AI Eval Starter Kit: Six Templates, Error Analysis to Gate Published: 2026-09-19 Canonical: https://falkster.com/blog/ai-eval-starter-kit Six templates in one markdown file. An error analysis log that makes you read fifty outputs before you build anything. An eval type chooser that walks from the cheapest measurement to the most expensive and stops at the first that fits. Four code assertions in Python, including Torres's quote-verification hallucination guard. A golden dataset format with the two columns most teams forget, who labeled the row and who confirmed it. An LLM-as-a-judge prompt with a rubric skeleton and a rule that the judge always sees the source. And an experiment log paired with a gate table, one row per action, where reversibility decides autonomy and model confidence never does. Method credit to Torres. The gate, the tier columns, and the log are additions. ### Torres Wrote the Evals Guide PMs Needed. Here Is Step Four. Published: 2026-09-19 Canonical: https://falkster.com/blog/torres-ai-evals-what-i-would-add Torres's framework is three steps: error analysis by hand to find the recurring mistakes, choose an eval type that matches the error (code assertions, golden datasets, LLM-as-a-judge, or customer feedback signals), and run an experimentation loop of baseline, change, compare. Her rule that correctness is the product team's job and never the vendor's is the line to frame. I'd add a fourth step, where a passing eval on a reversible action buys autonomy and a passing eval on an irreversible one buys a draft and a human, so the eval becomes the gate rather than the scoreboard. I'd add a cost column, because every judge call is margin. And I'd add a warning: a golden dataset labeled by a cheap model measures agreement with a cheaper version of the thing you are evaluating, not correctness. Her fourth eval type, customer feedback, is the one that compounds, because it is the observation record and it ports nowhere. ### The FDE Is the Product Builder Wearing a Visitor Badge Published: 2026-09-17 Canonical: https://falkster.com/blog/forward-deployed-engineer-product-builder The forward deployed engineer is an engineer employed by a vendor, embedded in a customer, and accountable for the outcome the software produces there. Palantir popularized the role around 2008 and ran four vintages of it; the one thing that survived every vintage is customer accountability. The role exploded in 2026 because code got cheap and outcome pricing arrived, and both make the person who guarantees the result the scarcest seat in the company. That seat needs the same six skills the Product Builder OS describes. The FDE arrived at them from services. The Product Builder arrived from product. Same collapse, one seat. I wrote it up as a new wave of the handbook, seven chapters, because the two mistakes companies are making with the role, confusing it with sales engineering and sending engineers into customers before the product can absorb what they learn, are both expensive and both avoidable. ### Cagan's Definition Is Right. The Weights Are Wrong. Published: 2026-09-15 Canonical: https://falkster.com/blog/cagan-definition-weights Cagan's August 2026 piece maps Benedict Evans's three product skills, problem discovery, solution discovery, and business viability, onto the risk framework SVPG has used for years, and concludes the product role's definition survives AI intact. The skills do survive. What does not survive is the assumption that they are one job in roughly equal parts. Solution discovery is the most AI-exposed skill in product work, because generating options is now free and the surviving skill is selection rather than generation. Problem discovery is intact but its input changed, since listening agents remove the bottleneck on how much pain one person can personally hear. Business viability barely moved, which is exactly why it is becoming the majority of the job: it is a consent problem across a company, not an information problem, and consent does not compress. A definition that does not say which third is growing is accurate and not actionable. ### Polish Stopped Being Evidence Published: 2026-09-08 Canonical: https://falkster.com/blog/polish-stopped-being-evidence The design review is not obsolete, but the signal it ran on is. For twenty years reviewers read fidelity as a proxy for conviction: grayscale meant early thinking, pixel-perfect meant someone had lived with the problem. AI broke that proxy, because a polished screen can be forty minutes old and carry no conviction at all. The predictable failure is that the work that looks most finished now gets the shallowest critique. The fix is to move the signal off the artifact and into the room: a stated confidence level before each presentation, the brief on screen before the pixels, and a critique aimed at the choice rather than the output. Options are free now, so "what did you kill and why" is the question that separates choosing from picking. This is the same argument as [Prototype Before You Spec](/handbook/instant-prototyping), arriving from the review side of the table. ### The Week the Prototype Beat the Spec Published: 2026-08-12 Canonical: https://falkster.com/blog/the-week-the-prototype-beat-the-spec We had a feature stuck in review for three weeks: a twelve-page spec, four reviewers, and a debate that would not resolve because everyone was arguing about what a user would do and nobody knew. I stopped writing and built a clickable prototype in an afternoon with Claude Code, put it in front of five customers, and four of them reached for the wrong control first. The feature we had specced for three weeks was built around an interaction nobody used. The prototype did not win because it was better looking. It won because it produced evidence the spec could only guess at. When the cost of being wrong drops from three months of engineering to half a day, the spec stops being insurance and becomes an expensive way to keep arguing. I now build first and write the doc after, as a record of what we decided, not a bet we then defend. ### What Landing Actually Is Published: 2026-08-12 Canonical: https://falkster.com/blog/what-landing-actually-is Shipping is the code reaching production. Launching is the announcement reaching the market. Landing is the thing that matters and the thing nobody owns: a customer's behavior durably changes and the value sticks. You control shipping and launching completely. Landing happens on the other side of the glass, in a person's real workflow, which is why it is hard and why cheap building did not touch it. There are four ways landing fails, and each one looks like success on launch day: the demo that never becomes a habit, the onboarding that activates once and goes silent by month two, the launch with no owner past GA, and the feature that gets used but moves no number. The test for whether something landed is simple and unforgiving. Point at a behavior a customer used to do differently, that they now do with your product, and would be annoyed to lose. If you cannot, you shipped and you launched. You did not land. ### What Replaces the PM Ladder When the Deliverables Are Gone Published: 2026-08-12 Canonical: https://falkster.com/blog/what-replaces-the-pm-ladder When documents stop being the promotion currency, leveling has to run on judgment instead of output, which is harder to see and harder to game. The evidence at every level is the same three things: a shipped surface with a metric and your fingerprints on why it moved, an eval you own that caught a real failure, and a bet made with the reasoning written down before the outcome was known. What scales across levels is not the volume of that evidence but the size of the bet you are trusted to make without a net and the blast radius when you are wrong. L4 owns one surface and proves the loop works. L5 owns a workflow and sets the eval bar others inherit. L6 owns a pillar and is trusted with bets that are expensive to reverse. Principal sets the standard the whole pillar is judged against. The constraint most orgs hit is not the rubric, it is whether their calibration room can read a prototype-and-eval workflow well enough to tell a good bet from a lucky one. ### Twelve Builders, Twelve Products, Zero Landings Published: 2026-08-09 Canonical: https://falkster.com/blog/twelve-builders-twelve-products-zero-landings The 2026 CPO Insights Report says product managers disappear by 2030 and product builders take their place. The role is real, and the numbers behind it are real: PM roles down 30% across industries and up to 70% inside SaaS, builder roles up 10x in a year. But the framing points at building, at exactly the moment building stopped being the constraint. Buried in the same report is the finding that undoes the headline: speed to market is now the number one internal challenge CPOs report, and the bottleneck moved from building to launching. Twelve builders delivering twelve products is only a win if twelve products can land. The scarce skills now are judgment about what should exist, evals written before code, downside sized honestly, and adoption. None of them come with a title change. If your builders still need three approvals to reach a customer, you renamed a role, you did not change your operating model. ### How I Build Eval Rubrics Published: 2026-07-24 Canonical: https://falkster.com/blog/how-i-build-eval-rubrics Building an eval rubric is not a writing task, it is an extraction task. Do not start by writing criteria. Start by grading thirty real outputs with nothing but gut feel and a notes column, then extract the rubric from your own disagreements with yourself. Keep a dimension only if failing it maps to a real cost (user harm, trust erosion, or rework), which is [downside exposure](/blog/rank-ai-features-by-downside-exposure) applied to the rubric. Score each dimension binary, pass or fail, not on a 1-5 scale, because scales hide disagreement and binaries force it into the open. Version the rubric like code, with every model or prompt change as a review trigger. Then ship it as a template the team runs on every diff. The template is not the hard part. The judgment you extract before you write it is. ### AI Can't Understand the User. That User Is Disappearing. Published: 2026-07-16 Canonical: https://falkster.com/blog/ai-cant-understand-the-user The most confident defense of the human PM goes like this: let AI write the PRD and run the standup, it will never do the one thing that matters, it can't understand the user. I used to give that speech. I've stopped, because it rests on a hidden assumption that no longer holds. The user we spent careers learning to understand is not a person, it is a departmental role: the AP clerk, the SDR, the tier-one support agent, the recruiting coordinator. We built personas around those roles because software was sold per seat into departments, so the user was the seat. Agents are now dissolving the departments. The workflow that defined the job gets absorbed, and the person left standing is a cross-departmental operator supervising outcomes across three functions that used to be three users. So the moat isn't wrong about empathy. It is aiming empathy at a user who is on the way out. Understanding the future user is less about deeper feeling for a fixed role, and more about reading outcomes that don't map to any persona doc you own. Here is why the user is disappearing, and what replaces the discovery job built on top of them. ### Is This Product Bet Group Stage or Knockout? Reversible vs. Irreversible Published: 2026-07-15 Canonical: https://falkster.com/blog/world-cup-group-stage-or-knockout Every product bet is group stage or knockout. The World Cup is two tournaments in one: a forgiving group stage where you can lose a match and still advance, and an unforgiving knockout where one bad day sends you home. Product decisions split the same way, and the common mistake is treating a knockout bet, where a single silent failure ends you, like a group-stage bet you can afford to lose. This is downside exposure in a football shirt: group-stage decisions are reversible experiments that can survive a bad week, knockout decisions are the features where one quiet quality drop churns the account with no replay. The whole event is also a seeded bracket you design through qualification, and tight knockouts are won on set pieces, which are your evals. Before any bet, ask one question: group stage or knockout? ### Stage Wins or the Yellow Jersey: You Don't Win the Tour by Winning Stages Published: 2026-07-14 Canonical: https://falkster.com/blog/tour-de-france-ai-product-management You do not win the Tour de France by winning stages. It is a 21-stage race decided on cumulative time, and the rider with the most stage wins almost never wears the yellow jersey at the end. AI product management works the same way. The win is cumulative outcome across many cheap bets, not the flashiest launch, and chasing stage wins, the visible daily victory, is how teams lose the general classification that actually counts. Three things carry over: the leader wins on an invisible team of domestiques, which in an AI-native org is your agent fleet plus product ops doing the pulling; you choose your terrain instead of contesting every stage, which is tournament design; and the yellow jersey goes to whoever spent judgment best over three weeks, not whoever was strongest on any single day. ### The Product Builder Was Never About Coding Published: 2026-07-11 Canonical: https://falkster.com/blog/product-builder-was-never-about-coding Product Builder was never about a PM learning to write React. LinkedIn replaced its APM program with a Product Builder program, and most coverage read it as a generalist story: PMs who can touch design, product, and engineering. That is the surface. The real shift is collapsing the distance between deciding and making. The traditional PM job was coordination, a relay race that existed only because turning an idea into a working artifact was expensive and slow. When one person can go from idea to prototype in an afternoon, the specialization that justified the handoffs stops paying for itself. So framing Product Builder as a skills question solves the wrong problem. The right question is organizational: what do you still need a coordinator for once the person with the idea can produce the artifact? ### The PRD Was Already Dead. Slack Proved It in Public. Published: 2026-07-09 Canonical: https://falkster.com/blog/slack-squads-killed-the-roadmap The PRD was already dead, and Slack proved it in public. Instead of quarterly roadmap commitments, Slack is reportedly running small cross-functional squads, sometimes one designer and one engineer, that prototype continuously and let evidence decide direction rather than a plan decide it in advance. This is not a scrappy startup habit; it is a company with the resources to run traditional planning choosing not to. At scale the fixed roadmap is the thing that breaks, because commitments made months out are made on stale information, and AI makes information decay faster than a quarterly cycle can track. What replaces the roadmap is not chaos but a different discipline: a shared brief and a shared definition of a good outcome, with the destination allowed to change as the prototype teaches you what you are actually building. ### Stop Picking Winners. Design the Tournament. Published: 2026-07-08 Canonical: https://falkster.com/blog/stop-picking-winners-design-the-tournament Cheap prototyping did not kill product judgment, it moved the judgment up a level. When testing an idea cost a quarter of engineering time, the first decision picked the winner and we wrapped it in a twelve-page PRD. When testing an idea costs an hour, the first decision picks the bracket: which eight of fifty backlog ideas get prototyped at all. Same judgment, radically cheaper to be wrong. The job moved from picking winners to designing the tournament, a portfolio exercise built on three questions: which ideas are cheap to test and expensive to skip, which ideas share one prototype, and which cannot be settled by a prototype at all. Marton Gaspar named the failure mode as cosplay: PMs who drop the betting to become part-time engineers running an unseeded tournament where whatever got built first wins. ### Rank AI Features by Downside Exposure, Not Engagement Published: 2026-07-07 Canonical: https://falkster.com/blog/rank-ai-features-by-downside-exposure Stop ranking AI features by engagement or revenue attribution. Rank them by downside exposure: if this feature's quality quietly dropped 20% tomorrow, how fast would it cost you customers? Downside exposure is a function of three things, revenue flowing through the feature's workflow, the cost of a wrong answer, and how reversible the damage is. Score every AI feature on those axes and the ranking rarely matches your dashboard. The flashy high-engagement feature lands mid-table, and the boring feature buried in the customer's core workflow tops the list. That top feature is, almost by definition, the one nobody is watching and the one with the stalest evals. Point your eval budget at downside exposure, not usage. ### Storytelling for PMs: The Skill That Decides Whose Evidence Wins Published: 2026-07-06 Canonical: https://falkster.com/blog/storytelling-is-a-pm-core-skill Decisions propagate through retellings, so your argument has to survive being repeated by someone else when you are not in the room. Three frameworks cover 90% of PM situations: SCQA and the Minto pyramid for memos and readouts, the working-backwards PR/FAQ for new bets, and the premortem narrative for risk conversations. Verbatim customer quotes are your load-bearing beams because they are data already wearing narrative. This post is the deep dive on the storytelling skill from [The Skill Stack: What PMs and CPOs Must Learn Now](/handbook/skill-stack), with worked examples, a 4-week practice plan, and an opinionated resource list. The companion craft for product proof is in [show, don't tell](/blog/show-dont-tell). ### Downside Exposure, Extended: When the Model Is Wrong About You Published: 2026-07-02 Canonical: https://falkster.com/blog/downside-exposure-when-the-model-gets-you-wrong Downside exposure, extended. The original framework was first-party risk: your product's AI feature gives a wrong answer to your own customer, and you rank features by how fast a silent quality drop would cost you customers. That still holds. The second half is second-party risk: as more of the discovery and evaluation layer runs through AI systems you do not control, comparison tools, procurement assistants, general assistants fielding which-vendor questions, the model can get you wrong and you never find out until a deal dies for a reason no one traces back to you. You cannot instrument it the way you instrument your own product. What you can do is treat your documentation and positioning as an eval target: periodically ask a general model, cold, to describe your product, and fix the documentation wherever the answer is vague, wrong, or generic. ### The PRD Collapsed Into Three Artifacts (Brief, Prototype, Eval) Published: 2026-07-02 Canonical: https://falkster.com/blog/prd-collapsed The PRD did not die, it collapsed. The single document was doing three jobs at once, alignment, commitment, and memory, and it did all three badly because a wall of prose is the wrong format for every one of them. Those jobs now split into three artifacts, each better at one job than the old document was at all three. Alignment moves to a **prototype** (a working render aligns a team faster than a spec they have to interpret). Commitment moves to an **eval** (a rule you can run, that fails the build, instead of a sentence nobody rereads). Memory moves to a **one-page brief** plus the eval's rationale (a document you reread is memory, a document you do not is an archive). I posted a version of this and twenty-one PMs pushed back. Under all of it were only four objections, and the answer to each is one of these three artifacts. The templates are below, and they are copy-paste. This is the same shift behind [prototype-first development](/handbook/instant-prototyping) and the [outcome-driven build loop](/handbook/impact-loop). ### The PR/FAQ Template: Amazon's Working Backwards for Your Bets Published: 2026-07-01 Canonical: https://falkster.com/blog/pr-faq-template The PR/FAQ is Amazon's working backwards format, documented by Colin Bryar and Bill Carr: a one-page mock press release announcing the finished product, plus an FAQ split into external questions (what customers would ask) and internal questions (the hard ones: unit economics, the quality bar, the biggest risk, what you are deliberately not building). It is read in a 60-minute narrative meeting that opens with 20 minutes of silent reading and closes with an explicit decision. Use it for one-way doors and quarter-scale bets, never for small iterations. It is the working-backwards discipline behind storytelling in [the skill stack](/handbook/skill-stack), and the deep dive on why narrative wins decisions is [storytelling is a PM core skill](/blog/storytelling-is-a-pm-core-skill). ### AI Evaluators Are Your New PM Audience Published: 2026-06-30 Canonical: https://falkster.com/blog/ai-evaluators-are-your-new-pm-audience AI evaluators are your new PM audience. AI systems increasingly decide whether your product gets recommended, compared, or dismissed before a human ever sees it, so product legibility to a model is now part of your funnel. This is not SEO with a new coat of paint: SEO optimized for ranking, this optimizes for being correctly understood and correctly recommended by a system reasoning about your product on someone else's behalf. Get it wrong and the AI does not rank you lower, it describes you inaccurately or leaves you out of the comparison. The new deliverable is a structured, machine-readable statement of what the product does, who it is for, and how it differs, kept accurate as the product evolves. Fold it into downside exposure: ask what an outside AI needs to know to evaluate your product correctly. ### PM Days 61 to 90: Own One Bet and Kill One Commitment Published: 2026-06-29 Canonical: https://falkster.com/blog/pm-days-61-90-own-a-bet PM days 61 to 90 convert standing into ownership through two moves. First, own one bet: a single outcome sized to a quarter, backed by evidence from your own archaeology and signal map, with a falsifiable measure and a date, written as a one-pager and pre-wired through your signal map relationships before any meeting. Second, kill or renegotiate one inherited commitment, the safest one, with an evidence memo and a replace-not-remove script. Close the quarter with a day-90 note to your manager: found, shipped, betting, killed, measure-me-on. The method for the kill lives in [The Anti-Backlog](/handbook/the-anti-backlog), and the templates are in [the PM First-90 Kit](/blog/pm-first-90-kit). ### The Decision Log Template: Train Judgment Like a Muscle Published: 2026-06-26 Canonical: https://falkster.com/blog/decision-log-template The decision log is one row per significant decision: what you decided, whether it was a one-way or two-way door, the evidence you had at the time, your confidence as a percentage, what would change your mind, a review date, and later the outcome and a quality verdict. The discipline comes from Annie Duke's separation of decision quality from outcome quality and Gary Klein's premortem for big bets. Logging takes ten minutes a week. The quarterly calibration review, where you score your confidence numbers against what actually happened, is where judgment gets trained. This is the instrument behind [judgment reps](/blog/judgment-reps), and decision quality sits in the judgment layer of [the skill stack](/handbook/skill-stack), the layer agents cannot reach. ### PM Days 31 to 60: Ship One Artifact That Compounds Published: 2026-06-22 Canonical: https://falkster.com/blog/pm-days-31-60-first-artifact PM days 31 to 60 have one job: ship one compounding artifact and let it earn your seat in decision rooms. Four options: a synthesis of 20 customer calls, an eval set for the next roadmap feature, a live page replacing a manual weekly ritual, or a prototype that ends a circling debate. Choose by team weather, not preference: synthesis for narrative-driven teams, eval set for engineering-led ones, live page for data cultures, prototype for opinion deadlocks. Build it in two to four days on the agent stack from [The PM Agent Stack](/handbook/pm-agent-stack), deliver it with a short memo, then read the reaction data. Artifacts get forwarded, and forwarded artifacts get you invited. ### I'm a Company of One Because I Refused to Vibe Code Published: 2026-06-18 Canonical: https://falkster.com/blog/company-of-one-refused-to-vibe-code I just crossed about $1.5M in ARR as a company of one, with Heidi in development for under two months. The reason it works is the part nobody puts in the announcement: I refused to vibe code. A solo founder has no team to absorb the maintenance that vibe coding quietly assumes, so the only thing that survives without hands to keep it upright is structure. I built agentic engineering from the first line, the substrate of specs, evals, guardrails, and review, and the substrate does the carrying a team would otherwise do. Vibe coding is low CapEx and high OpEx, and a company of one cannot afford the OpEx. This is the [vibe coding crossover point](/blog/vibe-coding-crossover-point) made personal: the company of one is only possible on the far side of it, where the structure you paid for early keeps the system standing without people. ### Kill the 'I Built It in a Weekend' Flex Published: 2026-06-18 Canonical: https://falkster.com/blog/kill-the-built-it-in-a-weekend-flex The "I built it in a weekend" post is a vanity flex, and it should be retired. Speed to demo measures the cheapest, least durable thing you can produce, the first working screen, which is exactly what vibe coding is optimized for and exactly the side of the cost curve before maintenance bites. A weekend build proves nothing about whether the thing survives real users, real edge cases, or its own second month. Building fast is a real skill, and a prototype you throw away is healthy. The flex is the problem: it celebrates time to first output as if it were time to durable value, and it trains teams to optimize the half of the [cost curve](/blog/vibe-coding-crossover-point) that does not matter for anything they intend to keep. The only question worth asking about a weekend build is whether it was still running the weekend after. ### The Mental Models That Break When Building Gets Cheap Published: 2026-06-18 Canonical: https://falkster.com/blog/mental-models-that-break Most popular mental models, the ones that show up in every "frameworks for better decisions" grid, are economics with the assumptions hidden. The biggest hidden assumption is that building is the expensive, scarce, slow part of any system. For forty years that was true. AI is ending it. When the cost of building collapses, four of these models invert and quietly start giving the wrong answer: Opportunity Cost, Bottleneck, Sunk Cost Fallacy, and Local vs Global Optimum. A few get sharper instead, because they were never about cost: First Principles Thinking, The 5 Whys, and Incentives. The dangerous part is that an inverted model still feels right, because the framework looks unchanged. So the move is to run a Chesterton's Fence check on your own head: find which of your mental models still price building as scarce, and retire the ones that do. ### The Vibe Coding Crossover Point: Google's New SDLC Whitepaper Published: 2026-06-18 Canonical: https://falkster.com/blog/vibe-coding-crossover-point Google published a whitepaper, The New SDLC With Vibe Coding, authored by [Addy Osmani](https://addyosmani.com) (a Director at [Google Cloud AI](https://cloud.google.com/discover/what-is-vibe-coding)) with Shubham Saboo and Sokratis Kartakis. It draws a sharp line between vibe coding, which is prompt-and-ship development optimized for speed to first output, and agentic engineering, which is AI development with structure: specs, guardrails, evals, and review. The key picture is a cost curve. Vibe coding starts cheap and climbs steeply. Agentic engineering costs more upfront and then flattens. The two cross, and past the crossover point vibe coding costs 3 to 10x more per feature. That is a CapEx versus OpEx story: vibe coding is low CapEx and high OpEx, agentic engineering is the reverse. The durable principle is the one I have bet Falkster on, structure scales and vibes don't, and the practical move is to decide whether a thing is a prototype or a product before the curve turns on you. ### The Product Strategy Memo Template (Pyramid Principle) Published: 2026-06-17 Canonical: https://falkster.com/blog/strategy-memo-template The template is a six-page maximum SCQA memo. The answer comes first, in one sentence at the top, per Minto. Then situation, complication, and question establish the shared ground and the choice. The answer section breaks into three grouped arguments, each a full sentence, each with three evidence slots: data, verbatim customer quotes, competitive. Then anti-bets, a premortem-sourced risks section with "what would change my mind" lines, and an ask that names a decision and a date. Final QA is the retelling test. This memo is the engine behind [the day-90 readout in the CPO First-90 Kit](/blog/cpo-first-90-kit) and the long-form version of the discipline in [Investor and Board Narrative](/handbook/investor-and-board-narrative). ### Your First 30 Days as a PM: Build a Signal Map, Skip the Coffee Chats Published: 2026-06-12 Canonical: https://falkster.com/blog/pm-first-30-days-signal-map Your first 30 days as a PM should produce a model of the org, not a contact list. Three moves: run decision archaeology on the last 90 days of your product area (five places to dig, five questions per decision, an agent does most of the work in an afternoon), build a signal map of the seven places truth enters the building and audit whether each gets captured, synthesized, and routed, and write a manager contract in week one that includes the question "what are you silently worried about." Hold all opinions until day 31. Templates are in [the PM First-90 Kit](/blog/pm-first-90-kit). ### PM Skills 2.0 Is Half a Funeral and Half a Blueprint Published: 2026-06-12 Canonical: https://falkster.com/blog/pm-skills-2-funeral-blueprint PM Skills 2.0 by Paweł Huryn is the best free PM tooling on GitHub: 68 Claude skills, 42 commands, 9 plugins, MIT-licensed, roughly 12,000 stars. Two pieces are new thinking. The /red-team-prd command turns any PRD or roadmap into ranked kill-assumptions with fails-if conditions and cheap tests. The AI Shipping Kit (/ship-check) audits the gap between what an AI-built system was supposed to do and what the code actually does, which is the unsolved accountability problem of 2026. The rest of the catalog encodes the legacy PM artifact stack, RICE matrices and PRD templates and canvases, and automating that scaffolding just builds scaffolding at machine speed. Install pm-ai-shipping and pm-execution, skip the other seven plugins, and do not mistake faster documents for better judgment. ### Cagan Built the Church. I Argue We Don't Need One. Published: 2026-06-09 Canonical: https://falkster.com/blog/cagan-vs-product-builder Marty Cagan and I are now describing the same future. His product operating model, the empowered product team, dual-track discovery, the PM who owns outcomes, was a brilliant description of how scarce engineering capacity should be rationed. AI erased the scarcity. When an agent produces a working prototype in an afternoon, a philosophy built on rationing build capacity is solving last decade's constraint, and Cagan's own 2026 writing concedes it. The product builder thesis I argue for, PRD as output not input, prototype-first, the PM role dissolving into building, is better aimed at the new constraint: judgment and taste are scarce, build capacity is not. But it has its own holes, a survivorship problem, a thinking-never failure mode, and an unsolved coordination story, that most posts comparing product philosophies refuse to name. Here is the honest version of both. ### The Prototype Graveyard: Why Cheap Demos Kill Good Ideas Published: 2026-06-05 Canonical: https://falkster.com/blog/the-prototype-graveyard Prototype-first is my thesis. When building collapses to nearly free, the working prototype beats the written argument, and I have made that case across this whole site. This post is the asterisk I owe it. Cheap prototyping has a failure mode almost nobody who advocates for it, including me, names clearly: when building is free, the demo quietly replaces the argument, and good ideas die because a rough first prototype made them look like bad ideas. The graveyard fills with strong concepts killed by weak demos, because no one stated what a fair test would even be before opening the editor. The fix is not prototyping less. It is stating a falsifiable claim before you build, so the prototype tests a hypothesis instead of becoming an unearned verdict. Here is how good ideas die, and how to stop killing yours. ### The PM/PO Split Is Broken. Merging Them Misses the Point. Published: 2026-05-28 Canonical: https://falkster.com/blog/pm-po-split-merging-misses-the-point Huryn diagnoses the PM/PO split correctly. The split creates handoffs where you need collaboration, translator work nobody enjoys, and filtered context that breaks discovery. He prescribes merging the roles and restoring the product trio. That fix is necessary and not sufficient. The Product Owner accountability exists because Scrum's sprint cadence requires someone to translate strategy into ceremony-shaped artifacts (user stories, refined backlogs, sprint commitments). Merging the roles without killing the ceremony just gives one person two broken jobs. The real fix is a four-to-six person builder pod that runs on prototypes, evals, and an outcome ledger. The PO role has no work in that structure. ### Three Designer Archetypes in 2026. The PM Split Is the Same Shape. Published: 2026-05-28 Canonical: https://falkster.com/blog/three-designer-archetypes-pm-version Jenny Wen, head of design at Claude, hires three designer archetypes: generalist (designs and ships across disciplines), specialist (extraordinary craft in one area), and prototype-coder (works directly in code). The traditional senior product designer is missing. Nurkhon's piece nails the diagnosis. The same archetype split is happening in PM, with builder PM mapping to archetypes one and three, translator PM disappearing in the middle, and deep specialist PM surviving only in regulated domains and outcome-specialist roles. The shift is not design-specific. It is the AI-era operating model showing up in the discipline that already had the prototype-in-code pattern. ### The PM Interview Question I'd Refuse to Answer in 2026 Published: 2026-05-27 Canonical: https://falkster.com/blog/pm-interview-red-flags-2026 The PM market in 2026 has split into two distinct roles that share a title. Builder PM and translator PM. Three interview questions reliably surface translator roles: backlog prioritization, stakeholder alignment when engineering disagrees, and roadmap defense. Three questions reliably surface builder roles: last thing you shipped without engineering, your current agent stack, your eval suite. The questions are not a judgment of either role. They are a diagnostic to match yourself to the right shape. The polite exit script if you get a mismatch: finish the call, then decline in writing without theatrics. ### Ship Story: The Discovery Week I Ran With Three Agents and No Calls Published: 2026-05-27 Canonical: https://falkster.com/blog/ship-story-discovery-week-three-agents Three agents (transcript triage, theme synthesizer, opportunity ranker) ran across six weeks of Gong calls, three months of support tickets, and a sales-notes export. Four hours per day for four days. The output was a ranked opportunity list with a quote bank and four prototype briefs. Two agents got beaten by a human on the same week: low-volume high-severity signal and tie-breaks between strategically different themes. Everywhere else, the agents were faster, more consistent, and produced better artifacts than my last live-call discovery sprint. ### The 20-Minute Customer Call Triage Agent Published: 2026-05-27 Canonical: https://falkster.com/blog/twenty-minute-call-triage Stack: any transcript source (Granola, Fireflies, Gong) + Claude with the customer-call-notes skill + whatever discovery ledger you already use. Inputs: a single call transcript. Outputs: a verbatim quote bank (8-15 quotes with timestamps), a theme rollup (3-5 themes with frequency), a one-line recommended next action, and a row formatted for the discovery ledger. The agent runtime is 90 seconds. The human review is 18 minutes. Eval: quote accuracy, theme legibility, action specificity. The highest-ROI use is running it across your entire backlog of unprocessed calls in a batch, which usually takes about four hours. ### PMs Should Vibe Code Internal Tools, Not Customer Features Published: 2026-05-26 Canonical: https://falkster.com/blog/vibe-code-internal-tools-not-features Vibe coding is the most valuable new skill a product manager can pick up. Learning to build with a tool like Claude Code turns a PM from someone who writes specs into someone who builds their own tools and prototypes in an afternoon. But there is a line, and crossing it is malpractice: vibe coding is for internal tools and prototypes, not for shipping features to customers. Vibe-coded code optimizes for looking right, and a PM usually cannot tell at the code level whether it is actually right. Point it at a dashboard, a feedback clustering script, or a throwaway prototype, where the worst case is losing your own time. Do not point it at the production code path, where the worst case is a customer's data and an engineering team inheriting a liability they did not write. Same skill, completely different blast radius. Here is the line and why it matters. ### Product Management Isn't Dead. It Escaped the Product Team. Published: 2026-05-25 Canonical: https://falkster.com/blog/pm-escaped-the-product-team Product management spent twenty years confined to R&D because that was the only place building happened. Agents removed the constraint. Every function deploying AI workflows is now structurally a product team. Finance, legal, HR, sales ops, support, RevOps, procurement, all of them are designing systems where humans and agents share the work. Aaron Levie named the person doing this an "agent operator." I'd name them a Product Builder who is also an Agent Operator, because the job is shipping working systems where humans and agents share the work. Running the agents is only part of it. The collaboration model changed too. PRDs made sense when cycle times were weeks. Agents collapsed the loop to minutes, and the most productive pattern I'm seeing is a Product Builder and a developer building synchronously, no spec in between. Underneath all of it sits an unfinished layer most companies haven't thought about: the shared context substrate of persistent data and business logic that determines whether your agents are smart or stupid. The companies that compound through this transition are the ones treating context as an architectural problem rather than a per-team one. ### Six pushbacks I keep hearing on vibe coding Published: 2026-05-22 Canonical: https://falkster.com/blog/vibe-coding-pushbacks When I say vibe coding isn't a strategy, six pushbacks come back. Demos sell deals. We need speed. Real prototyping is too slow. Evals are overhead. Anyone can ship now. PMs are irrelevant. Each one has a kernel of truth and a tail of confusion. The kernel is real: AI tools changed what a small team can produce in a week. The confusion is everything else, mainly that output is the same as learning, that polish is the same as evidence, and that judgment got automated along with making. It didn't. ### Customer Discovery When Your Customer Is an Agent Published: 2026-05-20 Canonical: https://falkster.com/blog/customer-discovery-when-customer-is-agent Teresa Torres' canonical playbook (weekly interviews, Opportunity Solution Trees, assumption testing) assumes a human customer. In 2026, an increasing share of who actually uses your product is an agent, a Claude or GPT instance, an MCP-wired workflow, a custom orchestrator. The discovery discipline assumed a human on the other end, and [that user is disappearing](/blog/ai-cant-understand-the-user). Agents don't answer interviews. The replacement: six methods. Agent telemetry as primary signal. Failure-mode interviews with the humans who deployed the agent. Eval drift conversations. Synthetic user simulation. The "bossing the agent" interview. Contracts-as-discovery. Smallest first step: tag every API call by agent vs human, then run a 30-minute failure-mode interview with the human behind the agent of your three most agent-heavy customers. ### Kill the OKR. The Quarterly Cycle Is Now a Liability. Published: 2026-05-13 Canonical: https://falkster.com/blog/kill-the-okr The 12-week OKR cycle was built when build cycles were weeks and learning cycles were months. In 2026 a Product Builder ships a working prototype in four hours, customer signal arrives daily, and high-performing teams are 4-6 people. A quarterly commit is now a lagging response. Replace OKRs with a Rolling Outcome Ledger: three to seven active outcome bets at any time, each with a hypothesis, a test, a 2-4 week decision deadline, and one owner. Keep quarterly cadence only for board narrative and capital allocation that has long lead times. Strip everything else. ### Survivorship Bias in AI: Interview the Planes That Didn't Come Back Published: 2026-05-12 Canonical: https://falkster.com/blog/survivorship-bias-ai-era Survivorship bias, Abraham Wald's WWII insight that the bombers coming back with bullet holes were the *survivors* and that you should armor the parts of the plane *without* holes because that's where the fatal hits were, is the single most common error in product management. I [wrote about it in 2024](/blog/survivorship-bias-pm) with the manual playbook: exit surveys, churn interviews, post-mortems on dead features. Two years later, the bias has gotten worse in some ways (LLMs are trained on survivors; RAG retrieves survivors; every AI workflow optimizer re-fits to people who completed the workflow) and, for the first time, much more fixable in others (agents make it cheap to interview every churned user, scan for every non-event, and study every feature that flopped). The new PM job is to point a small fleet of agents at what's *missing*. The bombers that came back were interesting. In 2026, you can finally afford to ask the ones that didn't. ### Kill the Feature Request Queue: Your Backlog Is a Signal Published: 2026-05-11 Canonical: https://falkster.com/blog/kill-the-feature-request-queue The feature request queue rationed engineering capacity. With Claude Code, prototyping a hypothesis takes four hours, so the bottleneck shifted from build to judgment, and you cannot queue judgment. Three replacements: a signal synthesis layer that clusters inbound requests into patterns, a prototype-first investigation that builds a one-week prototype for every cluster that hits threshold, and an outcome bet ledger with three to seven active bets at any time and decision deadlines in weeks not quarters. The 847-item backlog is not an asset, it is debt. ### Continuous Discovery Doesn't Scale for AI-Native Products Published: 2026-05-09 Canonical: https://falkster.com/blog/punctuated-discovery-replaces-continuous Continuous discovery assumes a deterministic feedback loop: customer expresses pain → team builds feature → adoption signals validate or falsify. Agent products break that loop in three places. The agent generates behaviors users don't anticipate. Causality is fuzzy in non-deterministic systems. The customer interview captures a fraction of the product surface (the rest is agent quality, latency, drift, escalation handling). ### Kill the APM Program. Hire, Train, Promote Builders. Published: 2026-05-08 Canonical: https://falkster.com/blog/kill-the-apm-program The APM program trained for the 2018 PM role: PRD writing, stakeholder management, metrics definition, sprint planning, presentation. Agents handle most of that now. Replace the two-year rotational program with a 12-week Product Builder apprenticeship: pair the apprentice with a senior Product Builder, ship four prototypes, send one to production, learn Claude Code and an eval harness on real work. No stakeholder training. No frameworks curriculum. No rotation. The graduate has four prototypes, one production ship, and a real network, which is exactly what the role of 2026 needs from a junior hire. ### Against Product Intuition: Why I Stopped Trusting Mine Published: 2026-05-06 Canonical: https://falkster.com/blog/against-product-intuition After twenty years in product, I stopped trusting my product intuition, and it made me better. Product intuition is pattern-matching on past experience, and it only works while the world stays similar to the one that trained it. The AI era rotates the patterns faster than any human gut can recalibrate, which means the more experienced you are, the more confidently you apply rules from a world that already disappeared. The fix is not to replace intuition with dashboards. It is to demote intuition from a decision to a hypothesis, then test the hypothesis against a real customer outcome, because AI made testing cheap enough that shipping on gut is no longer defensible. Experience still matters, but its job changed. It is for asking the right question and designing the fast test, not for making the call. Here is why a senior leader argues against his own intuition. ### Kill the PRD. The Prototype Is the Spec. Published: 2026-05-01 Canonical: https://falkster.com/blog/kill-the-prd-prototype-is-spec The PRD is a 2015 solution to a 2015 problem. Three artifacts replace it. None of them are documents. A working prototype, built in Claude Code in four to six hours, real enough that a customer can use it for five minutes. An eval rubric, one page, three to five criteria scored 1-5 with at least 20 test cases. A one-page README with why, what, open questions, and links. Together they answer all five things the PRD used to contain. Done is when the rubric passes the threshold, not when the doc gets approved. ### 200 PM Job Descriptions Reviewed: 98% Hire for a Dead Job Published: 2026-04-29 Canonical: https://falkster.com/blog/dead-pm-job-descriptions The four tells of a dead PM JD: translation-layer language, PRD-centric responsibilities, stakeholder-management framed as a job function, and a conspicuous absence of tools the role touches daily. The four tells of a live one: a 90-day prototype expectation, named tools (Claude Code, Cursor, an eval harness, a deployment stack), owned metrics rather than influenced ones, and an explicit disclaimer that PRDs are not the output. Most JDs miss all four. The fix is mechanical: rewrite the opening to lead with what the PM ships in the first quarter, not what they coordinate. ### pragmatic-pm-ai-skills Review: A Claude Skill That Tightens PM Output Published: 2026-04-20 Canonical: https://falkster.com/blog/pragmatic-pm-ai-skills [pragmatic-pm-ai-skills](https://github.com/vltnbrain/pragmatic-pm-ai-skills) is a small Claude Skill library by [Valentin Brain](https://www.linkedin.com/in/valentinbrain/) that installs into Claude Code or Cursor and enforces four behavior rules on every AI output: audit incentives first, prefer one-page artifacts, tie every claim to proof, and treat every deliverable as a testable hypothesis. Plus a "bullshit detector" that flags generic advice and demands a concrete alternative. It scores 5 out of 5 against the falkster PM Operating System POV. The only gap: it's a constraint layer, not an agent fleet. Install it alongside [your agent fleet](/handbook/ai-agent-army), not instead of it. ### How PMs Ship Their First Pull Request With AI Tools Published: 2026-04-19 Canonical: https://falkster.com/blog/pm-first-pull-request PMs are starting to ship their own pull requests. Not as engineers. As PMs taking back the surfaces they always had the most context on (copy, configuration, AI prompts, telemetry, small front-end changes), because AI finally made it possible to act on that context without a translation layer. The four-level PR ladder: copy and configuration first, then AI prompts on features you own, then small front-end changes, then telemetry and instrumentation. PLANNING.md files live in git next to the code. CLAUDE.md is your standing brief to the agent. Engineering throughput goes up, not down, because engineers reclaim deep-work hours on architecture. Tobi Lutke mandated this at Shopify in April 2025. If your engineering leader pushes back, show them the volume shift. ### Your Product KPIs Are Your Job, Daily Published: 2026-04-19 Canonical: https://falkster.com/blog/product-kpis-builders-daily Pick three product KPIs: one acquisition, one value-delivery, one retention or expansion. Some products need a fourth: cost or margin. Watch them every morning for five minutes. For each KPI, write down the healthy band, the investigation threshold, the escalation threshold, and the OKR threshold (sustained miss elevates it from a daily KPI to a quarterly OKR). Most PMs can't name three numbers that, if they moved tomorrow, would change what they ship next week. The product builder can. The instrumentation isn't the hard part anymore. Choice is. Pick three KPIs this week, automate the dashboard with Claude Code next week, install the ritual permanently. ### Mob Prototyping: One Day, One Room, One Prototype Published: 2026-04-18 Canonical: https://falkster.com/blog/mob-prototyping Mob programming is a bad idea for production code. Three engineers staring at the same function gives you one engineer's output for three salaries. But for prototyping, it's the opposite. One day a week, your trio (PM, designer, engineer) sits together with one screen, AI coding tools like Claude or Cursor, and builds a working prototype in eight hours. The math works because prototyping is primarily a decision-making activity, not a production activity. The week's structure: 30 minutes framing, 2.5 hours building, lunch, 2 hours iterate-and-polish, 1 hour test prep, 1 hour document and park. By Friday, you're showing the prototype to three customers. I've been doing this at Smartcat for six months. It's the single biggest improvement to how my team works. ### Build a PM Second Brain from Meeting Recordings Published: 2026-04-16 Canonical: https://falkster.com/blog/pm-second-brain PMs forget 50% of what was discussed in a meeting within 24 hours, 90% within a week. Spending 15-25 hours/week in meetings means losing the irreplaceable context that makes product decisions explainable. The fix is a four-step pipeline: record (Otter, Fireflies, Grain) every meeting; transcribe (Whisper); embed into a vector database (ChromaDB, Qdrant, Weaviate) so search works on meaning, not keywords; query in natural language ("What did the enterprise customer in the March pilot say about onboarding?"). Five meetings is a curiosity. Five hundred is institutional intelligence. PMs running this system don't show up trying to remember. They show up having queried their second brain. The longer you run it, the wider the gap. ### The PM Automation Stack: OpenClaw vs Claude vs Everything Else Published: 2026-03-26 Canonical: https://falkster.com/blog/openclaw-vs-claude-pm-automation OpenClaw, Claude Code, and n8n are the three real options for PM automation. OpenClaw is open-source and lives in your messaging apps, but it shipped with a CVE-2026-25253 (CVSS 8.8) token-theft vulnerability and a "ClawHavoc" supply chain attack that delivered Atomic macOS Stealer through 824 of 10,700 ClawHub plugins. Claude Code is cloud-managed, sandboxed, knows your real codebase, and ships through MCP connections to Linear, Jira, Notion, Slack, PostHog. n8n with MCP is the boring right answer for most teams: visual workflows, audit logs, safe automation, no daemon on your laptop. Start with Claude Code, add n8n for scheduled automation, only run OpenClaw in Docker on a non-production machine after auditing every plugin. The tool matters less than the commitment to stop translating and start building. ### How a 2-Hour Prototype Killed a 3-Month Project Published: 2026-03-24 Canonical: https://falkster.com/blog/playbook-prototype-decision 48 hours before a full-squad kickoff for a feature with six months of customer requests, exec sponsorship, and a complete design, I asked for 3 days to validate the workflow. Two hours of Claude Code generated a rough clickable prototype. Five customer calls revealed that our elegant linear workflow was structurally wrong: customers wanted exploration before commitment, collaboration during the process, configuration persistence, and batch application across time, not all at once. Friday I walked into the kickoff with the data and said "these aren't edge cases, these are the actual cases." We took a week to redesign, shipped in May instead of April, and hit DAU targets in week one. The 2 hours of prototype and five calls saved 600 engineering hours building the wrong feature. ### From Zero to Weekly Discovery in 30 Days Published: 2026-03-22 Canonical: https://falkster.com/blog/playbook-weekly-discovery We went from quarterly customer research to every PM running weekly discovery calls in 30 days. Not by mandate from leadership. By system that proved its value in real time. Week 1: I started alone, posting small insights in Slack from six 20-minute calls. Week 2: two PMs asked to join, I created a simple Google Doc template with five fields. Week 3: a roadmap was redirected mid-design because four PMs heard the same customer-driven insight. Week 4: all seven PMs were doing weekly discovery as habit. Culture change doesn't come from mandates. It comes from visible results. Eighteen months later, weekly discovery is so embedded that onboarding includes "here's how you schedule yours." ### What Happened When We Killed Our Most-Requested Feature Published: 2026-03-21 Canonical: https://falkster.com/blog/playbook-killed-feature We funded "Advanced Scheduling" for a full quarter based on 247 Salesforce requests. We shipped it in February. Three months in, fewer than 50 of 4,000 customers were using it. Twenty customer calls revealed the truth: customers couldn't articulate a specific use case. They'd seen the feature in competitor demos and asked for it by name. What they actually needed was existing features they couldn't find. We renamed "Template Operations" to "Batch Scheduling," moved it to the Operations section, and added contextual prompts. Adoption jumped to 600 customers in six weeks. Platform-wide activation lifted 15%. Then we deleted the Advanced Scheduling code entirely. The lesson: requests are not requirements. Behavior is. ### The PRD Is Dead. Here's What Replaces It. Published: 2026-03-18 Canonical: https://falkster.com/blog/death-of-the-prd I wrote my last PRD six months ago. Twelve pages, three days of work, two engineers read it. PRDs made sense when building took three months and cost a ton. Building isn't expensive anymore. A PM with AI can prototype in an hour, as I describe in [Instant Prototyping](/handbook/instant-prototyping). The cost of being wrong dropped from three months of engineering to one afternoon. What replaces the PRD: a working prototype, a one-page strategic context document, a 5-minute Loom recording, and a 30-minute conversation with engineering. Complex features need more prototyping, not more documentation. If it's too complex to prototype, it's too complex to build. Build it. ### 20 AI Prompts That Replace 20 Hours of PM Work Published: 2026-03-13 Canonical: https://falkster.com/blog/ai-prompts-for-pms Twenty AI prompts for product managers, organized into five categories: customer research, prioritization, strategy, writing, and prototyping. Each prompt includes the exact text to paste into [Claude](https://claude.ai) or [ChatGPT](https://chat.openai.com), what it does, and a pro tip for better output. The full library is also available as a [downloadable markdown file](/artifacts/pm-ai-prompts.md) you can drop into your prompt manager or save in a Notion page. The prompts that save the most hours per week, in my testing: the JTBD extractor (Prompt 1), the ticket-theme clusterer (Prompt 2), and the one-pager-from-notes generator (Prompt 14). For a deeper version of this idea (replacing whole PM workflows with always-on agents instead of one-off prompts), see [Your AI Agent Fleet](/handbook/ai-agent-army) and [The Impact Loop](/handbook/impact-loop). ### Prompt Logs Are the New Switch Interview Published: 2026-03-10 Canonical: https://falkster.com/blog/prompt-logs-new-switch-interview The switch interview is one of the best tools in discovery, and AI just gave us something better for half of what we used it for. When customers use an AI feature, they type what they want in plain language, at the exact moment they want it, across your entire user base. That is a switch interview with no recruiting, no scheduling, no recall bias, and a sample size of everyone. Prompt logs are the richest unmet-needs dataset most product teams already own and are not reading. They will not tell you why a customer feels something, so interviews are not dead. But for what customers are trying to do and where your product fails them, the logs beat the call. Stop booking eight interviews to guess at demand you can already see verbatim. ### The AI-Powered Weekly Review: A System for PMs Who Ship Published: 2026-03-04 Canonical: https://falkster.com/blog/weekly-review-system The PM weekly review takes 30 minutes instead of 3 hours when you let AI agents pull the data, surface insights, and prepare a brief. Three phases: gather (10 minutes, mostly automated, pull from GitHub, Jira, analytics, Zendesk, Salesforce), triage (10 minutes, five decision questions about what changes your week), communicate (10 minutes, generate the standup opener for your team). Run a 4-week trend prompt at the end of each month to catch slow-moving problems that look fine in isolation. The system works because it's regular, surfaces surprises, creates 30-minute constraints, gets better through repetition, and frees you for what only PMs can do: customer conversations, strategic thinking, unblocking teams. Start with manual data collection. Automate when it works. ### How to Build a Working Prototype in 60 Minutes (Step-by-Step) Published: 2026-02-27 Canonical: https://falkster.com/blog/prototype-in-60-minutes The exact 60-minute workflow: 5 minutes framing the problem (write problem statement, list steps, identify constraints, decide scope), 10 minutes describing to Claude Code and getting the first working version deployed to Vercel, 15 minutes iterating UX with specific prompts ("the data mapping step is confusing, add inline help text"), 15 minutes adding real data and edge cases, 15 minutes deploying and sharing. The exact prompts to paste are in the post. You're not building a product in 60 minutes. You're learning what product to build. A prototype with rough edges that teaches you something is infinitely more valuable than a beautiful mockup that's never tested. Pick one feature idea this afternoon and run the workflow. ### Jobs to Be Done Has a Half-Life Now (And AI Is Shrinking It) Published: 2026-02-18 Canonical: https://falkster.com/blog/the-job-has-a-half-life Jobs to Be Done has one load-bearing assumption: the underlying job is stable even when the products that serve it change. That assumption was true for most of software history, and it is the reason JTBD worked. AI breaks it. AI does not just out-compete your product at the job, it absorbs the job, so the thing your customer hired you for can stop existing inside a single release cycle. The job now has a half-life, and the half-life is shrinking from years to weeks. JTBD is still the right lens for a moment in time, but you can no longer interview your way to a job map and reuse it for two years. The job is a depreciating asset. Measure its decay continuously or you will keep optimizing a need your customer no longer has. ### The One-Pager That Replaced Our PRDs (Template Included) Published: 2026-02-13 Canonical: https://falkster.com/blog/one-pager-template We stopped writing PRDs three years ago. Replaced them with a one-page template covering six sections: problem statement, evidence (quotes plus data), proposed solution with prototype link, success metrics, risks and mitigations, ask (what's blocking you). It made execution 40% faster and improved communication because everyone reads one page instead of skimming the first three of a 30-page doc. The one-pager works because the page constraint forces clarity, everyone reads it, it stays relevant even mid-project, and it's a conversation starter, not a command. A working AI prompt to draft the first version in minutes is included. Use it on your next feature. PRDs are fossils by day five. ### Run a 15-Minute Sprint Retro That Actually Improves Things Published: 2026-02-05 Canonical: https://falkster.com/blog/sprint-retro-ai Most sprint retros spend 80% of time gathering data and 20% solving problems. Flip the ratio. Every Friday at 4 PM, an automated process generates a Sprint Health Report from GitHub commits, Jira tickets, Slack messages, PagerDuty incidents, and PR data, all synthesized by Claude. Monday's retro is 15 minutes: 2 minutes reviewing the report together, 5 minutes on the #1 pattern, 5 on secondary patterns, 3 to celebrate and commit to one action item with named owner and deadline. The pattern: [Owner] will [specific action] by [when]. Retros become decision-making meetings, not data-gathering meetings. Three setup options included: manual+Claude, Make/Zapier automation, or Python script with cron. ### Is Mob Programming the Right Approach for Your Team? Published: 2024-11-22 Canonical: https://falkster.com/blog/medium-mob-programming Mob programming (three+ developers working on one task with driver-navigator) sounds collaborative, but the productivity math is brutal: three engineers who could ship 72 units of output often produce 8 because of coordination overhead, consensus waiting, and the slowest-person pacing. Quality is also a myth: groupthink replaces real peer review and bug-catching diffuses. Worst, engineers become task takers without ownership. The gold standard is fully empowered Scrum teams: better decisions because of accountability, faster movement without consensus, real innovation, and retention. Mob programming works in three legitimate cases: high-stakes critical systems, cross-functional ideation, and onboarding. Use it strategically, not as a default. ### How to Avoid Survivorship Bias in Product Management Published: 2024-09-11 Canonical: https://falkster.com/blog/medium-survivorship-bias Abraham Wald's WWII bomber study taught us survivorship bias: the planes that returned with bullet holes in the wings and tail showed where damage was survivable. The real vulnerability was in the areas (engine, cockpit, hydraulics) where damaged planes never came home. PMs make this mistake everywhere: customer feedback from active users only, feature usage as a "survivors' metric," A/B tests measuring people who stuck around, competitor analysis seeing only the bets that worked. Fix it by gathering data from churned users, documenting failed experiments, layering complementary metrics (churn by feature, friction points, long-term retention), testing multiple hypotheses simultaneously, and measuring what's missing. The data you see is often the least important data. ### You're Only Listening to the Survivors Published: 2024-09-11 Canonical: https://falkster.com/blog/survivorship-bias-pm Survivorship bias is one of the most common mistakes in product management. Abraham Wald's WWII insight: don't armor the planes that came back; armor the parts of the planes that never returned. In PM work: you're only hearing from users who stuck around (your most engaged ones), looking at features that survived the gauntlet of your current UX, copying competitors who won (not the ones who failed identically), and celebrating A/B test wins without analyzing the losing variants. The countermeasures: talk to churned users (exit surveys, churn interviews), look at what's not happening (drop-off, non-events), run feature post-mortems on what flopped, include churn drivers in prioritization, frame your roadmap around outcomes. The bombers that came back were interesting. The ones that didn't had the answers. ### Why Users Don't Know What They Want Until You Show Them Published: 2024-09-01 Canonical: https://falkster.com/blog/medium-visionary-product-development Feature requests are reactive. Users know their problems but not the solution space, so they describe today's problem with today's mental model. As Steve Jobs put it: "people don't know what they want until you show them." The shift from feature-request-driven to visionary product development starts with better questions: "What are you trying to accomplish?" not "What feature do you want?" Treat user feedback as input, not direction. The power tool here is prototyping: a working prototype turns abstract vision into something tangible, and users react to what they see, not what they imagined. At SOCi, showing customers Applied AI and Genius Studio produced visceral reactions ("This changes how we think about our workflow") that incremental feedback never would have surfaced. ### Show, Don't Tell: Why Users Can't Describe What They Need Published: 2024-09-01 Canonical: https://falkster.com/blog/show-dont-tell Steve Jobs said "people don't know what they want until you show it to them." Users are great at telling you where it hurts (the problem) but bad at prescribing the medicine (the solution). [Why users do not know what they want until you show them](/blog/medium-visionary-product-development) is the longer argument, including the year I spent shipping a roadmap made entirely of requests. Feature requests pile up and look like a roadmap. They're not. They're symptoms. I spent a year at one company where the entire roadmap was driven by sales-funneled customer requests. We shipped 40+ features and churn didn't move. What works: dig into the "why" behind every request, prototype before you plan (AI tools make this hours not weeks), use feedback as input, not direction. Listen to everything. Build what matters.