We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Woodward's playbook for Labs teams
On Lenny's Podcast, Google Labs VP Josh Woodward said good ideas "very rarely" come from design sprints. They tend to start as side projects by small groups of people who are obsessed with something . His team keeps a list of things that are "almost possible" and acts when one becomes possible. The technology still has to meet a real user problem, ideally one painful enough that people will pay .
- Early PMF signal. Watch people's eyes when you show them prototypes. Daily or monthly active users and day-7 retention don't help this early. Fall in love with the problem, not the product, because it often takes "three, four, five pivots" . Teams usually know a project is failing before their leaders do. He cited a Gemini PM who recommended not launching a feature after early data came back weak, and he thanked her publicly .
- Lab design. In large companies, labs usually fizzle within three to four years or never get their work commercialized . His advice: give the lab real independence, and decide up front whether its job is to graduate ideas into existing products or to create new categories . Zero-to-one work looks for those early reactions. Scaling from 10 to 100 means watching conversion funnels and cost per acquisition .
- Teams and pace. New Labs project teams have dropped from five to seven people to two or three . He still warns that the "everybody's a builder" idea is overhyped, because specialties matter. He tells new PMs to vibe-code "in service of becoming an exceptional extraordinary PM" . Planning runs on a rolling six months, and the best teams reach a meaningful milestone in 50–100 days .
Designing products for agents
Hiten Shah argues every product will get a second interface built for agents. Building one will become as normal as building a website or an API . Opendoor's Morgan Brown said the company recently made its home-selling and financing tools return JSON that agents can act on . Aakash Gupta makes a related point about building agents: Anthropic changed only the harness around the same model and moved its Terminal-Bench 2.0 score by up to 6 points. That is more than the gap between the top models .
AI PM pay and skills
Gupta cites Ankit Shukla's figures: AI PM roles pay 15–20% more than traditional PM roles in the US and Europe, and 30–50% more in India. The US median is $195K across 12,397 postings . Across 12,500 job descriptions, the top skill was choosing the right use case for AI. It ranked above RAG, agents and prompt engineering. In one example, Claude proposed a $420-a-month AWS stack, and two questions brought the shipped cost down to $110 .
Harder PM interviews
A laid-off PM with five-plus years of experience was rejected after a recruiter screen. The stated reasons were vague metrics and too little detail on customer research . Another commenter said recruiters now ask technical, product and behavioral questions, record the calls or use AI note-takers, and share the notes with hiring managers . One commenter's explanation: "Fewer open jobs, more people applying" . A practical tip from the thread: prepare short versions of each story covering the decision, your contribution and the result, then offer more detail . A candidate for Microsoft's CoreAI PM internship says one of three final rounds is "AI Fluency (Vibe Coding)." They understand it to involve building and testing an AI agent .
Wireframes versus AI prototypes
Practitioners describe building interactive prototypes in Claude Code from screenshots . Others use AI-generated HTML wireframes to compare options before building . The pushback: high-fidelity prototypes narrow exploration and make work look further along than it is. In one case, executives asked two months later why a product built from a Claude mockup hadn't sold yet, when it wasn't even half done . One commenter's advice is to make wireframes only as detailed as needed and treat them as a way to communicate, not a contract .
How AI is changing the PM job
A senior PM at a big tech company has used AI for over a year to write PRDs and do competitive research. They say AI can't get another team to deliver, so the role isn't going away soon . Another PM says AI makes them 10x faster, but they're now expected to work at "11x" . A third argues AI should improve discovery, not speed up feature-factory work .
Briefly
- Sachin Rekhi published an AI transformation playbook for product leaders. It covers building a "Compounding OS" so one person's AI gains spread to the whole team, an AI-fluency rubric, and rebuilding the product operating model from first principles instead of bolting AI onto the old one .
- John Cutler's TBM 444 warns about the "Case-by-Caser": a person who keeps demanding specific examples until a systemic problem shrinks to individual blame .
- On tracking competitors, one founder suggests logging only moves that would change your pricing, positioning, channel or roadmap decisions. They also suggest building your competitor list from your last ten lost deals .
- Source ideas at the frontier: Josh Woodward says strong ideas rarely come from scheduled design sprints; they often start as side projects among small, obsessive teams. Keep a list of what is “almost possible,” then connect newly feasible capabilities to a real user problem and people willing to pay.
- Validate before optimizing: Show people early prototypes and treat visible interest—eyes lighting up or leaning in—as an early product-market-fit signal, rather than relying on later-stage metrics such as D7 retention. Stay focused on the problem, not the first solution: several pivots may be needed.
- Make it safe to stop or pivot: Teams often recognize a failing idea before the leader does; fading passion and having tried the available approaches without success are warning signs. Leaders should make candid feedback safe, thank teams for raising concerns, and be ready to pivot.
- Design frontier teams to connect exploration with the business: A dedicated team can track and build with emerging technology, but it needs room to experiment and a bridge into the broader company; large-company labs can otherwise fizzle or fail to commercialize their work. Define whether the lab is meant to graduate work into existing products or create new categories, and distinguish zero-to-one exploration from later-stage scaling because they have different priorities.
- Plan in short cycles without losing exploration time: Woodward describes a rolling six-month horizon, with strong labs teams moving products meaningfully forward in roughly 50–100 days. Tie intense work to important launches or model releases, then reserve time after events for exploratory building and make the shift in pace explicit.
- Adapt team design without flattening expertise: Woodward values the ability to unlearn based on product tests, collaborate with both agents and people, and build trust. He says Labs project teams have shifted from five to seven people to two or three, sometimes four, while cautioning against treating everyone as a generic builder: preserve functional specialties and use prototyping to strengthen PM craft.
- Gemini product direction: Woodward said Gemini Spark already supports connecting personal data, and described an iteration toward a simpler single prompt box that acts on what users ask for, with a broader vision of Gemini as personal, proactive, and powerful.
- Find product ideas by staying at the technology frontier and tracking capabilities that are “almost possible”; promising concepts often emerge from small, obsessive groups’ side projects rather than scheduled design sprints. Pair newly feasible technology with a real user problem and people who would pay for the solution.
- For early product-market-fit signals, show prototypes to users and watch for eyes lighting up or people leaning in rather than relying on DAU, MAU, or D7 retention. Stay attached to the problem rather than the first solution: several pivots may be needed. Teams often recognize before leaders when an idea is not working, so create room to say so and pivot.
- Give frontier labs enough independence to let unusual ideas grow, while building bridges to the wider company; Woodward says corporate labs often become ineffective and fizzle after three to four years or fail to commercialize their work. Define whether the lab is meant to graduate ideas into existing products or create new categories. Use stage-specific goals: zero-to-one work looks for user reactions, while 10-to-100 work focuses more on conversion and CPAs.
- In AI-era teams, look for a high “unlearning rate” and the ability to build trust and collaborate with both agents and people. Cross-functional building does not make specialties obsolete; PMs should use prototyping to become better PMs, not abandon their core craft.
- Plan on a rolling six-month horizon; Woodward says strong Labs teams move from idea to a meaningful milestone in 50–100 days. Name intense work periods and preserve post-Google I/O exploration as seed-generating time, while pacing teams for the long term.
- AI-assisted prototyping is speeding up alternative generation: practitioners report making interactive prototypes from prompts and existing-app screenshots, producing multiple variants quickly, and using AI-generated HTML wireframes to compare UI options before building. One practitioner at a large organization says their UX teams have moved from wireframes to mid-fidelity prototypes.
- Wireframes can still provide a useful low-fidelity outline for communicating ideas and comparing approaches; keep them only as detailed as needed and treat them as communication tools, not build contracts.
- High-fidelity prototypes can narrow exploration or be mistaken for delivery progress: one commenter recounts executives asking why a prototype had not launched two months later, although the product was still less than halfway done.
During San Francisco Fleet Week traffic, Andrew Chen’s Waymo was blocked for 15 minutes and required human intervention to reroute; a 20-minute ride became a 50-minute detour, illustrating a user-facing reliability and recovery challenge in congested conditions.
- PM candidates in this thread report more detailed initial screening than they expected: the original poster was rejected after a Talent Acquisition screen for imprecise metrics and not explaining customer research in enough detail, despite expecting a high-level conversation; commenters described STAR-style, behavioral, product, or technical questions in recruiter screens, including a 45-minute behavioral interview.
- One candidate reported that recruiter interviews were recorded or had AI note-takers, with notes shared with the hiring manager; this is a report of note-taking, not evidence that AI evaluated candidates. A practical preparation tip from the thread: have compact examples ready that state the decision, your contribution, and the result, and offer further detail if requested.
- Some commenters attributed tougher screening to competition for roles: one cited a large pool of qualified applicants, while another summarized the dynamic as fewer openings and more applicants.
- Organizations can provide meaningful work, growth, belonging, and real relationships, but employment remains a conditional bargain shaped by high personal stakes, temporary relationships, unequal power, and the cost of leaving; unwritten employee expectations can make unmet assumptions feel like betrayal. Product leaders should distinguish meaningful work and care from promises of unconditional support.
- Asking for specific examples can help teams surface observations, but it can also become a “Case-by-Caser” tactic that reduces systemic problems to isolated incidents and puts the burden of proof on the reporter. For persistent problems, move from diverse concrete observations to shared sense-making, and consider what action can address the pattern rather than waiting for the person denying it to agree.
Companies should operate like labs teams, continually experimenting at the frontier because what is possible changes every few months. The discussion also covers how to recognize product-market fit early, track ideas that are “almost possible,” and establish internal labs teams.
Hiten Shah argues that products will need a second, agent-facing interface alongside their human-facing one: software must give agents enough product understanding to act and make outcomes clear, and he expects this to become as standard as building a website or API. Opendoor provides an example: it recently made its home-selling and financing tools return JSON that agents can act on to produce results for a real home; the team expects agents to choose tools that help complete the task.
- The subreddit’s lifecycle guide frames Discovery as researching users and markets, designing an initial UX, and working toward problem/solution fit and an MVP; Validation tests and refines a launched MVP toward product/market fit . It describes Efficiency as optimizing UX, performance, and operations for growth .
- day3 targets small software teams with email billed by sends rather than subscriber count, combining newsletters, product updates, and transactional email; it offers a REST API and MCP server while deliberately omitting A/B testing, drag-and-drop builders, and landing pages. Its founder says the product has early users and is refining its product and pricing page, with goals to increase product-update usage and test whether per-send pricing is clear .
- A commenter praised send-based pricing as an alternative to paying for inactive addresses, while asking whether mixing marketing and transactional mail on one domain could affect deliverability and what workflows the MCP integration supports; these were raised as questions, not reported outcomes .
A user reports that Google Maps mispronounces Hawaiian street names, citing Kaanapali as an example; this is a specific localization and product-quality gap.
- PMs recommend protecting work hours through explicit boundaries: decline meetings that add little value, block deep-work time, and log off consistently; one VP says they kept an 8:30–5:30 limit in a new role without a pay cut and explained the arrangement to executives .
- Workload varies even within regulated sectors: one commenter says regulated environments can slow the pace, while a bank tech PM describes a punishing 9–5 but shuts off afterward; an aerospace senior PM reports limiting work to 40 hours except for occasional time-zone needs or production incidents .
- A PM says that after surviving a layoff, they were given responsibilities previously spread across four roles plus another product line, with no change in pay or title, and ultimately quit for their sanity .
- A Principal technical PM reports using durable cloud-hosted agents to automate at least 10 recurring tasks, with the agents running continuously .
Hiten Shah says people may eventually question why spending so much time learning to use software was considered normal, highlighting the product-design value of reducing users’ learning burden.
-
Claude Code workflow for PMs: Keep product, market, and strategy context, writing styles, prior work, and meeting transcripts in a project knowledge base; put standing rules in
CLAUDE.mdand save recurring workflows such as meeting notes, competitive research, and PRD reviews as reusable skills. Start complex tasks in Plan Mode, use parallel agents for transcript analysis or specialist reviews of PRDs, and add these capabilities incrementally. - AI PM careers and compensation: The note reports AI PM pay premiums of 15–20% over traditional PM roles in the US and Europe and 30–50% in India; its US posting sample had a $195K median across 12,397 AI product postings, while India medians varied from ₹55L at AI-first companies to ₹35L at Series B+ startups and ₹26L at enterprise MNCs. Across 12,500 job descriptions, choosing the right AI use case ranked above RAG, agents, and prompt engineering; one example reduced a proposed AWS build from $420 to $110 monthly after two questions.
- Agent product design: Treat the harness—the system around the model—as a performance lever: the note says Anthropic changed only the harness and improved its Terminal-Bench 2.0 score by up to six points, more than the gap between top models on the leaderboard. The described agent-building toolkit includes tools, memory, permissions, checks, subagents, and a human-in-the-loop.
- A senior big-tech PM says they have used AI for at least a year to draft PRDs and epics and to support competitive research, prioritization, and strategy; they still see relationship-building and getting other teams to act as work AI does not handle, and expect the PM role to persist for years.
- One commenter argues PMs should use AI to improve discovery—asking better questions, synthesizing learning, prototyping assumptions, and pressure-testing ideas—rather than mainly accelerating PRD and backlog production.
- Another commenter describes a productivity squeeze: AI makes tasks much faster, but expectations to work even faster have made the experience chaotic.
Commenters recommend concise “did X by Y by Z” resume bullets at any career stage, with differentiation coming from evidence of ownership and how the work solves the hiring manager’s problem—not a universal template. They caution that generic metrics can make the format feel limiting; the choice of what to measure helps create the narrative.
One commenter advises assuming a recruiter has about 30 seconds and linking measurable outcomes to the work that produced them. Another recommends maintaining a detailed master CV and tailoring it to each role so recruiters can assess fit easily.
For people building a PM portfolio without PM experience, one suggested approach is to present one or two strong case studies covering the problem, solution, key decisions and trade-offs, and outcome (including metrics if available); alternatives include a product teardown, a feature PRD, or a small side project with a prototype .
An India-focused product manager with about four years of experience reported being laid off and receiving only 2–3 interviews in five months despite applying widely, including on LinkedIn, Instahyre, Naukri, and IIM Jobs; this is one job seeker’s experience, not a market-wide measure. A commenter recommended tailoring interview examples to each job description and emphasizing specific achievements and their impact, problem-solving, and leadership.
- The founder said they built an after-hours HVAC voice agent before validating the problem and then struggled to get conversations; their reported outreach included 60–80 social-media DMs with no replies. A commenter cautioned that this volume of unanswered DMs says little about market demand and reflects ineffective, spam-like outreach instead.
- For product discovery, commenters recommended replacing a demo or interview request with a specific, low-effort test: send a short recording or after-hours call and ask where a human would take over, or what the agent should do when it cannot judge urgency.
- One commenter warned that HVAC owners may not adopt a separate system just for after-hours calls; the agent would need to write into existing dispatch software such as ServiceTitan or Housecall Pro.
For KPI trees, drawing the tree is relatively easy; the harder work is using discovery to validate the model and make it impactful for product decisions. Suggested resources include Made to Measure KPIs and Teresa Torres’s Continuous Discovery Habits; the commenter also offered to organize an online meetup with practical examples.
- As AI and no-code tools make building easier, commenters argue that customer discovery, go-to-market, and distribution have become bigger bottlenecks; one says product quality is now table stakes and a distribution strategy should come before coding.
- A crowded category does not necessarily mean every niche is served: focus on a specific buyer, a painful daily workflow, and that buyer’s language; use targeted, context-rich outreach instead of generic mass marketing.
- Practical early-stage tactics include being useful in relevant communities while building, manually contacting a narrow set of prospects and taking calls before automating, and talking to users early to guide what to build.
TBM 444: What a Workplace Can’t Promise

