We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Prioritization is tension management, not item ranking. Teams get better signal by examining recurring tensions—where the same arguments return, conviction fails, and momentum wins despite better judgment—rather than debating items that will attract attention anyway. The key distinction is between prioritization judgment (what deserves investment) and prioritization-as-enacted (what actually moves); the missing ingredient is often commitment under present-day inconvenience, not agreement. Before applying a framework, run the fill-in-the-blank exercise to name the deferred threat, the “fun” priority consuming too much, the capability gap, and the credible 80/20 scope cut. Then choose which tensions to hold in the portfolio across time, value, and urgency.
Loops are execution architecture, not product strategy. A loop adds memory and a goal and can automate agentic work such as coding, but it is a poor mechanism for deciding what to build. Replacing users with AI can reproduce—and worsen—the Product Death Cycle: ask what features are missing, build them, and still have no usage. Use loops after a PM has made the human decision about the customer problem and the “what + why”; let AI execute, not choose the product.
Tactical Playbook
Turn feedback into evidence tied to a decision. Start with actual behavior, not compliments, opinions, or hypotheticals; design research around the question—churn, win/loss, buyer triggers, or problem discovery—and make it continuous. For each note, record the product area, pending decision, customer role, and behavior behind the comment. Review it with product and customer-facing owners on a fixed cadence, logging both the decision and the missing evidence. A reported B2B SaaS sequence layers incoming feedback → small qualitative validation (roughly 20–30 people) → quantitative survey → post-launch A/B test → production monitoring. The last two are stronger checks because they observe behavior rather than stated intent.
Case Studies & Lessons
Agent adoption changes both the product surface and the PM job. One agent-first marketing-software team defines L1 as AI-assisted search, L2 as running an agent in a cloud session, and L3 as continuously running agent sessions or teams; it says a pre-AI PM focused on wireframes and specs now needs to become L3. Agents are treated as immediate power users: good documentation reduces onboarding, while agent use exposed missing APIs and made 1%-of-audience experiments cheap enough to try. The team warns that rapid feature generation can create “slop,” so it fed years of product critiques into an agent to enforce a living product bar. For customer-facing agents, it reports training against five to ten use cases until reaching roughly 50–70% resolution and insists the product be usable on day one, not after a large implementation. The PM takeaway: pair agent access with explicit decomposition, strong APIs, cheap experimentation, and a quality bar.
Career Corner
Make progression legible through differentiated strengths. Shreyas Doshi names two stuck points: senior ICs unable to gain scope or team responsibility, and GPMs/directors unable to reach VP/CPO roles. For level-one stuckness, his 10-30-50 heuristic is top 10% in one skill, top 3% in a second, and top 50% in the third. For leaders, the core skills are strategy, influential communication, and editing—cutting, simplifying, and clarifying other people’s work rather than writing everything yourself. Choose two skills to compound, and replace some document production with “red-pen” work that raises team output.
Aakash Gupta argues that the old resume-plus-execution path has become a bundle of visible proof: referrals, fast customized applications, a portfolio, working feature prototypes, and AI knowledge demonstrated at work and privately. Build one role-specific artifact rather than only claiming AI fluency.
Tools & Resources
PM Superpowers is a free, open-source, MIT-licensed Claude plugin aimed at product thinking rather than faster PRD generation. It includes VRIO, pre-mortems, RICE/ICE, moat analysis, and decision logs; /strategy or a natural-language request walks through the work and saves structured artifacts. Try it for a pre-mortem before kickoff or log a decision while it is made, instead of reconstructing rationale from Slack or Zoom.
- AI agents are reaching a consumer tipping point: the paradigm shifts from "help me do this" to "just do it," with persistent agents that have their own computer instance, memory, and can act across screens; the next step is proactive action (e.g., an agent reaching out to Comcast on its own).
- Trust is the key battleground for AI agents: users will decide which agent gets their data, APIs, inbox, and calendar, and whose answers they rely on. OpenAI's decision to make AI free and widely usable helped shift perception, though public trust is still very low and changes only through direct experience.
- Apple may become the default consumer AI agent by doing nothing: it has unmatched distribution, closed platforms (messages, payments, location), and users are cheap, lazy, and habituated; its internal AI confusion ironically keeps it from making mistakes.
- For AI products, defensibility lies in owning closed, unique data, not open APIs: iMessage/WhatsApp are defensible because they lack APIs; platform owners like Apple can hold exclusive API access. In physical/industrial AI, proprietary data is inaccessible and gives startups a window to build distribution before hyperscalers commoditize it.
- Enterprises are shifting to running open-source models on their own proprietary data instead of feeding closed labs, worried their data will be used against them (as with Figma). This will drive local model adoption and routers, though routers are expected to commoditize and many companies will build their own.
- AI models don't deliver value alone: the last mile requires real-world operations and obsession — "you can't vibe code a home health nurse."
- OpenAI exec churn is a feature, not a bug: Altman hires highly ambitious people who, in an era where you can build anything, will leave to start companies; low financing risk, low talent risk, and high upside make leaving rational.
- Airtable's acquisition: Hyper Agent was carved out before the deal, so only the legacy business was acquired — founder-led AI bets often remain separate from the core product exit.
- AI content-labelling UX is broken: C2PA credentials are broadly adopted but consumer platforms label any AI touch as "made with AI," confusing users (e.g., a blemish removal), and product teams need better provenance surfacing.
- Mind the Product's Mike Belceto is writing a book (due Feb 2027) arguing that product sense, taste, curiosity, and judgment are timeless skills AI can't automate away, and it offers ways to get better at each.
- SpaceX AI launched Grockbot into public beta on Aug 11 as an AI "digital teammate" with its own cloud computer. Users set it up by giving it a job description, tools, and check-in times; it runs continuously, signs into tools, and works unattended. It holds state across sessions, can operate inside authenticated apps, and is more user-friendly than earlier agent setups. Multiple bots can run, message each other, plan in group chats, and one can manage others. Internally, SpaceX AI used it as a sales outbound bot (researches accounts, drafts personalized outreach) and a demo readiness bot (checks/fixes demo environments overnight). It's in public beta on desktop and iOS for "super gro heavy cursor ultra and cursor teams premium" subscribers; teams/enterprise can join a waitlist. Product implication: design for agentic users as well as humans, because agents may soon use your product more than humans do.
- Anthropic announced (Aug 11) that Claude will embed invisible watermarks in all generated text, starting with new models in the EU and rolling out globally across Claude apps, the API, and cloud partners, with older models updated by Dec 2, 2026. These watermarks are invisible but detectable, and for images/files Anthropic uses the C2PA open standard. This is in response to EU AI Act Article 50's requirement to mark machine-generated content. Limitations: watermarks can be defeated by editing, paraphrasing, or translation, so absence isn't proof of human authorship. Product impact: if your product generates content with Claude that users publish, that content will carry watermarks; decide upfront whether that's a feature or concern and get ahead of transparency messaging (UI/terms), as the Hank Green backlash shows the risk of being caught off guard.
- Meta released Muse Glimmer (Aug 10), a 30B-parameter open-weight model under Apache 2.0 built for local agentic workflows. It runs fully offline on consumer hardware (e.g., high-end Mac or gaming PC), with no API calls, no data leaving the machine, and no usage fees or rate limits. It scores 75.5 on MCP Atlas Public (benchmark for tool calling and multi-step agents), beating other local models, and Meta's speculative decoding gives 2-3x speedups on high-end Macs. This combination makes on-premise agentic AI viable for privacy-sensitive verticals (healthcare, legal, fintech, government) and eliminates token-cost limits for high-volume AI features, potentially expanding the market for products that couldn't use cloud AI.
- AI autonomy ladder at Clavio: L1 = use AI to search; L2 = spin up a cloud session and run an agent; L3 = constantly run agent sessions or teams of agents. All employees, including PMs, sales, and marketing, are expected to reach L3 by end of June or "not going to be skilled to survive in this next era" . The average PM who previously worked on wireframes and specs now has to become an L3 .
- "Dark factory" agent-development pattern: Clavio routes prompts through an internal agent that acts as PM — it breaks requirements into specifications, decomposes problems into engineering subsystems, writes contractual API interfaces between them, and spawns sub-agents per piece . The pattern adds human-in-the-loop feedback: the agent asks clarifying questions over hours/days rather than a single upfront plan; the first Composer prototype was built over a weekend .
- Coaching the general-purpose LLM: Treat the base model like a talented generalist athlete and coach it to be great in one domain. Clavio feeds its marketing agent real-time consumer-behavior data and gives it a "coach" that scores proposed campaigns for predicted engagement/revenue and offers tuning feedback .
- Agents as power users reshape product thinking: Software has a power-law distribution of user skill; agents jump straight to the most advanced users and sit to their right, so onboarding matters less . Agents surface missing functionality (Composer asked for AMP-email APIs) and drive demand for cheap experimentation infrastructure (testing ideas on 1% of audience) .
- Codifying taste and the product bar: Clavio loaded years of product-review feedback into a database and gave it to an agent, so before Friday product reviews the agent enforces what's worked and won't and cuts low-quality ideas; the team can push back on the rule set, and the goal is to codify taste as "our product should work this way, it should feel this way, these are the outcomes we're after" .
- API-first mental model: With agents as the primary users, think of software as infrastructure exposing interfaces, actions, and APIs; great internal and external agent-friendly APIs can revive dated software (headless Salesforce and Twilio's turnaround cited as examples), and APIs are "the simplest thing you can improve" .
- Agentic product launch and self-training: For SMB customers that can't afford FDEs/SEs , Clavio trains customer agents using classified real/synthetic use cases, gives an agent full API access, and lets it train until it works; delivered agents start at roughly 50-70% resolution rates . Launch rule: if an agent product can't be tried out of the gates and requires big implementation, it's "dead on arrival" — the wow experience has to be day one .
- Career signal for the AI era: People who can put an agent or team of agents to work, decompose problems, and validate results will be "enormously successful" in the next era .
Susan Care, an iconographer who worked on the Macintosh at Apple, shared product lessons from Apple and Facebook:
- The Macintosh team's product vision was a computer “anyone could use,” understandable without a manual and friendly; that vision directed the icon and font work . Care treated the 16×16 black-and-white pixel constraint as a creative driver: understand constraints, then get excited about working within them .
- Design heuristic: minimal detail makes UI more universal — simple drawings let users project onto them, so use “a salient detail or two”; avoid depicting specific products because those metaphors age poorly (e.g., floppy-disk save icon) .
- Brand trade-off: Steve Jobs blocked an “Apple farm” of repeated logos on keyboard shortcuts to protect Apple's logo; the resulting abstract command key was harder to remember than a metaphor, though it later proved to echo a Swedish castle symbol .
- Stakeholder review tactic (from Andy Herzfeld): show decision-makers several options rather than one; a single option invites a no and another iteration, while a few options allow them to reject something and still pick .
- Facebook Gifts case study: a new gift launched daily at midnight; first-15-minute sales predicted bestsellers; cute items beat luxury ones (kiss mark was the all-time top seller, penguin limited editions sold out); Facebook ended the program to avoid competing with third parties .
- Planning: “nothing takes an hour” — allow extra time for product work (futurist Paul Safo) .
- Communication: architect Daniel Nord advised making ideas visual — “show, don't tell” .
- Scaling: consensus hiring and whole-team alignment worked up to ~15 people; beyond that, growth brings trade-offs .
- Shreyas Doshi identifies two common PM career stuck points: level one — senior PMs unable to reach the next level of scope or managing a team; level two — group PMs/directors unable to get promoted or get VP/CPO offers even from senior director roles at companies like Google or Meta .
- To break level one stuckness as an individual-contributor PM, aim to be a "10 30 50 PM": top 10% in one of three skill senses, top 3% in a second, top 50% in the third (which senses don't matter). Doshi calls this the surest path to product leadership and to the top 10% of compensation among peer PMs .
- Influential communication and critical thinking are the two skills PMs must constantly level up at every career stage; they separate okay careers from good ones and good from great .
- Level two stuckness is driven by three skills: strategy, communication, and editing . At GPM/director level, technical PM skills are assumed; success depends on influencing peers, org, and executives . Communication is not standalone — done right, it multiplies all your other skills, making execution, analytics, or strategy look like superpowers .
- Editing (from Keith Rabois, via Jack Dorsey) means acting more as an editor, less as a writer: cutting, simplifying, and clarifying others' work rather than producing it. Switching from creating to editing is the hardest change for new PM managers, and until they make it, their PMs stay frustrated .
- To improve a skill, decompose it into smaller sub-skills and tackle each component. Example: product sense = cognitive empathy + domain knowledge + creativity .
- Embrace your preferred learning style — read/listen/watch, doing, or shadowing someone — instead of fighting it. If you buy books but never read them, that's a signal your style isn't read/listen/watch, not a character flaw .
- For read/listen/watch learners, Doshi's book picks: "Understanding Michael Porter" for strategy — read it four times before any other book, avoiding other strategy content — and "Never Split the Difference" for communication .
Requirements stability through early alignment: A PM at a product with many contract customizations describes a process that keeps requirements stable: discovery months before dev, tiger-team calls with all related architects and domain dev SMEs, architectural planning while drafting stories, and PI planning to set delivery commitments. Their Notion documentation is ~95% complete after decisions (only success metrics pending, defined with BI), 99% after architecture (only delivery date pending), and 100% after PI planning; requirements rarely change because high-level agreements precede story drafting. She cautions that this works with knowledgeable, committed devs and a standard process — anything beyond that is "just another fancy tool" .
NPS survey design tip: A former CX Manager (now PM) advises against a 7-point scale for an NPS survey: an 11-point NPS can be simplified with a UI slider that shows no numerical values and maps ranges to the 11-point scale, reducing respondent confusion (unless the tool allows custom scales). She brings experience from CSAT/CES/NPS surveys across 5-6 lines of business .
AI product strategy: core intelligence vs. UI features: At an AI fintech startup, a newer PM argues for investing in memory and the core intelligence layer while their Senior PM focuses on building fancy AI UI features. After a data-backed report failed to align them, a community advisor suggests framing the argument via model limitations: if the model has memory/intelligence issues, those UI features are constrained — a stronger model enables fancier features, "there's your buy-in argument" .
Post-launch feedback loop: An internal product team built a feedback loop using Claude Code and other tools, capturing 1,000+ feedback items over a 30-day post-launch period and reporting them to both leadership and end users .
PM Superpowers: tactical strategy plugin: A Principal PM (13 YOE) released a free, open-source Claude plugin (PM Superpowers) that converts product strategy frameworks into tactical day-to-day skills: VRIO analysis, project pre-mortem (Tigers/Paper Tigers/Elephants), RICE/ICE prioritization, strategic moat and aggregation theory, and decision logs. It runs via slash commands (e.g.,
/strategy) or natural language like "help me prioritize my backlog," walks users step-by-step, and saves structured artifacts. Example uses: VRIO + competitive landscape before a QBR, pre-mortem two weeks before kickoff, and logging decisions at the moment a call is made. Install viaclaude plugin marketplace add aniganti/pm-superpowers; MIT licensed with contributions welcome .
Loops are not AI strategy. Loops are a technical architecture that adds memory and a goal, ideal for automating agentic tasks such as coding execution (beyond prompts + context), but they are "terrible for deciding what to build" — human judgment must own product strategy . Aakash Gupta argues David Bland's 2014 Product Death Cycle (ask customers what features are missing → build them → still no usage) still holds, and replacing users with AI makes it worse since AI can only simulate taste, not pinpoint "what + why" like a human .
Changing PM job-search playbook. Five years ago a strong resume and execution skills landed a PM job in 2–3 months; now candidates ideally need a fully optimized LinkedIn profile, a referral network, near-immediate customized applications, weekly relevant posting, an online product portfolio, ready working feature prototypes for the roles they apply for, and demonstrated AI knowledge used both at work and privately .
Satya Nadella's "full-stack builders" signal. Aakash Gupta restores context to Nadella's quote that Microsoft merged PM, design, front-end, and back-end roles into "full-stack builders" (a change he called "the biggest change in knowledge work since PCs") . The quote came in response to how Microsoft added $90B to the top line and doubled income with flat headcount , and referred specifically to LinkedIn's APM-to-APB program, not a company-wide merger; Nadella also described a two-person model pairing a full-stack builder/PM with a systems engineer . The deeper signal for PMs: Nadella said "to build an AI product today, it starts with evals. Evals are done by product managers," and that "there's a new loop, and you have to structurally change" . Takeaways: adopt builder skills, learn what makes building AI different, and ramp hard on the evals skill .
- Hiten Shah argues where an AI agent lives matters more than expected: Slack works well because the agent can sit alongside the people, conversations, and work it needs to help with; the same applies to iMessage, Telegram, Discord, docs, and eventually every place work happens .
- He evaluates agents with five questions — Can I reach it where I already work? Can it get the context it needs? Can it use the tools required to finish the job? Can I control what it has access to and where it runs? Can it keep working without me constantly babysitting it? — and says these answers predict whether an agent sticks in his actual workflow .
- On Notion, he argues the product "breaks or seemingly optimizes for Notion over the user's experience" (drawing on his history with docs/notes apps since Writely, Hackpad, and Dropbox Paper); he cites small "paper cuts" like unreliable content export when printing a Chrome page to PDF, and concludes "all ouchies count" .
- Tech PMM hiring (Aug 2026) is an employer's market: companies are hyper-selective, hold out for exact domain/technology-category or persona expertise, and want every box checked—even 10/10 candidates get rejected; smaller-company processes are chaotic and bigger firms rigid .
- Hiring is indecisive and opaque: roles put on hold after final interviews, companies decide they wanted a content person instead of a PMM, hiring freezes hit after seven interview rounds, recruiters ghost candidates 1–3 weeks then resume, and ghost/fake job postings are suspected .
- Recruiters penalize candidates for market-driven career patterns: 3 employers in 5 years (startups that failed to weather high interest rates/AI competition) triggers demands for explanations; 2-month gaps are treated like 2 years; recruiters ask whether the candidate even had a chance to use AI after being laid off .
- Domain expertise is now a hard filter: PMMs report losing to candidates with 'actual market experience' despite applying below their experience level; the counter-argument is that learning the customer is the job and B2B enterprise/partner skills should matter more .
- AI fluency is a differentiator: employers ask for AI case studies; candidates build vibe-coded websites and agent/API dashboards and talk through what they automated in their job search vs. human-in-the-loop to show appetite and curiosity; interviewers screen for interest and aptitude, and a POV on AI in PMM matters. One PMM cites cutting market research from 2–3 weeks to 3 days but still getting rejected for missing domain experience .
- Location bias is strong: being in SF or listing 'SF' on the resume helps; advice is to say only 'SF' with no town/address, be vague about where you live, and commit to in-office days; one candidate was excluded purely for not being in the city .
- Search timelines are long—one report puts the average at 6–9 months—and the market is unstable, though PMM is seen as more important than ever when companies ship fast .
Zach Lloyd argues the goal of AI tooling should be automation, not interaction: users want work automated rather than more conversations or constant guidance . Hiten Shah pushes back: the likely mode is interaction leading to automation, with visibility and optional control later, most commonly in chat format (voice still counts as chat); he doesn't see Grok Bot, Claude Tag, and Devin as similar products but puts them in the same category, and prefers chat as low-friction while noting his own agents are not tied to a single model or tool set .
Hiten Shah critiques Notion for breaking core product principles by seemingly optimizing for Notion over the user's experience ; he cites inconsistent Chrome print-to-PDF output and export friction as recurring issues, and argues "all ouchies count" — even edge cases — against a product .
Shreyas Doshi released a new video on why some PMs' careers skyrocket while others get stuck, aimed at two groups: senior ICs aiming for more scope & impact, and GPMs/Directors aiming for VP/CPO roles; it also covers skills needed to get unstuck . Video: https://youtu.be/szldFUqpReo.
In an a16z conversation, Uber founder Travis Kalanick — now building Adams, an industrial-AI company spanning food, mining, and transport — shared lessons with PM relevance:
- Decision culture: his principle, at Uber "meritocracy / toe-stepping," now rebranded at Adams as "best idea wins" — team members must fight for the best idea even at the cost of upsetting people, or they settle for the mediocre, politically expedient idea . Ben Horowitz compared it to Andy Grove's "constructive confrontation" at Intel — "the only way to get better" .
- Craft compounds: strategy writing gets dramatically faster with experience — an Adams vision note that would have taken "hundreds of hours" 10–15 years ago "just flowed" in about 45 minutes, and tasks that once took days now take roughly 45 minutes .
- Change and trust: Kalanick's Uber lesson was that delivering rapid change without bringing trust along puts you too close to the line; he now deliberately stays "a few inches off that line" . Horowitz adds that a leader's extreme framing is dangerous at scale, since people eight levels down interpret it — leaders must stay far from the line .
- Complacency warning: "when it gets easy it's time to push hard" — ease tends to precede getting "whooped," or it means you're winning but taking it easy and about to start losing .
- Stealth launch playbook: Adams ran a deliberate, high-fidelity "how to not get attention" playbook for years, including barring thousands of employees from listing the company on LinkedIn .
- Motivation: revenge and spite (after being sued by 33 media companies) and fear of failure ("long nights where you get little done") are inferior fuel to falling in love again with the problem, which enables better creation .
On Aug 15, 2026, @hnshah criticized a Notion dialog as one of the most annoying he hits: it's a dead end yet tells him there's an out without leading to it, eroding his trust so much he'd rather use doc.new and paste instead . In a reply, he specified that Notion even shows his content then erases it before the dialog pops up; though he loves the formatting more than other products, the friction is too much for the payoff . This highlights how dead-end UI messaging and unnecessary friction in UX can damage user trust and drive users to simpler alternatives.
When choosing between problem-first and technology-first approaches for building a venture, the thread's strongest advice is to optimize for neither: work in an economically important domain with freedom to explore. Pure problem-first "risks trying to force physics to solve a market need"; pure technology-first "risks producing great science that nobody needs." The recommended synthesis: be "problem-aware, technology-open," since the biggest value of that formation period is developing an unfair technical advantage while learning what actually scales technically and economically .
The underlying trade-off: a technology-first path means mastering one technology and applying it across industries, while a problem-first path means developing multiple solutions within one problem space, specializing in the sector rather than in deep technology — with the commenter leaning technology-first for a hard-tech founder . Counterpoint: without a concrete vision for creating value, problem-first environments give a clearer path to a commercial solution, while technology-first environments make it "very easy to get stuck in research land forever without an aspirational end state" .
The originating question frames the conflict for hard-tech founders choosing between problem-first labs (e.g., Yet-Ming Chiang's MIT lab) and technology-first academic labs where commercialization "happens largely by chance": successful entrepreneurs give conflicting advice — work backwards from a problem vs start companies only after a breakthrough reveals a commercial application .
Hiten Shah (@hnshah) argues that when AI lets everyone build, the new competitive advantages are distribution, judgement, and taste — in that order (distribution first, then judgement, then taste). This responds to the question "If everyone can build with AI, what becomes the new competitive advantage?"
A tension-based approach to prioritization argues that teams prioritize more effectively by focusing on recurring tensions rather than the specific items being prioritized — the tensions point to the real decisions, where the same arguments keep surfacing, conviction fails, and momentum wins despite better judgment . It distinguishes prioritization judgement (what deserves attention) from prioritization-as-enacted (what actually moves work); retros never critique the framework — only how people rationalized, communicated, and showed up . The missing element isn't belief but commitment under present-day inconvenience; priority problems often involve intangible existential threats nobody can mobilize around, or 'fun' priorities with no guardrails consuming everything . Common tension patterns: default-yes areas where prioritizing individual items costs more than just doing them; efforts needing a big reset (the reset IS the priority); almost-done work needing one concentrated push; priorities boomeranging for lack of data; early-stage efforts needing protection without a free pass; capability gaps; credible paths to radically less scope (80/20) worth testing; false urgency windows; and indirect-value efforts (making a dozen things faster/cheaper) that lose because they're less sexy — a crisis of the commons . These polarities must be managed as a portfolio across time, value, and urgency — it's tension management, not rational math . Implementation: before using any prioritization framework, run the 12 fill-in-the-blank prompts with the team to surface these tensions — e.g., 'We keep coming back to but no one has a clear solution...' , 'No one debates that is important, and that is part of the problem...' , 'Unless we agree to do __ in principle, we'll keep wasting time trying to prioritize each little piece' — the prompts force the real questions and decisions on the table before any framework .
Hiten Shah announced a live 'evals-101' session (10 AM PT) on evaluating AI tasks. Participants are asked to bring one AI task they care about improving; the session covers how to choose the right examples, define what good looks like, and test whether the next version got better . Session link: https://www.hiten.com/evals-101.
- A laid-off junior PM/ops candidate reports five or six final-round rejections over three months of recruiting: they pass technicals and feel hiring-manager conversations go well, but receive no feedback to identify the blocker; each cycle spans 4-6 rounds and up to a month .
- Commenters attribute post-final-round rejections mostly to invisible factors — culture fit, internal candidates, hiring freezes, comp mismatch — and one points to interviewer "vibe check"/culture-fit preferences, including obvious gatekeeping .
- Tactical advice: record mock interviews with real PMs to surface what goes wrong; the junior PM market is currently "dumb hard" — the original poster adds they landed more offers as an intern, underscoring how much the entry-level market has tightened .
First-time PM/PO agency manager was fired after 2 months despite the team delivering results and a happy client ; a planned 30-minute feedback meeting became a 2-hour rant plus an A4-page rebuttal , and the CEO later said 90% of the work was good, with the main gap being how he gives and receives feedback .
Management lesson: a manager's role is to create conditions that bring out the best in the team, not to be the highest-performing contributor; complaints are requests for the manager to address something, and entering a role wanting to prove yourself rather than elevate others is incompatible with good management .
Politics and feedback handling matter as much as performance, especially in agency work; turning a 30-minute feedback session into a 2-hour rant would get most people fired, and reflecting and accepting responsibility is essential .
Job-search tactic: some candidates report getting calls only after rewording their resume for each job posting to match keyword filters, using a tool like jobowl.co .
TBM 436: Tension-Based Prioritization (A Non-Framework)
I’ve come to believe that teams can prioritize much more effectively by focusing less on the specific things they’re prioritizing (which will naturally be important, and will naturally get attention) and more on the tensions they’re observing and acting out day after day.
The tensions point the way to the real decisions. Most of what we call prioritization is forging agreeable narratives. It resolves very little and produces very little real commitment. But if you pay attention to where the same arguments/tensions keep surfacing, where conviction keeps failing, where momentum keeps winning despite everyone’s better judgment…that’s where you actually need to make the hard decisions.
There’s something Gestalt about this: you already perceive the whole shape of the problem. Your intuition is already doing that work. The framework just forces you to decompose it back into parts and lose the signal.
Later on in this post I share a simple, actionable exercise you can do with your team to surface these tensions. But before that, let me lay out my case.
If you like the newsletter, consider…
No One Retros The Framework. Why?
There are two parts to prioritization:
- Prioritization judgement. What deserves attention and investment?
And then:
- Prioritization-as-enacted
What would actually cause things to move in alignment with those priorities.
A lot of teams use prioritization to AVOID what is sitting right in front of their face. Instead of having the harder discussions, they slip into perpetuating the same old fake rigor and safe decisions.
I rarely, rarely talk to teams and hear “Oh well, during that prioritization exercise three quarters ago we really dropped the ball on prioritizing that because it was 3 not a 4.” Or “Woah boy, we really should have allocated 60% of our time there instead of 41.23% based on the CoD calcuation.”
I almost always hear something like “We just didn’t have the conviction to stop _______.” Or “We just kept plodding away on [something decided on two quarters before that] and everyone knew that was wrong.” Or “You had 20 teams saying they were slowed down by X, and we still didn’t have the political will to prioritize that measly platform investment.” Or “Let’s admit we were wrong about [that thing] and move on.”
The conversation in the retro is never about the framework. And always about how people rationalized, communicated, showed up, and made sense of things together.
Teams will spend hours/days/weeks trying to invent some sort of “defensible” system, when massive asymmetries and “problems to prioritize fixing” are sitting beneath their noses.
You don’t need more options! Or more spreadsheets!
The example I use is how as individuals we’re often swimming in the things we should be doing, the self-care we should be performing, the nagging tasks holding us back, and the big threats looming on the horizon that we can’t quite mobilize or motivate to tackle. Sitting down with a spreadsheet and trying to “reason things out” doesn’t solve the problem. The same with teams.
Most prioritization discussions obsess over prioritization judgement. But it is the recurring argument around prioritization-as-enacted that can be incredibly informative.
Instead of:
“Let’s prioritize again”
You instead should ask:
“Why has our existing prioritization process repeatedly produced this particular tension?”
Theoretical vs. Enacted Prioritization
The missing thing isn’t belief. It is commitment under present-day inconvenience. Good prioritization isn’t simply choosing the right work. It is recognizing the traps and tensions that prevent your portfolio of bets from panning out the way everyone claims it should.
I can’t count how many times I’ve been in a room where there seems to be a lot of agreement about some far-off threat—something we should do, something existential even, but not immediately existential. But for various reasons, despite the “priority”, the team can’t mobilize any sort of conviction. Maybe it will involve too many teams. Maybe there is currently “no clear owner”. Maybe there are differing opinions on how much energy to commit based on perceived levels of problem and solution certainty.
A lot of time, the key problem is that the problem is intangible. It is a future threat that people find all sorts of ways to rationalize will somehow work itself out. Every pre-mortem singles out the threat, and every quarter there are half-hearted efforts to take it seriously, but nothing happens.
When their guard is down, I’ll ask about some sort of existential threat looming on the horizon. There’s rarely disagreement about what that thing is. It doesn’t need to be rationalized. If there is disagreement, it is between markedly different futures with existential issues, or a comparison of existential problems (we need to live to even worry about that). Or magnitudes of disruption. The problem is imagining what action right now might look like. It isn’t some sort of rational, measured, economics-informed debate.
Is this a prioritization problem?
Well, yes, in many ways it is. But it isn’t the kind of rational pros vs. cons, risk, upside, effort conversation that people normally associate with prioritization.
Similarly, I can’t think of any work situation I’ve been in where there isn’t a priority people love to work on. The value is tangible. No one questions it. It is fun. It feels meaningful, at least on the surface. Saying yes has become a well-worn, habitual knee-jerk reaction, and no one is really complaining. In a meeting, trying to defend your value? Mention this priority. But there’s also a widespread intuition that it might be too much and that it is getting in the way of something far less comfortable, and maybe way less easy to rationalize. There aren’t enough guardrails. You’re running a very serious risk of exploring the wrong side of the effort/outcomes curve. No one wants to be the person to say “we can have a bit too much of a good thing”, but you really need someone to say that.
Is this a prioritization problem?
Again, yes. But because the work is happening right now, and because teams have a tendency of avoiding discussing the priority of “work in flight” (and because people get used to fun things that feel even a bit meaningful), you’re starting to drift from a standard prioritization motion.
Tension Patterns
Those are two motions. Here are some others:
Areas where you need to pass along a “default yes” because prioritizing all the individual items will not result in anything getting prioritized (the meetings are more expensive than just cranking)
Areas with a ton of inertia where someone needs to call a big reset to save the effort. The reset IS the item to be prioritized
Efforts that have been almost-done forever and just need one concentrated push to finish (different from the reset because you know the direction is right, you just need to stop tip-toeing around the close)
Priorities that keep boomeranging because there is insufficient data/discovery, so people keep saying “when we have more data”
Early-stage efforts that need care and room to grow, but not a free pass. The big decision is to really commit to planting the seed, and caring for it (without falling into “innovation lab” or “hire to get anything done” syndromes)
Effort blocked because you don’t have the “capability” yet. The big decision is whether to (and how to) build those chops
Important efforts where there’s a credible path to radically less scope that still captures most of the value (this is more of a lens, it can apply to almost any of the above)
Priorities that feel urgent because “the window is closing.” But is the window real?
Modest-looking efforts whose real value is indirect: they make a dozen other things faster or better. On paper they should win every conversation, but they get bogged down because the priority is less sexy, and everyone wants the benefits without funding/helping that shared capability (crisis of the commons)
There’s a polarity between many of these. You can’t do everything at once. You can’t cap the comfortable thing AND do the consolidated push AND plant the seedling AND fund the capability gap all in the same quarter. You keep a tight portfolio of risk profiles across time, value, and urgency. But it is not nearly as mathematical or rational as we think. It is more like managing tensions: knowing which ones to hold, which ones to release, and which ones you’ve been avoiding.
My theory is that even when we try, we’re not doing any sort of “rational” prioritization. But instead of fighting that, you can actually use prioritization tensions as a signal on the way to a more balanced portfolio of bets.
Conventional discussions of prioritization assume something like: “We have several plausible things we could do. Let’s compare value, risk, effort, confidence, etc. and decide which ones to invest in.”
But in my experience, the real problem starts AFTER that. We often know what we should do — that isn’t the problem. We know what the existential threats are. We already know we’re overinvesting in some things. We already sense which projects need a reset. What we’re struggling with, or don’t have the conviction to do, is how to create the organizational conditions required to act on that knowledge.

Meanwhile, you’re currently doing a lot of things you should either not be doing, should spend more time on, or should radically change your approach. The challenge is two-part: yes, you need to be considering the right or less wrong options, but it is also HOW you approach those things.
Exercise
Try this with your team. Fill in the blanks. If you can’t fill one in, skip it.
“We keep coming back to _______, but no one has a clear solution. And we seem unwilling to jump headlong into it. Every pre-mortem singles it out. Every quarter there are half-hearted efforts. But the threat is just abstract enough that there’s always a plausible story for why it might _______. We keep pushing it off to _______ and hoping that’s enough.”
“No one debates that _______ is important, and that is part of the problem. It’s fun. It feels productive. Saying yes is a well-worn habit. But unless we set limits, we’ll keep polishing it forever, well past the point of diminishing returns, while _______ starves. We’ve probably already captured _______% of the value.”
“Unless we agree to do _______ in principle, we’ll keep wasting time trying to prioritize each and every little piece of it. No single item is big enough to survive a prioritization meeting. But collectively? People should just be able to pull from this pile whenever _______. The value comes from doing it in _______, not batching it into some giant future initiative.”
“Everyone in the room knows something is off with _______. Confidence has dropped since _______. But the momentum is crazy. Ask a question, you get shot down. Nobody wants to be the person who held up the train. What we actually need to prioritize is permission to _______ it.”
“_______ has been almost done since _______. Everyone is tired of it. We keep giving it scraps of attention, and it keeps lingering. _______ stays blocked waiting on it. We need a short-lived period of extreme focus, or we need to stop pretending. That means explicitly saying _______ slows down for a bit.”
“We keep discussing _______ but never actually learn anything new. Someone is always ‘doing discovery’ on it amidst _______ other things, but nothing real emerges. We need to spend real, concentrated capacity resolving _______ before we can move.”
“_______ needs room to grow. We can’t judge it by the same standards as _______. We need to protect it and give the team leeway, but also hold them accountable for _______. The question isn’t ‘Is this paying off yet?’ It’s ‘Is this developing in a healthy direction?’”
“We keep calling _______ important, but no one will fund it, stop _______ for it, or hire against it. Is it important enough to displace _______? Important enough to add capacity for? Or neither? We either invest or say no.”
“What’s really stopping us on _______ isn’t the work itself. It’s the investment to be able to do it. We keep wishing we had _______, but we haven’t prioritized building that muscle. We have to prioritize our ability to do this, not just doing it.”
“The scope on _______ is huge. But there’s a credible path to radically less scope that still captures most of the value. What if we just did _______? There’s an 80/20 here if we’re willing to seriously test _______ before committing to the full thing.”
“_______ feels urgent because _______. But is that window actually real? What specifically changes if we wait until _______? Sometimes the answer validates the urgency. Sometimes it exposes something people just want to do now.”
“On paper, _______ looks like just another effort. But if you consider everything that would benefit, it’s critical. _______ gets faster. _______ gets cheaper. Unless you explicitly account for what it multiplies, it will always lose the prioritization conversation.”
Each one of these mad libs is designed to surface a tension, and a potential prioritization decision. Use them before you use whatever framework you had in mind to get the real questions and decisions on the table.
These are the real tensions to resolve.
A tension-based approach to prioritization argues that teams prioritize more effectively by focusing on recurring tensions rather than the specific items being prioritized — the tensions point to the real decisions, where the same arguments keep surfacing, conviction fails, and momentum wins despite better judgment . It distinguishes prioritization judgement (what deserves attention) from prioritization-as-enacted (what actually moves work); retros never critique the framework — only how people rationalized, communicated, and showed up . The missing element isn't belief but commitment under present-day inconvenience; priority problems often involve intangible existential threats nobody can mobilize around, or 'fun' priorities with no guardrails consuming everything . Common tension patterns: default-yes areas where prioritizing individual items costs more than just doing them; efforts needing a big reset (the reset IS the priority); almost-done work needing one concentrated push; priorities boomeranging for lack of data; early-stage efforts needing protection without a free pass; capability gaps; credible paths to radically less scope (80/20) worth testing; false urgency windows; and indirect-value efforts (making a dozen things faster/cheaper) that lose because they're less sexy — a crisis of the commons . These polarities must be managed as a portfolio across time, value, and urgency — it's tension management, not rational math . Implementation: before using any prioritization framework, run the 12 fill-in-the-blank prompts with the team to surface these tensions — e.g., 'We keep coming back to but no one has a clear solution...' , 'No one debates that is important, and that is part of the problem...' , 'Unless we agree to do __ in principle, we'll keep wasting time trying to prioritize each little piece' — the prompts force the real questions and decisions on the table before any framework .