# The Falkster Corpus: Product Leadership CPO-level decisions on org design, hiring, eval infrastructure, and operating cadence when the cost of building collapses. The claim: The product org chart was calibrated to a build cost that collapsed. Leadership work now is deciding which coordination roles stop being necessary, and saying so out loud. Source: https://falkster.com/corpus · Built 2026-09-19 · Author: Falk Gottlob Contents: 74 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 (74 pieces) Each entry is the piece's own extractable summary. Follow the link for the argument. ### SpaceX Just Bought Cursor for $60B. What It Actually Bought. Published: 2026-08-18 Canonical: https://falkster.com/blog/cursor-spacex-60-billion Cursor is the fastest company ever to $100M ARR (January 2025), past $1 billion annualized by November, more than half the Fortune 500 as customers, built by four MIT founders who barely issued a press release. The growth was product, not marketing and not a model edge. Michael Truell and his cofounders made a handful of operating choices that compound: fork the editor so you own the surface, obsess over the latency of the edit loop until the product sells itself, grow bottoms-up from individual developers into the enterprise, and ship faster than the frontier models can commoditize you. The one thing that could break it was always the model supply, Cursor ran on Anthropic's Claude, and a supplier can become a competitor. That is the exact weakness the SpaceX and xAI deal fixes. The lesson is not "build an AI coding tool." It is that a great product beats a sales motion, and that your foundation-model dependency is a strategic risk you price in before someone prices it for you. ### The Harvey Playbook: How AI Cracked Big Law Published: 2026-08-18 Canonical: https://falkster.com/blog/the-harvey-playbook Harvey went from a 2022 experiment by two roommates to $100M ARR in three years, roughly $350M by July 2026, and an $11 billion valuation, selling into elite law firms that are famous for saying no. Winston Weinberg, a former litigator, and Gabriel Pereyra, an ex-DeepMind researcher, made a set of choices that are almost the inverse of a horizontal tool. Go narrow and deep into one vertical where a founder has real credibility. Land a flagship firm, Allen & Overy, and turn it from a logo into co-development and revenue share. Sell to the partners and the firm's economics, not the IT department. Price per seat and let land-and-expand do the compounding, median seats double inside a year. And in a domain where a wrong answer is malpractice, make trust the product, not capability. The model underneath is increasingly commoditized. The moat is the vertical, the workflows, and the distribution into Big Law, and none of that is something a frontier lab can ship in a weekend. ### Every Artifact Is Somebody's Promotion Packet Published: 2026-08-12 Canonical: https://falkster.com/blog/every-artifact-is-a-promotion-packet The PM career ladder runs on artifacts, but not for the reason people assume. Documents are how promotions get justified. When you get leveled, someone in a calibration room points at the PRD you authored or the strategy you wrote and argues it demonstrates the scope of your next level. The artifact is the currency of advancement. That is why AI collapsing the document is not a productivity story, it is a career-structure story. When a spec that used to take three weeks takes an afternoon, its existence stops being proof of work, because everyone can now see it was never the work. The people most exposed are managers whose leverage was grading artifacts and senior ICs whose reputation was being the best writer in the org. The fix is to rebuild leveling around outcomes and judgment, which is harder to see and harder to game, which is why most orgs will avoid it and keep promoting the best document producers into a role where documents no longer exist. ### The Landing Ledger: What It Costs to Build vs What It Costs to Land Published: 2026-08-12 Canonical: https://falkster.com/blog/the-landing-ledger Building costs collapsed and landing costs did not, so the ratio between them flipped, and most orgs still budget as if building were the expensive part. Build cost lives inside your org as engineer-weeks and compute, is highly visible, and is falling fast because building is a technical problem and AI is good at those. Land cost lives mostly on the customer's side of the glass as switching effort, sustained GTM attention, and change management, is nearly invisible until it fails, and is flat because landing is a human problem and no model changes how long it takes a person to trust a tool and rewire a habit. The failure signature of the mismatch is month-two silence: the thing works, the customer signed up, and then usage decays because nobody funded the work of turning availability into habit. The ledger below prices both columns. The instruction is simple. Stop budgeting the cost that fell and start budgeting the one that now dominates. ### The Launch That Worked and Did Not Land Published: 2026-08-12 Canonical: https://falkster.com/blog/the-launch-that-worked-and-didnt-land We launched a feature and hit every number we were watching: coverage, signups, week-one activation, all green. We celebrated, the launch team moved to the next thing, and two months later the usage curve was flat. The launch worked. The landing never happened, and it fell through in three specific places: no owner past general availability, onboarding that stopped at a single activation event, and a product that delivered value once and never gave anyone a reason to come back. Every one of those gaps was invisible on launch day, because the launch dashboard was built to light up at release and had no way to show the month-two silence. The launch measured the two things I could make happen and stayed quiet on the one thing I couldn't. I had confused the launch for the finish line, and my own dashboard let me, not by lying about anything it showed, but by leaving out the only part that mattered. ### The Person Whose Job This Shift Threatened Published: 2026-08-12 Canonical: https://falkster.com/blog/the-person-whose-job-this-threatened The best document writer on my team was threatened by the Product Builder shift, not because she was bad but because she was excellent at the one thing AI made cheap. Her craft was the clearest spec and the most thorough strategy doc in the org, and that craft was the currency her reputation and her sense of her own value were built on. When a model started producing clean documents for free, the thing she was best at stopped being scarce. I handled it badly the first time by softening the message to protect the relationship, which really protected my comfort and stole two quarters of her runway. When I finally said it straight, her first question was why I had not told her sooner, and I did not have a good answer. The lesson is not about tooling. It is that the transition is a people problem, the people are owed the truth early, and kindness that delays the truth is just comfort for the manager, paid for by the person. ### 31,832 PMs Applied. Whatnot Hired One. The Premise Is the Point. Published: 2026-08-12 Canonical: https://falkster.com/blog/whatnot-regrets-product-management Whatnot's product org was founded on the premise "we regret that product management exists," and the numbers make it an operating model rather than a hot take: roughly 22 senior PMs across the fastest-growing US marketplace, one hire from 31,832 applicants, PM managers spending 90%+ of their time on IC work, and PMs assigned to problems each six-month cycle rather than to pods. Verrilli's target is not product management as a craft, it is the pod-ratio default that hired a PM per six engineers, infantilized engineers and designers, and produced a generation whose specialty was politics. His sharpest structural claim is the one I have argued from the theory side: the title is getting scarcer while the trade gets more durable, and AI removed the places to hide. His "verify then trust" leadership, micromanagement redefined as managing without ground truth, is the missing answer to the calibration problem I wrote about in the ladder posts. And his claim that AI's biggest PM unlock at Whatnot was data science, not prototyping, corrected me: I have been preaching build-speed while his binding constraint was learn-speed. The caveats are real, extreme talent density is the enabling input and most companies cannot buy it, but the premise, the problem-mapping, and the verification discipline transfer to anyone. ### Who Owns Landing? Right Now, Nobody Published: 2026-08-12 Canonical: https://falkster.com/blog/who-owns-landing Landing falls into the seam between four functions, each of which hands off before the customer's behavior actually changes. Product owns shipping and lets go at GA. Marketing owns the launch and moves to the next one. Sales owns the close and moves to the next quota. Success owns the renewal, which is three quarters away. The ninety days that decide whether a launch mattered belong to no one, because the org chart was drawn when building was the constraint and every function was optimized around the moment of release. A Head of Landing with no authority is the weakest fix. The strong fixes are structural: give landing to whoever owns the outcome and remove the handoff, or change the pricing so revenue only arrives when the customer uses the product, which makes landing everyone's job by making it the only way anyone gets paid. The first move is small and clarifying: name one person accountable for the durable-adoption number of your last launch, and forbid the handoff. If you cannot name them, you have found your answer. ### The PM Does Not Make Decisions. Make Sure They Get Made. Published: 2026-07-24 Canonical: https://falkster.com/blog/pm-does-not-make-decisions The PM's job was never to make decisions, it was to make sure decisions get made, by the right owner, on real evidence, before the window closes. That was always true, and building being slow used to hide the cost of getting it wrong. In the AI era building collapses to a day, so every slow decision is now the critical path, and a PM who insists on personally making every call becomes the thing throttling the loop. The job in this era is to be the decision architect: design who decides, on what evidence, by when. Deciders get pushed to the lowest accountable level. Evidence comes from evals, so the team can decide without you in the room. Every decision gets a clock, because an unmade decision just lets agent output rot in review. This is not the same as letting the AI decide. That is abdication. The job is the narrow middle: make sure the right human decides, well, on time. ### Judgment Reps: How PMs Train Decision Quality Deliberately Published: 2026-07-13 Canonical: https://falkster.com/blog/judgment-reps Decision quality and outcome quality are different things, and conflating them (what Annie Duke calls resulting) is why orgs learn the wrong lessons from their own history. The training loop has four parts: a decision log with eight fields as the scorecard, written confidence percentages scored quarterly as the calibration habit, the premortem as the repeatable drill, and reversibility (one-way versus two-way doors) as the dial for how much process a decision deserves. This is the deep dive on decision quality from [The Skill Stack](/handbook/skill-stack), and the instrument is [the decision log template](/blog/decision-log-template). Speed of deciding is set by [the cost of being wrong](/blog/cost-of-being-wrong), not by temperament. ### Stop Calling Yourself an AI PM Published: 2026-07-12 Canonical: https://falkster.com/blog/stop-calling-yourself-an-ai-pm Stop calling yourself an AI PM. Product management is fragmenting into specialist labels, AI-native, growth, monetization, platform, GTM, and while some of that is healthy specialization, a lot of it is a company hedging on a decision it has not made: whether product management as a coordination function still deserves its current headcount. AI-native is the clearest tell. It promises nothing beyond a PM who has used AI tools, which by 2026 should be everyone, and it covers for the unanswered question of what the PM actually owns now that AI has eaten research synthesis, first-draft specs, and analysis. The specialization that holds up is built around a different kind of judgment, not a different tool stack: a growth PM and a platform PM optimize different outcomes. Name the outcome you own, not the tool you use to get there. ### The QBR Deck Template That Forces Decisions, Not Applause Published: 2026-07-10 Canonical: https://falkster.com/blog/qbr-deck-template Nine slides, 30 minutes, deck sent 48 hours early as a standalone pre-read. Slides 1 through 6 make the quarter legible: scoreboard versus plan with the same five numbers every quarter, what we said versus what happened with misses unspun, a decision review that scores calls separately from outcomes (Annie Duke's framing), what we killed, customer signal themes with verbatim quotes, and the margin trend. Slides 7 through 9 make the next quarter decidable: a bets table with confidence and reversibility, the anti-bets you are explicitly not doing, and the asks. The meeting spends most of its time on 7 through 9. The argument behind the format is in [the quarterly business review](/blog/quarterly-business-review); the weekly numbers that feed it come from [the stakeholder update autopilot](/blog/stakeholder-update-autopilot). ### The Resume Is Dead. Here Is What Replaced It. Published: 2026-07-08 Canonical: https://falkster.com/blog/the-resume-is-dead-heres-what-replaced-it The resume is dead as a hiring filter. The signal it used to carry, a well-structured document with a clean impact narrative, is now trivially producible by anyone with an AI model and twenty minutes, so it no longer correlates with the ability to think and communicate clearly under your own effort. What still correlates: published writing with a defended point of view, recorded talks where you thought in real time, teardowns where the seams of your reasoning show, and decision frameworks you actually used. None of these compress well with a model, because the value is the visible trail of a specific person's judgment. If you hire, redesign the funnel around this: a structured work sample beats a portfolio of titles, a live teardown beats a take-home. If you are the candidate, the fix is not a better resume, it is starting to publish now. ### GTM Is Not Someone Else's Job Anymore Published: 2026-07-06 Canonical: https://falkster.com/blog/gtm-is-not-someone-elses-job GTM is not someone else's job anymore. The convergence between product management and product marketing is accelerating, and the direction is one way: PMs are picking up market research, pricing experiments, creative briefs, and ownership of the activation funnel, not the reverse. This tracks with the role collapsing into building, because activation and pricing are not adjacent to product building, they are the parts of building that decide whether the thing you built gets used. AI collapses the gap the same way it collapsed the PM-to-engineer handoff: prototype the product, prototype the activation flow, run the pricing experiment, write the positioning brief. This does not mean PMs replace product marketers. It means the job that stops at requirements and roadmap is describing half a job in a market that pays for the whole one. ### The First 90 Days as an AI-Native CPO Published: 2026-07-02 Canonical: https://falkster.com/blog/first-90-days-ai-native-cpo The classic CPO first-90-days plan centered on people and roadmap because execution was the constraint. Execution is no longer the constraint; judgment, cost, and quality are. So the plan changes. Days 1 to 30: audit reality, not the deck (use the product on real tasks, sit in raw customer calls, map what agents build versus people, find out if anyone reads evals). Days 30 to 60: instrument what matters (cost per outcome by workflow, eval scores with trend lines, an operating cadence that forces decisions). Days 60 to 90: kill the ceremonies that survive on inertia and defend the few things that are actually yours (problem selection, the quality bar, the expensive-to-reverse calls), and decide what to do about the segment a lean competitor would attack. The throughline: stop optimizing execution, which is cheap, and start owning judgment, cost, and quality, which is the job. ### The CEO Who Can't Read Their Own Product Anymore Published: 2026-06-30 Canonical: https://falkster.com/blog/ceo-cant-read-the-product Dashboards were a faithful proxy for the product when humans built it at human speed: usage, retention, and revenue moved slowly and legibly, so reading the numbers was a reasonable way to know the state of the thing. Agents broke that link. When the product is partly produced and operated by agents, the gap between what the metrics say and what customers experience can open fast, because an agent can be confidently wrong in ways that pass aggregate checks for weeks. The dashboard stays green while the experience degrades. The fix is not more dashboards but three habits: watch the agents work and not just their outputs, read evals and not just KPIs, and use your own product weekly on a real task. CEOs who stay close to the experience keep their judgment; those managing by dashboard alone are about to be surprised by their own product. ### Product Ops Is the Job AI Made Necessary Published: 2026-06-27 Canonical: https://falkster.com/blog/product-ops-ai-made-necessary Product ops is the job AI made necessary, not the job AI replaced. As the PM role splits into specialists, growth, platform, monetization, GTM, and as fixed roadmaps give way to small squads prototyping continuously, the single roadmap owned by a single PM per area stops existing. That coordination has to go somewhere, and it is going to product ops, which is quietly becoming the highest-leverage seat in the building rather than the administrative one it used to be. The job is closer to infrastructure than administration: keeping specialist PMs on the same data, the same definition of a good outcome, and the same view of what AI features cost to run and govern. Hire for it as a systems thinker with technical fluency and organizational range, closer to a chief of staff for product than an entry-level support role. ### I Ran My Staff Meeting Off a Live Dashboard for a Quarter Published: 2026-06-25 Canonical: https://falkster.com/blog/staff-meeting-live-dashboard I banned status updates from my weekly product staff meeting for a quarter and replaced them with a live dashboard that a small set of agents refreshed before each meeting: what shipped, what moved, eval scores and trends, cost per outcome by workflow, and a flagged list of anything off track. Everyone read it beforehand, so the meeting opened at the decisions. It killed thirty minutes of narration nobody acted on, and it surfaced uncomfortable numbers that used to hide inside confident verbal summaries, including a drifting eval score and two underwater costs no one had examined. The mistake was letting the dashboard get too dense until people stopped reading it; the fix was cutting it to the eight numbers that change decisions. Net, the best operating change I made that year. ### CPO Days 61 to 90: The Kill List, the Bets, and the Readout Published: 2026-06-24 Canonical: https://falkster.com/blog/cpo-days-61-90-first-bets CPO days 61 to 90, the closing month of [The CPO 30/60/90](/handbook/cpo-30-60-90), has three deliverables. The kill list, built by running the inertia test over everything the audits flagged: does this change a decision? Two public kills, each with a written kill memo. And two or three first bets, reversibility-weighted and evidence-linked, with an explicit anti-bet paragraph. All of it lands in the day-90 readout, an SCQA memo in the Barbara Minto tradition, written to be read rather than presented, delivered first to the exec team and then in a tightened version to the board. The instruments that make every claim in the readout checkable were built in [days 31 to 60](/blog/cpo-days-31-60-instrument-the-org). ### The Founder Mode Misread Published: 2026-06-23 Canonical: https://falkster.com/blog/founder-mode-misread Founder mode started as a correction to over-delegation: founders who professionalized so hard they lost touch with their own product. The real idea was to stay close to the things only a founder can do. It got misread as permission to micromanage and be in every decision, which is just a bottleneck with a good story. The AI-native version cuts the other way from how most founders apply it. When execution was expensive and human, "stay involved" meant staying in execution. Now execution is cheap and automatable, so it is the least valuable place for founder attention and the first thing to hand off. What remains founder-only is narrow: problem selection, defining what good looks like, the few expensive-to-reverse decisions, and taste. Founder mode means being irreplaceable in those and getting out of everything else faster than ever. ### The Board Deck Product Section: An SCQA Slide Kit Published: 2026-06-19 Canonical: https://falkster.com/blog/board-product-slide-kit Seven slides, ten minutes, SCQA underneath. Slide 1 is the scoreboard: the same five numbers every quarter, direction metric, eval trend, margin, adoption, retention-relevant signal. Slide 2 is what changed, including the bad news. Slide 3 is the bets table with status, confidence, and a call-it date per bet. Slide 4 is the kill list with redeployment math. Slide 5 is the one risk that matters, premortem result attached. Slide 6 is the asks, framed as decisions with dates. Slide 7 is a footnoted appendix that carries the depth. The pillar this serves is [Investor and Board Narrative](/handbook/investor-and-board-narrative); the prose engine behind it is [the strategy memo template](/blog/strategy-memo-template), and a new CPO's first version of this section grows out of [the day-90 readout](/blog/cpo-first-90-kit). ### The AI Product Operating Model Has a Survivorship Problem Published: 2026-06-18 Canonical: https://falkster.com/blog/ai-product-operating-model-survivorship This week Aakash Gupta and Rohan Varma published "The AI Product Operating Model," and the core argument is correct: the traditional product org rests on the belief that engineers are your scarcest resource, that belief is dead, and when building gets cheap the build-then-decide sequence inverts. The diagnosis is sound. The evidence is the weak part. Every case study, Cursor, Codex, Anthropic, Medvi, OpenClaw, is a company that won, and survivorship bias is the one bias built to make a true claim look far more proven than it is. The inversion is real and the case studies are the right tail, not the mean outcome. Three things the survivor stories hide: greenfield is the easy version, regulated domains punish the inversion, and the operating model was never the hard part. The hard part is the taste to know where it applies. So read the piece, then ask who tried this and is not here to tell you how it went, and design for that company too. ### The Cost of Being Wrong Is the Only Number That Matters Now Published: 2026-06-18 Canonical: https://falkster.com/blog/cost-of-being-wrong When building was slow, speed was the binding constraint and a wrong decision cost you the quarters it took to ship it. Now that building is fast and cheap, you can ship in a week, which means you can also be wrong in a week, at scale, in front of customers, especially when an autonomous agent executes the wrong call thousands of times before anyone notices. The constraint moved from "how fast can we go" to "how expensive is it when we are wrong, and how fast can we undo it." The CPO move is to stop triaging decisions by size and start triaging by reversibility: ship cheap-to-reverse decisions immediately and learn, and reserve real scrutiny for the expensive-to-reverse ones. Speed is now free. Judgment about reversibility is the scarce skill. ### Five Questions That Make a Product Review Worth Your Time Published: 2026-06-16 Canonical: https://falkster.com/blog/product-review-five-questions Most executive product reviews are status theater: a deck of green bars that confirms work is happening but forces no decision. That was tolerable when building was slow; now that building is cheap and fast, "are we on track" is the least valuable question in the room. Five questions convert the review into a decision-forcing session: what did we learn and change, what outcome moved (not what shipped), what does this cost to run, what is the eval score and its trend, and what are we willing to be wrong about. Ask these and the meeting stops measuring progress and starts surfacing judgment, cost, and risk. To make room, cut the roadmap walkthrough and anything that does not change a decision. ### CPO Days 31 to 60: Instrument the Org Before You Steer It Published: 2026-06-15 Canonical: https://falkster.com/blog/cpo-days-31-60-instrument-the-org CPO days 31 to 60 convert the four audits from [The CPO 30/60/90](/handbook/cpo-30-60-90) into three permanent instruments: cost per outcome by workflow, eval scores with trend lines, and one direction metric. Then three moves turn the instruments into authority: a written coalition map, one visible evidence-backed decision, and a scoreboard renegotiation with the CEO around day 50. The discipline is subtraction. Three instruments leadership reads weekly beat thirty nobody opens. The contradictions you logged in [the listening ledger](/blog/cpo-listening-tour-ledger) are the first things the instruments should settle. ### Your Next Competitor Has Eight People and Your Whole Roadmap Published: 2026-06-11 Canonical: https://falkster.com/blog/your-competitor-has-eight-people The most dangerous competitor in your category is no longer the funded incumbent. It is the small, agent-native team: eight people who fit in one conversation, carry no legacy product to protect, and produce what eighty people used to thanks to the agent stack. They have no coordination tax, no architecture they cannot rewrite, no customers they cannot break, and a cost base low enough to survive on revenue that would not cover your floor. The instinct to dismiss them as too small is the same instinct every incumbent had before losing a segment. The CEO move is not panic but a specific exercise: ask what eight people starting today with no legacy would build to attack you, and why you cannot. ### The CPO First-90 Kit: Ledger, Map, and Readout Templates Published: 2026-06-10 Canonical: https://falkster.com/blog/cpo-first-90-kit Five templates, all downloadable below, all fillable in under 10 minutes each. The interview guide gives every listening-tour conversation the same nine questions so answers become comparable data. The trust ledger and claim ledger are the two files that protect your credibility and your model of reality. The coalition map sorts the org into allies, persuadables, blockers, and sleepers, and includes the pre-wiring checklist for big decisions. The day-90 readout skeleton is the SCQA memo the whole quarter builds toward. The operating plan these templates serve is [The CPO 30/60/90](/handbook/cpo-30-60-90); the month-by-month essays start with [the listening tour, rebuilt as a ledger](/blog/cpo-listening-tour-ledger) and end with [days 61 to 90, first bets](/blog/cpo-days-61-90-first-bets). ### The Product Budget Is a Compute Budget Now Published: 2026-06-09 Canonical: https://falkster.com/blog/product-budget-is-a-compute-budget The product org used to be a fixed headcount cost: want more output, hire more people, and the cost line grows predictably. In an agent-native company, a growing share of output comes from compute (tokens, tool calls, GPU time) rather than people. That cost is variable, usage-driven, and monthly, which means the "product org cost" line stops behaving like a fixed cost and starts behaving like infrastructure. For CPOs and CFOs, three things change: you budget output instead of heads, marginal cost stops being zero so quality and waste become financial, and capacity becomes elastic. The org that learns to plan in this blended unit wins on capital efficiency. The one still budgeting product purely in headcount is optimizing the wrong number. ### The CPO Listening Tour Is Broken. Run a Ledger Instead. Published: 2026-06-08 Canonical: https://falkster.com/blog/cpo-listening-tour-ledger The CPO listening tour, rebuilt as a listening ledger: ask every interviewee the same nine questions, log every answer as a falsifiable claim with a source, a confidence level, and a field for what contradicts it, then mine the contradictions between functions as the real signal. Run a Friday synthesis to update confidence levels, and hold all conclusions for 30 days so your information supply stays uncurated. This is the month-one deep dive of [The CPO 30/60/90](/handbook/cpo-30-60-90), and it borrows the falsifiable-priors discipline that Michael Watkins gestures at and most people skip. The ledger template and the interview script are in [the CPO First-90 Kit](/blog/cpo-first-90-kit). ### Any Competitor Can Clone Your Feature in a Week. Now What? Published: 2026-06-04 Canonical: https://falkster.com/blog/clone-any-feature-in-a-week Feature parity used to take competitors quarters, and that lag was the implicit moat under most product strategies: ship a feature, enjoy a head start, use the runway to ship the next one. The agent stack collapsed that lag to days. It can read your site, docs, public API, and demos and reproduce the experience in a week. So the feature is no longer the moat. Durable defensibility now lives in four places a week of copying cannot reach: distribution, proprietary data, switching cost, and trust. The CEO move is to stop treating features as defensibility, build them fast as the price of entry, and pour real investment into the four moats that remain. ### Taste Is the Last Moat: Why CEOs Can't Delegate Product Judgment Published: 2026-06-02 Canonical: https://falkster.com/blog/taste-is-the-last-moat Taste is the last moat. When execution costs almost nothing, the scarce input becomes judgment: which problem is worth solving, which version is good enough to ship, which feature dazzles in a demo and dies in production. That judgment is taste, and unlike execution it cannot be cleanly delegated, because it is the accumulated pattern recognition of someone who has shipped, been wrong, and felt the cost. CEOs who stayed close to the product kept their taste sharp while the cost of building fell around them. The ones who delegated product judgment along with execution are now running companies they can no longer feel. The move is to protect and encode taste, not to hire around it. ### Being AI-First Is a Product Decision, Not a Tooling One Published: 2026-05-30 Canonical: https://falkster.com/blog/ai-first-is-a-product-decision Being AI-first is a product decision, not a tooling one. Using AI means accelerating the workflow you inherited: faster specs, faster tickets, faster teardowns. Being AI-first means re-engineering the workflow from scratch, assuming AI was there on day one. Most product orgs are doing the first and calling it the second. The capacity gap is the real story, AI does not shrink the team, it lets the team finally clear a decade of deferred work. Roles shift from specialists to generalists while AI becomes the specialist, a film crew instead of a conveyor belt. And once building is cheap, the scarce input is taste: the judgment to ship the one thing that matters and kill the nine that do not. This is the [Product Builder](/handbook/old-pm-vs-product-builder) thesis arriving from the marketing side of the org chart, and it rests on the same foundation as [the Product Operating Model](/handbook/product-operating-model). ### Product Judgment vs Frameworks: What No Framework Teaches Published: 2026-05-29 Canonical: https://falkster.com/blog/what-no-framework-can-teach Twenty years across Microsoft, Adobe, and Salesforce taught me the one thing no PM framework can teach: judgment under ambiguity, which only comes from being wrong at scale, repeatedly. Frameworks are training wheels. They teach you the moves, RICE and JTBD and opportunity solution trees and the rest, but they cannot teach you which move to ignore, what the data is not saying, or when to override the method entirely. That part is earned, not read, and it forms only by making consequential decisions and being wrong enough times that the pattern finally clicks. The AI era over-rewards framework fluency, because frameworks are exactly the explicit, testable knowledge machines are good at and interviews screen for, while earned judgment is tacit and slow and hard to demonstrate in a loop. That is exactly backwards for where things are going, because judgment is becoming the scarce asset. Here is the difference between product judgment and frameworks, and why the thing you cannot teach is the thing that matters most. ### Yes, Scrum Is Obsolete. The Replacement Already Has a Name. Published: 2026-05-28 Canonical: https://falkster.com/blog/scrum-obsolete-replacement-has-a-name Polyakov is right that Scrum is obsolete. Hiring data, content-volume-vs-demand divergence, the framework's ceremony-over-rigor drift, and the way Scrum normalizes missed timelines all support the case. The piece stops at diagnosis. A diagnosis without a named replacement loses the argument inside the room, because "Scrum is obsolete" without "and here is what we do instead" reads as nihilism to the people who have to schedule next week's sprint. The replacement has a name. Four-to-six person builder pod. Three artifacts: a prototype, a five-row eval, an outcome ledger. Cadence: 30 minutes weekly, 5 minutes Friday. No Scrum Master role. ### Kill the AI Office Hours. They're 2026's Agile Transformation. Published: 2026-05-27 Canonical: https://falkster.com/blog/kill-ai-office-hours AI office hours, AI Slack channels, AI prompt libraries, and AI lunch-and-learns are coping mechanisms for an org that does not know how to operationalize AI inside actual work. They produce no shipped output. They exist to make leadership feel like the org is moving. Three replacements work: paired shipping sessions, eval reviews, and kill list reviews. All three are integrated into existing workflow, not added on top of it. The test of any AI ritual is whether it changes what shipped this week. If the answer is no, kill the ritual. ### Agile Was a Coping Mechanism. What Replaces It Isn't Waterfall. Published: 2026-05-13 Canonical: https://falkster.com/blog/agile-coping-mechanism Brian Carpizo published a piece called "Agile Is Dead. AI Killed It. Welcome Back, Waterfall." He's right about the diagnosis. Agile was a rational response to two real 1990s constraints: humans were bad at comprehensive planning, and building was slow. Both constraints just collapsed. The ceremony economy that grew on top, Scrum Masters, story points, planning poker, half-day sprint planning meetings, was always overhead, and AI made the overhead impossible to justify. He's wrong about the destination. What replaces Agile isn't waterfall. It's a spec-first loop where the architecture document gets written WITH AI in an afternoon, fed back into AI as primary context, and validated against working software inside a week. Waterfall failed because humans couldn't plan well. AI removes that constraint. The right answer is to do the planning properly, in hours instead of months, and keep the feedback loop. Iteration survives. What dies is the planning aversion that got dressed up in Agile language for thirty years. ### AI Deletes the Director of Product, Not the PM Published: 2026-05-12 Canonical: https://falkster.com/blog/ai-deletes-the-director The whole industry is asking whether AI replaces the product manager. It is the wrong question about the wrong layer. The IC PM does work that touches reality and the VP does work that requires accountability, and both are reasonably safe. The role actually exposed is the one in between: the Group PM and Director of Product whose main job is moving information up and down, aggregating IC status into leadership summaries and translating leadership priorities back into IC tasks. That information-routing is precisely what AI does best. The first real casualty of AI in product orgs is not the PM, it is product middle management. This is not a claim that Directors add no value. It is a claim that the part of the Director job that is pure relay is large, automatable, and about to be exposed. Here is which part survives, and how to be on the right side of it. ### Field Report: What Broke When We Killed Our Per-Seat Tier Published: 2026-05-11 Canonical: https://falkster.com/blog/field-report-killing-per-seat-tier The day the per-seat tier sunset is when five things broke at a $40M ARR SaaS 21 months into a SaaS-to-agents transition. Migration drift on accounts the dashboards said were fine (12 accounts migrated on paper but barely using the product). An unexpected churning cohort (14 of 35 mid-market accounts with edge use cases). A unit definition that was too loose at scale (200+ contested cases per week). Dispute volume at 12x projection (50 projected, 600 actual). Sales reps quietly negotiated unauthorized extensions for three accounts. By month 22, outcome revenue was 91% and blended gross margin recovered to 71%. The strategy decks make it look linear. The work isn't. ### The PM-to-CPO Bridge in 2026 Published: 2026-05-11 Canonical: https://falkster.com/blog/pm-to-cpo-bridge The 2026 CPO seat demands three things the 2020 seat didn't require: business model literacy (unit economics, pricing strategy, gross margin math), agent fleet operations (managing agents as teammates, not just humans), and public strategic posture (a written point of view on AI's effect on your category). ### Outcome Accountability Is a Luxury Good. Measure Direction. Published: 2026-05-10 Canonical: https://falkster.com/blog/outcome-accountability-is-a-luxury-good Outcome accountability is a luxury good. It works when you can complete an outcome cycle inside a single decision cycle. AI products iterate ten to twenty times a week. Outcome cycles for AI features still run four to twelve weeks. By the time an outcome attributes back, you've shipped forty to eighty more changes. Outcome accountability becomes a lagging measurement that can't drive day-to-day decisions. ### The Triad Is Dead. Pods Are Dead. Agent Departments Now. Published: 2026-05-06 Canonical: https://falkster.com/blog/triad-is-dead-pods-are-dead The pod model assumed humans are the unit of execution. Agent fleets break that assumption. A pod of 5 humans plus 8 agents is structurally not a 13-person pod; the agents have different work, different cadence, different accountability. The right frame is two units: a human department doing judgment work, and an agent department doing routine and synthesis work. They coordinate on exception via a published interface. ### The Dual Transformation Operating Model Published: 2026-05-05 Canonical: https://falkster.com/blog/dual-transformation-operating-model You don't transform legacy. You run it while you transform. Treating the two as one transformation creates a single product that is bad at both jobs. The right model is two clocks inside one product org. Legacy SaaS runs on a six-week rhythm with quarterly OKRs and seat-based forecasting. Agent-native runs on a one-week rhythm with [eval gates](/handbook/the-eval-is-the-spec) and outcome cohorts. The CPO's job is running both clocks deliberately, including the parts where they conflict. ### The CPO's Coalition Map: Why You Can't Run a Migration Alone Published: 2026-05-03 Canonical: https://falkster.com/blog/cpo-coalition-map-essay The five seats, CEO, CFO, CRO, CCO, you. Each has reasons to support and reasons to fight. The 90-day coalition assembly plan: weeks 1-4 land the CFO, weeks 5-8 draft and rewrite the comp plan with the CRO, weeks 9-12 pre-sell the board and onboard the CCO. Most of the work is one-on-one. By day 90, the seven decisions can move publicly because they've been pre-aligned. ### Why "Soft Pivots" Always Become Two Companies in One Office Published: 2026-05-02 Canonical: https://falkster.com/blog/soft-pivots-become-two-companies The soft pivot becomes two companies in one office because it has two cadences, two pricing models, two talent profiles, two customer segments, and one shared P&L. The shared P&L hides the operational tension. Every shared resource (engineering attention, sales motion, CS capacity, customer trust) becomes a turf war. The org chart pretends it's one company; the work is two. Within twelve months, both halves are slow, and the company concludes "we're not good at AI." It wasn't an AI problem. It was a sequencing problem. ### The Eval-First Product Org: Rebuild Around Quality, Not Velocity Published: 2026-05-01 Canonical: https://falkster.com/blog/eval-first-product-org The Eval-First Product Org puts evals at the center, not inside engineering or data science. Four functions: a Quality Spine (5-8 people, owns rubrics), Product Builder pods (4-6 people each, own outcomes), an Economics Unit (3-4 people, owns per-outcome margin and model routing), and a Discovery Network (centralized customer research and analytics). Three functions go away: standalone Product Ops, the separate AI/ML team, and research as an isolated shared service. The smallest first step is publishing eval scorecards for your top three AI features within six weeks. That proves the model before you reorganize anyone. ### The PM-to-Engineer Ratio Is the First Thing AI Breaks Published: 2026-04-28 Canonical: https://falkster.com/blog/pm-to-engineer-ratio The product manager layoffs of 2025 and 2026 are being explained as a skills story: PMs did not adapt, AI made them redundant, the role is dying. That explanation is mostly wrong and it lets leaders off the hook. What is actually happening is a ratio correction. The PM-to-engineer ratio was never about engineers, it was about how much build output one PM could direct. AI raised each engineer's output two to three times, so the same team now generates far more work per PM, and the headcount math that held for a decade broke. This is not a verdict on whether PMs matter. It is arithmetic. But it has a sharp edge: the part of the job that gets compressed is coordination and throughput, and the part that survives is judgment. Here is the math, and what it means for where you want to be standing. ### The CPO Mandate 2026: What Boards Expect From Product Published: 2026-04-27 Canonical: https://falkster.com/blog/cpo-mandate-2026 The 2026 CPO board deck has seven slides: the outcome ledger (bets and what moved), per-outcome unit economics, the eval scorecard, the agent inventory, cycle time by stage, headcount-to-output ratio, and a "willing to be wrong" paragraph. Velocity is no longer a defensible metric. Per-outcome cost and margin is. If you cannot answer "what's the eval score on the agent that drove most of this," you are presenting to a board that has moved past the deck you are showing them. Getting to the seat where you present that deck at all is a separate problem, and I mapped it in [The PM-to-CPO Bridge in 2026](/blog/pm-to-cpo-bridge). Rebuild the deck before the next quarter, not after the bad call. ### My Best Product Decision Was a Kill, Not a Launch Published: 2026-04-25 Canonical: https://falkster.com/blog/my-best-decision-was-a-kill The best product decision of my career was a kill, not a launch. I stopped something that was already built, already loved by the team that made it, and already on the roadmap, because the honest answer to "would we start this today" had become no. The industry rewards exactly backwards: launches get announced and celebrated and put on reviews, while kills get buried and quietly resented, even though a good kill often creates more value than a mediocre launch. Killing well is the rarest leadership skill in product, because every incentive points the other way and sunk cost fights you the whole time. In the AI-native present this matters more, not less, because when building collapses to nearly free, the scarce skill moves from building things to deciding what not to ship. Here is the kill that mattered most, and why the kill decision is becoming the core of product leadership. ### Empowered Product Teams Were a ZIRP Feature Published: 2026-04-21 Canonical: https://falkster.com/blog/empowered-teams-were-a-zirp-feature The empowered product team was a luxury of the zero interest rate era, not a timeless truth, and now that capital is expensive and AI changed the constraint, the empowered-team orthodoxy is breaking. The model assumes a company can afford to hand cross-functional teams broad autonomy and patient time to discover the right outcome. That patience was cheap when capital was cheap. It is not cheap now. Worse, the whole empowered apparatus existed to make good decisions about scarce, expensive engineering capacity, and AI collapsed that cost, so the machinery is aimed at a constraint that no longer binds. Marty Cagan was not wrong for his era. He was wrong to teach an era-specific configuration as a permanent law of product. What replaces it is a smaller team of product builders carrying more of the loop with agents. Here is the uncomfortable case. ### The New Org Chart for AI Published: 2026-04-19 Canonical: https://falkster.com/blog/new-org-chart-for-ai AI coding tools work. The org chart doesn't. Cursor and Claude Code boosted developer output but org-level velocity stayed flat because the gains get swallowed by review queues and coordination meetings. CodeRabbit's data: AI PRs are 18% larger and take 3.6x longer to review. Logilica: 21% more tasks shipped but PR review time up 91%. Fix three layers in order. One: get every engineer across the AI-adoption line in 90 days. Two: rebuild review for AI speed (move humans from line-by-line review to specification and verification). Three: flatten the coordination layer (the relay middle managers exist to do is exactly what agents replace). The subscription works. The org chart is the cost center. ### Product Builder Job Ladder: Four Fork-Ready JDs from L4 to Principal Published: 2026-04-18 Canonical: https://falkster.com/blog/product-builder-job-ladder A fork-ready four-level job description ladder for Builder PMs: Product Builder (L4, 4+ years), Senior Product Builder (L5, 6+ years), Staff Product Builder (L6, 9+ years), Principal Product Builder (L7, 12+ years). Five dimensions scale: scope, architecture decisions, mentorship, external voice, years of experience. The operating model does not scale. At every level, the Builder PM ships working prototypes (not specs), designs AI systems end-to-end, owns evals, reasons about cost and latency, validates with users not stakeholders. If you have no Builder PMs yet, hire a Senior first because they set norms. If you're starting a new pillar inside a larger org, hire a Staff. Principals rarely come in cold. Fix the operating model before hiring against the ladder. ### The PM Role Is Being Rewritten. Are You Rewriting Yourself? Published: 2026-04-16 Canonical: https://falkster.com/blog/pm-role-rewritten AI-forward companies are hiring "Product Builders." Not as a quirky experiment. As the new standard for what the PM job requires. The six skills that matter now, priority-ordered: rapid prototyping (hours from idea to working artifact, not weeks to a deck), customer proximity (AI compressed build time toward zero, so the only durable edge is whoever understands the customer best), AI fluency (decide which primitive fits the workflow: rules, RAG, agent with tools, fine-tuning), outcomes thinking (define the customer behavior change you'll cause and the eval that proves it before code is written), storytelling and distribution (write the launch tweet before the spec, run rollout to the first 100 customers yourself), and end-to-end ownership (the meta-skill: insight to prototype to launch to gross margin). Most PMs are in the observation phase. A smaller group has moved into building. A very small group is operating at a level where their output is indistinguishable from a small engineering team's. The gap between those groups is growing. ### Every CPO Job Is a Turnaround: The First 90 Days Published: 2026-04-02 Canonical: https://falkster.com/blog/every-cpo-job-is-a-turnaround I have been CPO four times, at Commure, Crisis Text Line, SOCi, and Smartcat, and every one of those jobs was secretly a turnaround. Nobody hires a Chief Product Officer when product is working. Companies promote from within when things are healthy and go outside for a CPO when growth has stalled or the org has lost trust. So the title is a lie about the job. The real CPO mandate in the first 90 days is diagnose the real problem in 30 days, make one visible change by 60, and install a new operating model by 90, in that order, not a reorg on day one. And in the AI-native era the turnaround is bigger, because you are not just fixing the product org, you are converting it to an outcome-to-prototype model where build cost has collapsed. Here is what the first 90 days actually require. ### Founders Don't Want a CPO. Here's What They Want. Published: 2026-03-31 Canonical: https://falkster.com/blog/founders-dont-want-a-cpo Founders do not actually want a CPO. They want their own [product judgment](/blog/what-no-framework-can-teach) cloned and scaled across more surface area than they can personally cover, without losing control of the decisions they care about most. The CPO founder relationship fails so often because nobody names this. It is also where most people [misread founder mode](/blog/founder-mode-misread): the founders worth working for are not refusing to delegate, they are refusing to delegate the specific decisions their own judgment is the product of. The CPO arrives expecting real ownership, the founder keeps overriding them on the calls that matter, and both sides feel betrayed because they never agreed on the actual deal. I have taken the CPO seat under strong founders more than once, and the pattern is consistent: the CPOs who succeed spend their first months absorbing the founder's taste so they can decide the way the founder would, then expand ownership only after they have earned predictive trust. In the AI-native present this gets stranger, because agents can now partly clone the judgment founders were hiring a CPO to extend, which changes the deal entirely. Here is why the CPO founder relationship fails, and how to make it work. ### The PM-as-Translator Is Dead Published: 2026-03-22 Canonical: https://falkster.com/blog/rippling-killed-the-pm-translator The PM-as-translator role is dead. For 15 years, PMs were professional middleware: reformatting customer input into decks for engineers, waiting for analysts to pull reports, filing tickets to change a button label. AI and MCP just stripped away three layers of translation. PMs now write markdown in git repos next to the code, query session replays in plain English via LogRocket's MCP server, and fix their own copy by pushing PRs. What survives: judgment about what to build, customer intuition (data isn't understanding), cross-functional alignment, systems thinking. What dies: the planning deck, the weekly metrics meeting, the voice-of-customer monopoly, the feature factory PM. If your 12 PMs are still translators, ask the uncomfortable question: what are they actually doing that needs 12 people? ### Product Management Without Revenue Made Me Better Published: 2026-03-19 Canonical: https://falkster.com/blog/product-with-no-revenue-model The highest-stakes product of my career, at Crisis Text Line, had no revenue model, and it made me a better product leader than any monetized product I ever shipped. Mission-driven product management removes the one metric most teams hide behind. When there is no revenue to grow, you cannot tell yourself the product is working because the number went up. Every decision gets judged on pure outcome, did this help a person in crisis, with nothing to launder a weak call through. That is a harder test than revenue, not an easier one, and revenue turns out to be a crutch that lets product managers avoid judging real value. AI agents now force the same outcome-first discipline, because once building is cheap, effort stops being a proxy for impact too. Here is what working without revenue taught me, and why it is suddenly the most relevant lesson I have. ### The Quarterly Business Review Template That Gets You Promoted Published: 2026-03-16 Canonical: https://falkster.com/blog/quarterly-business-review A QBR is the leadership meeting where a product manager presents the past quarter and gets the next one funded. The five-section structure that works: (1) top-line scorecard with three numbers and red/yellow/green; (2) what we learned this quarter; (3) what we shipped and the outcomes it produced; (4) next quarter's plan with explicit metric bets; (5) the clear ask in one sentence. Total runtime: aim for 30 minutes, not 45. Lead with bad news on slide 2, not slide 20. End with one concrete request that leadership can say yes to in the room. The full slide-by-slide template is the [downloadable artifact](/artifacts/quarterly-business-review.md) at the bottom of this post. The downloadable 9-slide kit that implements this argument is [the QBR deck template](/blog/qbr-deck-template). For the underlying operating rhythm that makes the QBR easy to write, quarterly outcomes plus a continuous Impact Loop, see [The Impact Loop](/handbook/impact-loop) and [The CPO Mandate 2026](/blog/cpo-mandate-2026). ### The Guerrilla PM Playbook Published: 2026-03-13 Canonical: https://falkster.com/blog/guerrilla-pm-playbook Most PMs work without a research team, dedicated data analyst, or full-time design support. The Guerrilla PM playbook runs world-class product management in 2 hours a week, four 30-minute blocks: Monday discovery call, Tuesday competitive scan (AI agent does 80%), Wednesday prototype session in Claude Code, Thursday data review (AI agent runs queries). The system compounds. By month three, you're operating at a level that PMs waiting for support functions never reach. Tools cost under $100/month. Scrappiness forces clarity. When you can't spend two weeks on customer research, you ask better questions. Block one hour next Monday and call a customer. ### OKR Writing That Doesn't Suck Published: 2026-03-12 Canonical: https://falkster.com/blog/okr-writing-guide Most OKRs are disguised task lists. The litmus test for a real OKR: if your key result were achieved, how would the behavior of your customers, users, or business actually change? If the answer is "we'll have shipped the thing we planned to ship," it's a task. Real OKRs describe a future state ("reduce time-to-value on mobile from 8 minutes to under 4 minutes"), not a project plan ("redesign mobile navigation"). Pick 3-5 objectives per function, max 3-4 key results each, ambitious but achievable (70-80% hit rate). Cascade through outcomes, not work breakdown. OKRs are a decision-making tool: "Does this help us hit our Q2 OKRs? If yes, fund it. If no, don't." That's the entire point. ### Empowered Teams When Your CEO Doesn't Buy In Published: 2026-03-11 Canonical: https://falkster.com/blog/empowered-teams-resistance You don't need permission from leadership to run empowered teams. You need evidence. The playbook is four tactics: reframe feature requests as outcomes ("we want to improve Y, X is what we think will improve Y"), run discovery silently and bring evidence, build prototypes before asking for roadmap slots, and show before-and-after metrics on every feature. Then repeat for six months. Leadership says yes not because they became enlightened. They say yes because the evidence is overwhelming. I've watched this play out at seven companies. The pattern is always the same: leaders waiting for permission lose, leaders shipping better outcomes win. ### Running Your First Product Trio Published: 2026-03-09 Canonical: https://falkster.com/blog/product-trio-guide A product trio is three people (PM, designer, tech lead) who own a product area together and make meaningful decisions as a unit. It's not a meeting. It's a weekly operating rhythm. The shape: 2 hours blocked weekly, 50 minutes of discovery together with raw notes and sketches, 10 minutes writing what we learned, 1 hour deciding together with committed ownership. The point is that alignment happens synchronously during discovery, while the team is in the room. It doesn't get lost in Slack threads where half of them never read the context. Killed a "collaboration workspace" feature in week two of running my first trio at Smartcat because the tech lead's architecture question and the designer's "do customers actually want a workspace?" reframed everything. Pick one product area. Three people. One two-hour block. Start this week. ### PMs Won't Be Automated - They'll Be Amplified Published: 2026-03-08 Canonical: https://falkster.com/blog/pm-wont-be-automated AI won't replace PMs. But it will replace 80% of what most PMs do (writing PRDs, sitting in meetings, processing information, coordinating people). The PMs who survive are the ones who were always doing the other 20% well: customer empathy you can't get from reading tickets, strategic judgment that weighs incomparable things, cross-functional leadership that's politics and trust and vision, and creative vision that imagines what doesn't exist yet. The amplified PM doesn't just survive automation of the 80%, they weaponize it. 4x more time for customer conversations, prototyping, judgment, alignment. If AI handled everything information-y tomorrow, what would you actually do? That's the question to answer this week. ### Shipping Velocity vs Being Right: My Two Years Shipping Zero Published: 2026-03-04 Canonical: https://falkster.com/blog/shipping-nothing-at-microsoft-research Microsoft Research paid me to ship nothing for nearly two years on .NET-era work, and it was the best product training I ever got. The reason surprised me: with no ship date to hide behind, the only thing I could be judged on was whether my thinking was correct. That taught me to separate being right from being shipped, which is the hardest and most undervalued discipline in product. The industry worships shipping velocity, and velocity is a real skill, but it is not the same skill as being right, and we constantly confuse the two. In the AI era this matters more than ever. When an agent ships a working prototype in an afternoon, raw velocity stops being a moat, because everyone has it. The scarce skill becomes knowing what deserves to ship. Cheap building turns "ship nothing until it's right" from a luxury into a discipline. ### Why Acquisitions Fail: The Integration Autopsy Published: 2026-02-24 Canonical: https://falkster.com/blog/why-acquisitions-die-inside-big-companies Why acquisitions fail at integration is not a mystery, it is a pattern, and I watched it run three times inside Salesforce across the Marketing Cloud, Quip, and Slack-era waves. The acquired team dies in three predictable steps. First it loses its constraint, the scarcity of money, people, and time that was forcing sharp decisions. Then it inherits the parent's process, the reviews and planning cycles and approval chains built for a giant organization. Then it stops shipping, because the velocity and focus that made it worth buying have been engineered out of it. Integration is where products go to die, and the cause of death is almost always the same: the parent removed the forcing function and added friction in its place. AI-native acquisitions will fail the exact same way unless the parent deliberately protects the team's loop, because an AI team's speed depends entirely on a short feedback loop and full decision authority. ### Leading a Product Team Through Layoffs: What Survives Published: 2026-02-12 Canonical: https://falkster.com/blog/product-leadership-through-layoffs I have led product teams through three layoffs, and the lesson nobody tells you is that the cut is not the hard part. Deciding who goes is brutal but bounded. Keeping the survivors building is the part that actually breaks companies, because a layoff sends a signal to everyone who stayed, and if that signal is fear and chaos, your remaining team freezes and quietly starts looking for the door. Most product organizations survive the cut and then slowly die in the weeks after, when the people who remain stop building and start hedging. Less survives a layoff than leaders think: institutional memory leaves, projects lose owners, trust takes a hit, and only what you explicitly protect makes it through. In the AI-native present this gets more dangerous, because efficiency-driven cuts tempt leaders to bank the entire gain instead of reinvesting it in the survivors, the same cheap-capital logic that made [empowered product teams a ZIRP feature](/blog/empowered-teams-were-a-zirp-feature). Here is what actually survives a layoff, and the leadership moves that matter when the spreadsheet is done. ### What Happens After Acquisition: My Product Was Killed Published: 2026-02-09 Canonical: https://falkster.com/blog/acquisition-killed-my-product What happens after acquisition, in my case, is that Microsoft killed the product I built, and it was the right call. I sold MVC to Microsoft, the standalone product went away, and the capability got absorbed into a much larger platform with real distribution. The romantic founder narrative says integration ruins products and the parent company is a graveyard. Sometimes that is true. But mostly that story is ego. When the acquirer's distribution matters more than your roadmap, keeping the standalone product alive is a vanity tax on the capability customers actually wanted. The test is simple: after the kill, did the value reach more customers or fewer? In my case it reached vastly more. The same logic now governs AI features absorbed into platforms, and the teams fighting to stay independent are usually protecting their pride, not their users. ### What Acquirers Actually Buy in a Startup Acquisition Published: 2026-01-29 Canonical: https://falkster.com/blog/what-acquirers-actually-buy What acquirers actually buy is almost never your product, and usually not even your revenue. I sold MVC to Microsoft, and I have watched acquisitions from the inside at Salesforce and elsewhere, and the pattern is consistent: a strategic acquirer buys one of four things, a capability it cannot build fast enough, a team it wants intact, a defensive block to keep you away from a rival, or time in a market where being early is everything. Founders optimize for the wrong asset constantly. They polish the product and chase revenue while the buyer's real thesis is the team or the capability. In the AI era this is shifting harder, away from codebases and toward teams and taste, because a strong team with an AI substrate can rebuild most products quickly. The codebase stopped being the moat. The judgment is. ### The Reorg Is a Product Decision Nobody Calls One Published: 2026-01-22 Canonical: https://falkster.com/blog/the-reorg-is-a-product-decision Org design is product strategy, and Conway's Law is the reason. Your org ships its own communication structure, so a reorg sets the ceiling on your roadmap before anyone writes a ticket. Most leaders treat reorgs as HR events, headcount math and reporting lines, then act surprised when the product mirrors the new boxes with seams a customer can feel. The org chart is the most consequential product spec in the company and almost nobody reviews it as one. In the AI-native present this gets sharper, not softer: when agents absorb the routine work, fewer humans coordinate more, and the new product lever is where the agent layer sits and which judgment stays human. Here is why the reorg is the product decision you are not calling one, and how to design org structure around the product you actually want to ship. ### Startup Exit Lessons: My $6.5B Win Taught Me Nothing Published: 2026-01-15 Canonical: https://falkster.com/blog/the-exit-that-taught-me-nothing My biggest startup exit, the one around $6.5B, taught me almost nothing about product leadership. The category was rising, the timing was perfect, and the market would have rewarded a decent team running almost any sane play. The startup that returned close to nothing taught me everything, because there was no enormous outcome to launder my decisions through, so I had to look at each one honestly. The industry has this backwards. We worship exits, put the survivors on stage, and build our entire body of product wisdom on the handful of teams the market happened to lift. That is survivorship bias, and in the AI era it is getting more dangerous, because cheap building lets weak judgment ship fast and hide inside a good market. The real startup exit lessons live in the losses. ### The AI Revolution Is Faster and Deeper Than the Industrial Revolution Published: 2024-12-28 Canonical: https://falkster.com/blog/medium-ai-revolution The Industrial Revolution amplified human muscle and took centuries. The AI Revolution amplifies human thought and is compressing centuries of change into decades. Three dimensions of disruption: society (machines amplifying thought, not muscle), workplace (workers moving upstream from production-line to higher-order problems), money (wealth concentration on whoever owns the data and models). For companies: audit your workflows (60-70% of knowledge work is deterministic enough to automate), invest in data infrastructure, upskill the workforce, adopt test-and-learn. For SaaS: build a knowledge graph before agents, integrate workflows not features, productize outcomes not capabilities, build trust first. The window to act intentionally is closing. ### The AI Product Engineer: One Person Doing What Used to Take a Team Published: 2024-11-21 Canonical: https://falkster.com/blog/ai-product-engineer AI tools are collapsing the distance between PM, design, and engineering. The AI Product Engineer is the archetype emerging: one person who thinks strategically about what to build, creates and iterates on the experience, and ships it, with AI amplifying each step. PMs are well-positioned because they already have the hardest skill (customer empathy and strategic thinking). AI gives them the "how." Things that used to require three people and four weeks now require one person and four days. PMs who treat AI as "something my team uses" instead of getting hands-on with Cursor, Claude, and Copilot are going to fall behind fast. Pick one feature idea this week, skip the spec, build the prototype yourself. ### The Rise of the AI Product Engineer Published: 2024-11-21 Canonical: https://falkster.com/blog/medium-ai-product-engineer The product manager role has evolved through four eras: the 1930s P&G Brand Man, the 1960s HP product owner, the 1980s Microsoft Program Manager, and the 2000s Big Tech PM. The next era is the AI Product Engineer: one person owning the full lifecycle (strategy, design, development, customer insights), amplified by AI to do the work of three. PMs are best positioned to step into this role because they already have customer empathy, strategic thinking, and holistic focus. The challenges are real (overload, blind spots, ethical risk). The benefits are speed, clarity, cost efficiency, and customer focus. Five years out, this is the norm for small fast-moving products. ### The Evolution of Product Management Over the Last 20 Years Published: 2024-11-15 Canonical: https://falkster.com/blog/medium-evolution-of-pm Product management has evolved through seven phases over 20 years: early-2000s project coordinator, 2001 Agile Manifesto, 2005 Steve Blank's Customer Development, 2008 Marty Cagan's empowered teams, 2011 Eric Ries Lean Startup + Teresa Torres Continuous Discovery, 2012 Nir Eyal's Hooked behavioral design, and today's strategic PM combining everything. The next shift is AI as co-manager: AI automates the boring parts (market research, feedback synthesis, requirements translation), letting one talented person own the whole product as an AI Product Engineer. Preparation: develop cross-functional expertise, use AI aggressively, build human-centered skills, break silos, learn continuously, practice ethical thinking. ### When Your Data Becomes the Product Published: 2024-10-10 Canonical: https://falkster.com/blog/medium-data-becomes-product When a nonprofit offers a free service and generates revenue by monetizing your data, you are the product. This is especially troubling for intimate data: health, mental health, behavioral patterns of people in crisis. The greater-good defense ("we use these insights to help people") rarely traces clearly from "sold anonymized health data" to "helped someone." GDPR forces transparency in the EU; the US has only sector-specific protections like HIPAA and FERPA. AI makes this more urgent because machine learning extracts deeper insights and infers sensitive information you never explicitly shared. The call isn't to stop monetizing data. It's to be honest about it and require informed consent from vulnerable populations, especially children.