In other posts, I’ve written about the distinction between “the work” and “the workplace.” I want to dig a little more into what makes workplaces unique.
It is not naïve to seek autonomy, mastery, and purpose at work. Given how much of our lives we spend working, it would be strange not to.
The seductive mistake, however, is to assume that companies function like families, guilds, unions, friendships, expeditions, sports teams, congregations, neighborhoods, or communities. Humans organize themselves in all sorts of interesting ways, each with its own purpose, expectations, obligations, and peculiarities.
Institutional theorists Roger Friedland and Robert Alford argued that different institutions have different “central logics.” A family, company, profession, and community may overlap, but they demands different things (from us), and make different promises in return.
Companies are unusual.
They can provide us with meaningful work, friendships, belonging, opportunities to grow, and, importantly, money to put food on the table. But they also combine several features that complicate our relationships within them.
Our livelihood, career, and reputation are at stake. So high stakes.
Relationships are temporary, uncertain, and often not of our choosing.
Power and influence (and protection) are unevenly distributed.
Performance and accountability are open to competing interpretations.
We can survive without resolving a conflict (e.g., “lay low” or “wait it out”).
What protects an individual may harm the team.
Leaving is possible, but rarely without cost.
This is why companies are not especially well suited to providing unconditional support, lasting membership, or the kind of mutual obligation and reciprocity we might reasonably expect from other relationships. When we imagine companies as families (or teams, pirate ships, professional communities, or congregations), we transpose expectations the institution simply cannot reliably fulfill.
Denise Rousseau calls this a psychological contract, which she defines as “an individual’s beliefs regarding the terms and conditions of a reciprocal exchange agreement.” Because the contract exists in the mind of the employee, it can feel binding even when unwritten or not shared by the organization. A breach can therefore feel like betrayal even when no formal promise was broken.
Well-meaning HR teams and leaders may work tirelessly to create environments of inclusion, engagement, belonging, and psychological safety. That work matters. It can make companies far more humane. The care and relationships can be real. But none of this makes the bargain unconditional. It remains shaped by economics, incentives, unequal power, and the ever-present possibility of exit. The more a company feels like a community, the easier it is to forget the limits of the institution underneath it.
There is a lot of talk about agency, and especially being “high agency.” That may help us improvise, and roll with the punches. But it does not magically change the calculus of company work. The imbalance of power and the cost of leaving remain. The relationship is still conditional.
We also place expectations on ourselves that we cannot reliably fulfill. We can come to see our inability to resolve contradictions built into the institution as a kind of self-betrayal. When the bargain breaks down, the sense of betrayal can turn inward as a kind of self-gaslighting. We beat ourselves up for “caring too much,” staying too long, failing to speak up, failing to leave.
This is where healthy ambivalence helps. We can let the work and the relationships matter without expecting the institution (and the humans representing the institution in various ways) to promise more than it can.
Simone de Beauvoir wrote about the ambiguity of being both free and constrained.
Let us try to assume our fundamental ambiguity. It is in the knowledge of the genuine conditions of our life that we must draw our strength to live and our reason for acting.
We can act, but we always do so within conditions we did not choose or control. Something similar is true here. Work can be genuinely meaningful, and the workplace can remain a conditional bargain. Neither cancels the other out.
Most of us will work for decades. Across that time, we may have several “work lives.” The work itself may follow different arcs and change as we do. We may spend only a few years at a particular workplace, or perhaps a decade. Keeping that difference in view creates a certain freedom, even some levity. A workplace can matter deeply without becoming the whole story. It is one place where the work happens for a while.
And some lighter material… after The Standard Setter (opens in new tab), I wanted to follow up with another curious character….
The Case-by-Caser
May I present to you: “The Case-by-Caser.” By repeatedly asking for specifics, they can make any problem not their fault, and any systemic issue magically disappear.
The tactic here is very simple. No matter the problem, keep pushing people to give “specific examples” until you’ve narrowed and flattened the thing down to something innocuous that can ideally be pinned on an individual, or a small group of individuals, or a concrete next step.
The Case-by-Caser makes it very clear that no systemic issues, or anything uncomfortable or messy, will be tolerated. The burden of proof falls completely on the reporter. Anything that doesn’t comport with some arbitrary (and safe) version of specificity will be summarily chastised and challenged.
The beauty of the CBC’s tactic is that, on the surface, specific observations are valuable (especially if you stick with observations and don’t label them). They are salient. They help people grapple with what they are experiencing. The right tactic is to surface broad/diverse observations, and then grapple with sense-making together. Act through “the problem.”
A problem that has stuck around is most certainly impervious to simply reporting a “specific example.” You have to foster a situation where the team can move beyond sweeping statements to something more “tangible,” but that isn’t a switch you just turn on/off.
So asking passes the sniff test.
With the CBC….
The problem is in the complete lack of coherence in their approach.
The definition of specific is completely arbitrary. When it comes to a vague strategy and someone calling that out, they are “uncomfortable with uncertainty!” “Why do you need all of these details?” Yet when it comes to a problem, somehow the tables are turned and you need to define the specifics. Strategy vibes are fine. Problem vibes are not fine.
Why is this effective? No one ever got fired for asking for specific examples. Plenty of people have gotten fired for trying to talk about systemic, messy problems.
So the CBC has a 100% self-sealing tactic. There’s a hard-to-parse undercurrent of fear and doubt. “What’s a specific example?” How do you answer that?
Whenever there’s a problem, the Case-by-Caser confidently points to the fact that they’ve addressed “all specific problems,” and they have a self-sealing argument to their boss.
Is there any way to beat the CBC at their own game? Probably not, especially if they have more positional power than you do. They can always ask for another example.
Stop trying to win the argument. Ask yourself what intervention you can actually make that has some chance of changing the system. You don’t necessarily need the CBC to agree with your diagnosis to start acting on what you’re seeing. Sometimes the most expensive mistake is believing you need permission from the person denying the pattern before you can do anything about the pattern.
- Organizations can provide meaningful work, growth, belonging, and real relationships, but employment remains a conditional bargain shaped by high personal stakes, temporary relationships, unequal power, and the cost of leaving; unwritten employee expectations can make unmet assumptions feel like betrayal. Product leaders should distinguish meaningful work and care from promises of unconditional support.
- Asking for specific examples can help teams surface observations, but it can also become a “Case-by-Caser” tactic that reduces systemic problems to isolated incidents and puts the burden of proof on the reporter. For persistent problems, move from diverse concrete observations to shared sense-making, and consider what action can address the pattern rather than waiting for the person denying it to agree.