We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI adoption should be outcome-led, not mandated. Top-down “AI-first” directives tend to become licenses, trainings, and “AI” on the roadmap, optimizing for appearances rather than relief. A better sequence is to automate a hated chore, then a small, recurring, unloved team process with a clear trigger. Measure hours reclaimed, issues caught, or response time—not AI usage or token volume—and publish failures alongside wins. For PMs, the first transformation bet should be one workflow with a baseline and outcome owner, not a usage KPI.
The bottleneck moves from making to deciding. The same playbook describes AI shifting constraints toward senior decision-makers and approval layers. Trace work from request to result, separate doing time from waiting time, and mark handoffs; then codify common cases, name the decision owner, or remove gates so authority moves closer to the work. Faster output without faster choices simply builds a queue.
Tactical Playbook
Use “Fire, Ready, Aim” for cheap uncertainty—and add the eval before scaling. When an artifact is cheaper to produce than the knowledge needed to specify it, and the decision is reversible, build a bounded prototype first. Keep its blast radius small and information radius large; inspect what it teaches, define the evidence needed to trust it, and commit when conviction is earned. Use more preparation for costly, hard-to-reverse choices, and establish measurement before an A/B test.
Operationalize that loop by mapping the trigger, inputs, repeatable steps, judgment points, output, quality test, reversibility, and outcome owner. Start with frequent, repeatable, easy-to-verify work; test routine, edge, and known-failure cases, set pass criteria first, rerun after changes, and log misses. Measure speed as the time from important uncertainty to a trustworthy change in belief—not the number of prototypes produced.
Case Studies & Lessons
A no-PM experiment separated signal collection from prioritization. In one startup, three engineers and a marketer split the PM role while 20-odd engineers adopted Claude Code. An in-app feedback loop and session-error flags made problems visible and enabled same-day fixes, but four people produced “four good lists, not one ordered list.” After four months, the company rehired a PM to decide what mattered and challenge assumptions, while leaving distributed ownership unresolved. Let teams own instrumentation and local fixes; keep a named owner for cross-product trade-offs.
Superhuman used research to reset mobile’s interaction model. Because mobile had not reached the bar of its web and desktop apps, the team spoke with thousands of users and redesigned around discoverability and speed: persistent bottom navigation, one writing flow for new mail and replies, surfaced actions, clearer comments, and faster AI- and voice-writing. Early reactions described a usability leap, but the announcement reports qualitative feedback rather than a quantified outcome; next steps are a faster search engine, more context for Auto Drafts, and hands-free voice.
Career Corner
Progression is a change in decision scope, not title. One framework moves from feature shipper (reliable launches) to metric owner (kill work that does not move the number), system thinker (trade-offs and direction), multiplier (results through PMs), and org leader (portfolio and business metrics). It summarizes the climb as features → metrics → strategy → teams → business and execution → judgment → scope → vision. Make the next promotion case with evidence of the next scope—outcome ownership, cross-team decisions, or team leverage—not a longer feature list.
Tools & Resources
Pattern of Pain is a lightweight discovery aid: give it a product website and it searches public customer evidence for independently recurring struggles, who experiences them, how they respond, and where evidence is thin. In a self-test it compared reliability and usage pains and reported seven versus eight independent origins. Use it to generate interview and prioritization hypotheses, not to replace direct customer research.
- AI-agent design workflow: AI product design can follow a Double Diamond-inspired Discover–Define–Deliver process: explore varied directions with bold briefs, establish an individual design identity by pushing beyond familiar patterns and chaining models, then polish rough edges and focus on essential elements. The described experience reports that agents can complete in hours work that previously took a team weeks, while human judgment remains necessary to ensure the result makes sense, flows well, and serves users.
- Discover broadly before going deep: A generic “make it unique” prompt still produces familiar layouts and styles, so inject variety externally by having the model generate a long random alphanumeric string with a shell script, derive the creative direction from its subpatterns, and then realize it with judgment. A complementary ideation loop is to request many shallow concepts, visualize favorites, record personal reactions and constraints, iterate with AI, and only then ask it to write a concise prompt for an initial proof of concept.
- Define through independent critique: Have the implementer capture a screenshot and invoke a separate critic in a fresh context with only the screenshot; ask it to assess the intended aesthetic, compare the work with a top design studio’s quality bar, identify the largest gaps, and score it out of 10. Use concrete evaluation criteria and reference examples, check after one or two iterations that the loop is converging, and use a stronger model for critique while a capable smaller model handles implementation; in the cited example, the critic used less than 10% of output tokens.
- Deliver through restraint and richer media: Polish by removing elements that add no value—extra labels, glows, gradients, random highlights, and custom controls that look worse than native components—rather than continually adding more. Image generation can add personality beyond code-based shapes and gradients, while video models can interpolate between product stills to create transitions triggered by navigation or scrubbed through scrolling or swiping.
- Design motivation as a three-part problem. Sustained motivation requires knowing what to do, why it matters, and believing in either one’s own ability or a leader’s commitment; without that belief, people eventually quit. For PMs, apply this to adoption and team-change initiatives by making the action, purpose, and confidence/trust mechanism explicit.
- Audit assumptions when a goal or decision feels stuck. Eyal’s belief-audit method identifies the underlying belief or excuse, then asks: “Is it true?”, “Is it absolutely true?”, “Who do I become when I hold on to this belief?”, and “Who would I be without this belief?” The subsequent “turnaround” tests whether the opposite could also be true—including whether one’s own expectations contribute—and treats beliefs as revisable tools rather than fixed truths. PMs can use this to pressure-test product, market, and execution assumptions before committing.
- Use mental contrasting instead of success-only visualization. Eyal describes research in which students who visualized earning an A studied less and received worse grades; the alternative is to visualize the desired outcome alongside the obstacles and the response required when difficulty arrives. For launch or roadmap planning, define the goal, identify likely obstacles, and rehearse a calm step-by-step response or checklist—the pattern he attributes to fighter pilots and athletes.
- Ethical habit-forming design: Use the Hook Model for products that need users to return consistently, while optimizing for improved user outcomes rather than addiction; Eyal defines addiction as compulsive dependency that harms the user, versus a habit as an impulse to act with little or no conscious thought. Implement the loop as: (1) an external trigger, eventually replaced by internal discomfort such as boredom, loneliness, fatigue, uncertainty, or anxiety; (2) the simplest action taken in anticipation of a reward, with mental, physical, and cost friction reduced; (3) a variable reward whose uncertainty increases response; and (4) an investment of data, skills, connections, or other stored value that makes the product better with use.
- AI-era personalization: The Hook Model’s four steps remain stable, but the rewards and products people use to satisfy their needs change over time. Eyal argues that AI makes mass customization economically feasible and will raise customer expectations for products that adapt to individual preferences; PMs should therefore treat user investment and accumulated context as inputs to increasingly personalized experiences.
- Diagnosing stalled adoption or behavior change: Sustained motivation is a triangle of behavior, benefit, and belief—not merely an incentive; when people know what to do but do not act, diagnose whether they doubt the benefit, doubt their ability to sustain the behavior, or lack the belief connecting the two.
- Time-boxed PM execution: Use a task list for capture, but move commitments to the calendar as implementation intentions—what will be done and when—because calendar constraints force explicit trade-offs. Define a fixed work period, protect it from distraction, and measure success by uninterrupted focus rather than by finishing the task; the output becomes a feedback loop for estimating how many additional time boxes are needed. PMs should also schedule reactive work such as email and Slack separately from protected reflective work such as planning, strategy, and thinking.
Four-month no-PM experiment. After the PM left, the startup split parts of the role across three engineers and one marketer while its 20-odd engineers adopted Claude Code and moved faster. The team built an in-app feedback loop that collected issues where things went wrong, used an LLM twice weekly, and posted key issues to Slack; broader team attention to feedback felt like an upgrade. It also flagged mid-session drop-offs and routed session links to feature owners, enabling same-day fixes; this workflow seemed to work better than the subsequent prioritization arrangement.
Where PM judgment remained essential. Better visibility produced “four good lists, not one ordered list,” leaving the founder to absorb context and decide what mattered across the next week and quarter—work that proved much harder than expected. Engineers’ direct exposure to user behavior did make changes easier to justify. After a PM was rehired, the role was redefined around deciding what matters and challenging assumptions rather than translating between engineering and users, while the team’s distributed ownership remained an unresolved design question.
Implications for PM practice. A long-time PM commenter characterized the experiment as replacing mainly the inbound portion of PM work; strategic gaps still include choosing target segments, users, and pain points, and estimating segment revenue. Another commenter argued that a few customer-office sessions can reveal more than prolonged error and ticket monitoring, and that surveys, interruption feedback, and session recordings are wants or hypotheses requiring verification rather than standalone discovery. The thread also flags guardrails for AI-assisted triage: define drop-off thresholds, evaluate and continually correct LLM categorization, and maintain an insight, experiment, and decision log. Session flags can also miss intent—for example, detecting a problem with task Y when the user is actually trying to accomplish X.
A practical division of responsibility is to have whoever launches a feature confirm whether it produced the desired effect and formulate a new hypothesis if it did not, while ensuring that someone defines and reviews adoption and benefit metrics across the product.
Julie Zhuo says many teams are approaching AI transformation poorly and has published a long-form account of lessons from her own experience and conversations with other leaders: https://lg.substack.com/p/you-cannot-mandate-an-ai-transformation
- The linked report’s headline thesis is that the PM role will be dead by 2030 . The thread challenges both its evidence and operating model: commenters call the chart’s y-axis questionable, reject the “12 builders, 1 product → 12 builders, 12 products” scenario as inaccurate or dystopian, and interpret the proposal as blending product, design, and engineering roles .
- AI can help PMs ship internal tools, but customer dependence and product quality remain constraints: one senior PM reports shipping internal apps that pass security and licensing scans, while describing AI-assisted engineer-built apps as poor in frontend and UX once real users depend on them . The same PM argues that durable product work includes facing customers, defending decisions to executives, managing trade-offs, and owning roadmaps, and expects roles to change rather than disappear . For AI-generated artifacts, commenters recommend a simple quality bar—whether the document could be sent to a colleague without editing—and warn that verbose requirements conveying little information are “AI slop” .
- Career positioning is unsettled. One commenter argues that moving from B2C growth to enterprise infrastructure requires deep persona, technical, and segment intuition; they define core PM value as making and communicating hard trade-offs and describe AI as a performance enhancer for a good PM . A former B2C growth PM leading enterprise infrastructure counters that a strong generalist can become a domain expert, transfer judgment across domains, and use AI to shorten build and user-feedback cycles . Another commenter recommends starting AI mastery now but warns that today’s techniques may expire as models gain more meta-work capabilities, while a counterpoint argues AI expertise may not provide a durable moat .
- AI-assisted design workflow: Lenny highlights the argument that LLMs tend toward predictable next-token outputs, while memorable design depends on unexpected choices. To push beyond generic AI output, use seed strings to inject variety, write more ambitious prompts, create positive-feedback loops with subagents, enrich concepts with image and video generation, remove low-value elements, eliminate recognizable “AI tells,” and rewrite copy by hand.
- Human–AI workflow: AI is most useful for well-scoped, execution-heavy work. In one mathematician’s workflow, it served as a faster research substitute for Google, enabled coding projects, and supported massively parallel exploration—such as working through a thousand examples or coordinating multiple subagents. When the models could not prove a lemma, human exploration of examples produced a better formulation, which the model then proved quickly.
- Keep discovery and judgment with humans: Current models are strong at applying known techniques and technical computation but weaker at intuition, big-picture understanding, and autonomous theory-building. They also struggle with global validation and subtle-error detection in long outputs; harnesses designed to elicit long or creative proofs can reduce reliability. For PM workflows, this supports using AI to expand and execute a well-framed problem while retaining human ownership of discovery, strategy, and final validation.
- Design for quality, learning, and diversity: Making work much cheaper can increase low-quality output without improving overall quality, so thoughtful usage and institutional incentive redesign are required. The source also warns that subordinating exploration to a model’s preferences could replicate one reasoning mode rather than preserve diverse human exploration, making broad participation and varied interests important.
- Use outcome-led AI adoption: Replace an “AI-first” mandate with a progression from automating a disliked chore to automating a small, low-stakes, unloved team process with clear triggers. Judge success by measurable outcomes—hours reclaimed, issues caught before release, or faster customer responses—not by AI usage or token volume; record the baseline, failures, and result so others can reuse the approach.
- Treat the workflow, not the job title, as the unit of product automation: For a candidate workflow, document its trigger and frequency, required information, repeatable steps, judgment points, outputs, quality test, error visibility/reversibility, and outcome owner; prioritize frequent, time-consuming, repeatable, easy-to-verify work. A weekly metrics-review agent can reconcile data, investigate an activation decline by product, geography, or channel, and leave humans to verify the analysis and decide what to do. Build evaluations alongside the workflow using known routine cases, edge cases, and failures; define pass criteria in advance, rerun tests after every change, pilot with human review, add misses to the test set, and assign an owner to monitor regressions.
- Redesign the product operating model when approvals become the bottleneck: Track work from request to result, separate doing time from waiting time, mark handoffs and approvals, identify the constraint, and move authority closer to the work where appropriate. One product organization replaced a central design-team gate with a self-serve experimental area where product teams could launch independently; losing experiments were retired and clear winners graduated into the core product, resulting in more independent team movement, fewer designer bottlenecks, and more experiments.
AI-assisted design: LLMs tend toward conventional outputs because they predict what typically comes next, while strong design often breaks rules and uses unexpected choices. The post recommends eight tactics for generating more creative work: use seed strings to add variety, write more ambitious prompts, create positive-feedback loops with subagents, enrich designs with image and video generation, remove low-value elements, eliminate AI tells, and rewrite copy by hand.
- AI-assisted design should not default to predictable, conventional outputs: the recommended approach is to deliberately push models toward unexpected, memorable choices because their next-token training can stifle creativity.
- For AI-assisted product and design exploration, the post recommends eight tactics: use seed strings to introduce variety, write more ambitious prompts, create feedback loops with subagents, enrich concepts with image and video generation, remove low-value elements and recognizable “AI tells,” and rewrite copy manually.
Zoom is heavily promoting its AI notetaker, and Shreyas Doshi is soliciting user feedback on their experience with it.
- Use “Fire, Ready, Aim” when the first attempt is cheap, reversible, and informative. Build a bounded, throwaway prototype before spending extensive time specifying requirements when producing the artifact is cheaper than acquiring the knowledge needed to specify it correctly; design for a small blast radius and large information radius, then commit once evidence earns conviction.
- Match product process to the cost of being wrong. Reversible product decisions should face a lower approval bar and can be tested early, while consequential or hard-to-reverse decisions require more preparation; A/B tests need a measurement system in place first.
- Treat validation and judgment as the bottleneck in AI-assisted product work. Cheap prototypes, code, and research increase the need for evaluations, measurement, and expert review to separate meaningful signal from random results; the useful speed metric is the time from an important uncertainty to a trustworthy change in belief, not the volume of experiments produced.
- Use “Fire, Ready, Aim” for low-cost, reversible product decisions: Build first when producing an artifact is cheaper than specifying it correctly; a working prototype makes debates concrete, exposes unnecessary features, and can reveal new ideas. Create a bounded prototype with a small blast radius and large information radius, then inspect the result, distinguish meaningful signal from noise, and define the evidence, evaluation, or measurement needed to trust it.
- Match the sequence to decision economics: Use more preparation for decisions that are costly, consequential, or difficult to reverse; A/B testing requires a measurement system before the test can teach much. Do not equate speed with producing more prototypes—the useful measure is the time from an important uncertainty to a trustworthy change in belief. Once evidence earns conviction, stop exploring and commit.
- Pattern of Pain is a product-discovery method that starts with only a product website, infers what the product does, searches public customer evidence, and identifies struggles that recur independently. For each repeated pain, it shows who experiences it, how they respond, and where the evidence remains thin.
- In a Grok Bot application, the method compared two pains with nearly equal evidence strength: reliability, where one stuck shared computer could take every Bot down, and usage, where users may think Bot usage is separate even as Cursor credits drain. It found seven independent origins for one pain and eight for the other.
Hiten Shah is testing Grok Bot by assigning it a new job each day, then plans to share the bots built, lessons learned, and how he decides which jobs are worth turning into bots at a Friday 10 AM PT session.
Hiten Shah’s When It Matters bot addresses the product problem of repeatedly checking information even when little has changed: users give it something to monitor, and it determines what would actually change the answer, watches connected context, and alerts them when a meaningful change occurs. Users can also ask it to identify overlooked follow-ups or questions worth monitoring across their connected context.
- Build durable workflow value rather than a thin model wrapper. The discussion argues that chat-based AI products are vulnerable as frontier models absorb their capabilities; stronger differentiation comes from proprietary or private data, domain-specific processing, hard integrations, and connectors to the customer’s ecosystem.
- Own the workflow around the model in high-consequence domains. In deep-domain B2B products, buyers may value the system of record, permissions, approvals, audit trails, and accountability around an AI step more than the model itself; AI features that only reduce typing are viewed as especially exposed to commoditization.
- Measure differentiation against the base model. A practical evaluation approach is to run the product and the raw model on the same tasks and measure the performance delta, but practitioners report that many B2B teams still rely on ad hoc checks of a few outputs because comprehensive eval suites take substantial time to build.
- PM and Product Owner titles have no universal contract: practitioners describe organizations where the PM does everything, the PO does everything, the roles are peers, or either role is senior; effectiveness depends on company culture and the product operating model. Evaluate the job description and actual scope rather than the title.
- A common split places the PM over strategy, roadmap, market/customer analysis, go-to-market, and customer or business outcomes, while the PO works within the engineering team on backlog ownership, stories, acceptance criteria, sprint scheduling, and task-level prioritization.
- Organizational scale affects the split: enterprise and multi-product organizations may use POs for execution while PMs manage leadership expectations, stakeholders, metrics, and strategic outcomes; lean startups and scaleups increasingly combine strategy and tactics in one PM to remove an extra communication layer.
- Platform PMs can be an exception to the usual model: one practitioner reports that their platform PM group drives major decisions for dependent products and has a go-to-market strategy even though the platform generates no direct revenue.
- One practitioner expects AI and agentic assistants to blur PM/PO boundaries and recommends a peer-level model in larger organizations, with roughly 20% tactical work for PMs and 20% strategic work for POs; their workload heuristic is one PM to three development teams, scaling to one PM, three POs, and nine development teams.
- Validate demand before the technology is complete: Hart established airline relationships before incorporation, secured letters of intent from SAS and other Nordic airlines despite having only a 3D-printed model, then used a working 400 kW motor to attract pre-orders—including from United—and further capital. The sequence turned increasingly tangible milestones into customer and investor validation.
- Choose a focused wedge and familiar product experience: Hart targeted short regional flights, where conventional jet technology is especially inefficient and half of global flights are under two hours, rather than competing first in the flying-taxi market. It intentionally made the aircraft resemble the turboprops it would replace instead of looking futuristic.
- Use risk-adjusted iteration to resolve hard product constraints: Battery-only flight would require carrying roughly two-thirds of the battery for diversion reserves, so Hart accepted about 20% higher upfront aircraft cost for a hybrid engine that supports up to 125 miles on battery and 500 miles in hybrid operation. The team’s stated risk philosophy is to minimize the impact of being wrong, enabling cheaper, easier iteration rather than waiting for complete certainty.
- Internalize work when it materially accelerates learning: Hart developed key components and processes in-house because traditional aerospace suppliers could take a year; it prioritized components reused across multiple aircraft systems and built the facility as an integrated test bench, including fault-injection testing.
