We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI prototyping is becoming the PM’s first draft. Product Compass reports that Meta PMs now vibe-code prototypes for Zuckerberg and that product-sense interviews include a live prototyping round; a Productboard survey cited in the piece says 60% of enterprise product teams already use two AI tools for prototyping. The shift is from “complete spec” to context plus iteration: define users, problems, jobs-to-be-done, evidence, and out-of-scope in CLAUDE.md/AGENTS.md, ask the agent to propose the interface and alternatives, and ask up to five questions before it starts. Cheap, reversible ideas can be feature-flagged and measured in production, while high-risk or hard-to-reverse ideas still merit experiments. The PM edge is therefore the quality of the context and the judgment about what to learn, not prompt-to-screen speed.
Model choice is product design. A local-model essay argues that the right model is the one that clears the quality bar for a specific job: coding needs reasoning and context, while inline writing needs latency, voice, and timing. Local inference fits small, frequent, personal or offline work; cloud fits hard reasoning, shared work, and large context. Use that split as an architecture question before choosing a vendor or model.
Tactical Playbook
Find the automation boundary manually. A founder with roughly 10 prospective pilot users asked whether to run the process manually or build a light MVP. The advice: ask each person for one real case and a review date, run the first three manually, and only build the step that repeats across all three. For agentic workflows, this tests repeatable value before automating a whole system.
Treat AI-generated prototypes as real software. In the workshop, a Lovable CRM’s contacts policy was USING true, so any signed-in user could see the data; an outside attendee confirmed the exposure 62 seconds after the link was shared. The fix was per-user isolation, and the article’s rule is to inspect Cloud policies before publishing. Make data isolation a demo gate, not a post-launch cleanup.
Case Studies & Lessons
Owner’s pivot was an outcome redesign, not a chatbot add-on. At Pizza Expo, restaurant-owner enthusiasm for an AI concept contradicted the company’s earlier expert and discovery signal; Owner then changed onboarding so a restaurant name triggers web, competitor, Google-profile, review, and photo analysis, followed by a new site in under five minutes. Owner says more than 83% of new customers now start with Gradar, growth was faster in 2025 than 2024, and it is approaching $100M ARR. The lesson is to encode a best-practice path that drives an outcome: in agentic products, repeated manual logins are a failure signal, so low-touch success matters more than DAU.
Square stages delegation behind trust. William Ave describes the DRRI/DRI model as one empowered owner carrying a decision from ideation through go-to-market and scale, cutting silent vetoes and alignment problems. ManagerBot starts with ideas and rich artifacts such as menu engineering and labor forecasts; only after investigation and trust does the user delegate bulk actions such as campaigns or price changes. A reusable agent UX is: insight → artifact → reviewed action → delegated execution.
Career Corner
AI-first teams still need juniors, but managers must defend the learning loop. Opus 2’s CPTO says juniors are part of its diversity strategy and receive the same 30/60/90 onboarding and first-year value expectations as more senior hires. Managers are expected to spot LLM slop and make juniors present their own thinking, not just submit fast output. The team also compares AI adoption with PR size and DX/DORA scores, retaining small, well-planned customer value as the quality bar. For PMs, use AI but keep reasoning visible; for leaders, measure quality and learning alongside speed.
Tools & Resources
Lennybot is a focused retrieval tool for PM work. Lenny Rachitsky’s new Grok Bot is trained on 500+ podcast episodes and newsletter posts; prompts cover first 1,000 users, promotion, PM interviews, growth ideas, and hard feedback, via a custom MCP connector. Use it to generate starting hypotheses and questions, then validate them against current users and data.
William Ave, global head of product at Square , said Square/Block reorganized ~2 years ago from a business-unit/general-manager model to a fully functional org (product, design, engineering) with brand-based focus areas (Square, Cash App); the goal was functional excellence, and the guiding principle is to organize teams as close to customer outcomes as possible .
Under the Square brand, the product org splits into an audiences org (verticals: services, retail, food & bev), a core platform org that owns product surfaces to avoid one-size-fits-one solutions, a growth team, a money team (bill pay, payroll, banking), and sister hardware teams .
On hardware+software products: hardware must be approachable, easy to use, and delightful, and the software form factor must be married to the hardware form factor rather than treating them separately; commodity off-the-shelf hardware makes excellent experiences hard. Since timelines differ, success requires strong people, minimal red tape, and iterative learning loops in both hardware and software .
Block's DRRI/DRI model is meant for when products slow down because of decision-making, silent vetos, or lack of alignment: one empowered person owns a decision through the full product lifecycle (ideation -> go-to-market -> scale), synthesizing product, technology, and business, shaping technical strategy, and keeping teams accountable to execution .
On org design + AI: orgs historically existed for information flow; AI can encode knowledge in data/agents rather than org structure, democratizing decisions and enabling small autonomous teams. DRRI plus flatter orgs speed execution, but people managers remain necessary for career growth .
Square's SMB AI product, ManagerBot, reflects William's view that the standard Q&A chatbot era is over and AI should do 'real work': it is built as an intelligent thought partner, generates ideas (e.g., missing item descriptions), produces rich artifacts (menu engineering analysis, labor forecasts), and supports bulk actions/campaigns once trust is built. William argues it is easy to build a chatbot but hard to build a dependable agent, and AI experiences must avoid making customers do more work; users investigate first, then delegate tasks like inventory counts or price changes .
On TAM: "with the right team, the right idea, and the right learning loop, your TAM is almost infinite." Square's north star is the 'neighborhood network' - all economic action in local neighborhoods (owners, staff, customers) - which refocuses effort away from internet-only D2C and toward commerce, financial, and intelligence tools .
SMBs currently use fragmented point solutions; Square's strategy is strong first-party tools plus an open partner platform, and agentic AI that lets sellers work across multiple software products at once; AI software engineering has lowered the barrier to building across these areas .
William also described Block's Buzz collaboration platform, aimed at helping small businesses manage staff and inbound communication across fragmented channels (WhatsApp, Instagram, SMS, email), a problem he says no one has solved yet .
Real working hours for PMs vary widely by country, role, and company stage. European examples: Netherlands 7–9h/day average (5.5–11h outliers), excluding off-hours thinking time ; Denmark 33–40h/week ; UK ranges from ~35h for a 15-yr product director and ~6.5h/day actual for product leadership to 50–60h for a London head of product and 12–14h/day at a £100k fintech job the PM quit ; Ireland ~50h at a 25-person company ; Sweden 37–40h after kids vs 45–50h pre-kid ; Czech 30–35h (~40h in Q4) ; Germany healthtech 50h ; France ~7h/day or 45–50h/week with 35 holidays and €60k Paris ; Switzerland CPO ~10h/day . Outside Europe: Bay Area ~50h ; Australia 25–50h unofficial .
Workload is lumpy and stage-dependent: contractual 40h can mean 10h days or 2–3h days , and a Dutch startup PM says longer days are inevitable despite the 40h norm . One PM reports only 2–3h of 'real work' daily during execution vs 50+ hour weeks in planning ; on complex multi-team products, meetings and prep can leave as little as ~2h of deep focus . Seniority often reduces hours: a UK product director with 15 years works 35h and says longer hours don't make a difference , while an Irish head of product says impact can be massive in 30 hours and none in 60 . Another UK leader with 15 years worked 9–10h days early on and credits that for accumulated experience/efficiency ; a Swedish PM says the best PMs get away with ~35h as long as they deliver numbers . Tactics for managing the load: track hours and take equivalent time off rather than working unpaid overtime ; take unofficial Fridays off as long as expectations are met ; and one Dutch PM at a global company uses downtime for short days and stays late in crunch, saying pressure ebbs and flows and 'it all evens out' .
Live commerce: 30–40% of all commerce in China is live commerce, vs single digits in the US . Whatnot's co-founder expects the gap to close because live selling is more efficient for merchants — a shop can be set up for $0 with a global audience rather than an expensive physical storefront — and because live is demand-expansionary: buyers discover items they didn't know they wanted, growing the total market rather than just shifting e-commerce .
Product philosophy: Users don't care about the market category — only whether the experience is enjoyable and provides value; focusing on 'building a market' distracts from building a great user experience . The founders' unfamiliarity with the existing market was an advantage: knowing it well would have led to iterating on existing models rather than building something new .
Discovery-led engagement: Whatnot is positioned as browsing a store/mall — buyers start with loose intent, not a specific item . More than 80% of daily users don't purchase; they watch and chat, and users average 95 minutes/day . The co-founder contrasts this with e-commerce, where you must know exactly what you want and where discovery and entertainment are underserved .
Customer discovery and MVP: The Whatnot concept came from daily customer conversations while running a Funko Pop marketplace — customers were already hacking live video on social media to sell, but transactions, shipping, payments, discovery, and CX were broken . The first version was built in a few weeks and validated by going live and selling .
Trust and safety as product: Whatnot invests ~40% of headcount in trust and safety, with a 'measure everything' mandate . A rules engine ingests billions of data points in under 1 second to auto-warn/suspend/ban for LLM-detected harassment, late shipping, or high refund rates . The co-founder likens trust and safety to running the police force and legal system of a city of ~10–20 million people, and notes live video itself makes bad behavior harder to hide .
AI to amplify, not replace, human connection: AI is used to help sellers run more efficiently while keeping the experience human — LLM-inferred metadata for listings/live streams and analytics that tell sellers where their business is strong or weak . Avatar-based selling is rejected because the human connection is the reason buyers come back .
Category expansion: Whatnot sells in 100+ categories and uses the test that any category someone would build a retail shop around works — requiring explanation, personality, and story . Women's fashion is now its biggest category (heavy off-season inventory at deep discounts) ; golf is growing hundreds of percent YoY ; cars and liquor/beer/wine are planned next .
International expansion: Across 10 countries (US/Canada, five in Europe, Japan, Australia), the same dynamics recur — collectibles, fashion, and electronics sellers/buyers behave similarly — which the co-founder cites as evidence that live commerce is a durable shopping medium .
- Hiten Shah: judge models by the job, not by benchmarks. A local model is useful when it clears the quality bar for a specific job; coding needs exceptional reasoning and a large context window, while inline writing cares about latency, voice, and whether the completion appears at the right moment. The smartest available model and the most useful model for a product can be two different decisions.
- Local models crossed a practical threshold. Demos impressed until daily use exposed quality or latency problems, but capability jumps are now getting 'kind of ridiculous' — Qwen's 4B Qwen3 rivaling Qwen2.5 72B Instruct, Granite 4.1 8B matching prior 32B MoE, Google's 12B Gemma designed for 16GB laptops — and a surprising amount of useful intelligence fits on machines people already own.
- Once the model clears the bar, the experience is the product. In his local writing product, tiny product decisions (where suggestions appear, how much they write, whether they can be ignored or steered without breaking flow, native feel) determined whether it felt impressive or like something to leave running all day; speed, context, control, and native integration mattered. The question shifts from can the model do the job to did we build the experience around it well enough.
- Remaining failures are product problems, not model problems. Fast but feels off, missing what you meant, getting in your way, or bad defaults can be observed, tuned, and tested by putting software in front of people; that is why he stopped waiting for another model release.
- Local AI unlocks work below the threshold of asking. Finishing six words in an email, extracting one fact, classifying a file when it appears, or quietly keeping an index current are not worth opening a chatbot; local models let software afford to care about these small jobs, so intelligence can disappear into the product — writing help inside the sentence, a notes app understanding while you write.
- Place intelligence deliberately between local and cloud. Local fits small, frequent, personal work (writing, personal files, half-formed ideas) with low latency, offline operation, and no API decision per small operation; hardest reasoning, shared work, and large-context collaboration belong in the cloud. Great AI products will use both and get increasingly good at deciding where each piece belongs — and the best local AI products will make the architecture boring: users care that the assistant feels instant, works on a plane, keeps personal context close, and avoids another subscription.
-
Opus 2 CPTO Tiana (legal-tech) says product management doesn't require an engineering background; effectiveness comes from curiosity about user problems, scalable solutions, and commercial acumen (e.g., gross margin). As a non-engineer, she treats engineers as subject-matter experts, asks
five Ws, and ties work back to business model/KPIs. -
AI speeds work but risks burnout from
token maxing; leaders should model taking breaks and use AI to free humans for uniquely human tasks, with guardrails on quality. -
Opus 2 tracks AI quality with DX and DORA scores and watches for oversized PRs as a sign of
AI slop; quality markers from before AI should still guide. - AI rollout succeeds by removing friction: pre-integrate AI into tooling (Pendo, Grafana, Linear, LaunchDarkly) so teams start immediately, and redesign work around the desired outcome rather than mapping AI onto old process steps; keep human judgment as the quality gate.
- Three traits identify people who thrive in the AI era: outcome focus over craft attachment, curiosity about unknowns, and a sharing culture; those preferring old sequential processes may be better off elsewhere.
- AI increases team agency but makes documentation and planning more critical: with daily shipping, teams lose natural time to absorb context, so document intended outcomes and which decisions can be made autonomously.
- Scaling teams with AI shows conflicting signals: one CEO's internal AI platform cut engineer needs enough that half of engineers left without replacement, while Gartner/consultancy projections say 77% of jobs are still cheaper with humans and 40% of corporate agent projects will fail in the next few years; AI budgets are up 300–320%. Opus 2 deliberately keeps humans in the loop because customers prefer it, using agentic systems to remove mental load.
-
Juniors are a deliberate part of diversity strategy; they bring fresh perspectives and may adapt better than seniors who have more to lose. They get the same 30/60/90 onboarding as senior hires, but managers must be extra vigilant for AI-generated
slopand require juniors to present their own thinking. - CV advice: write the first 50% of your CV yourself to preserve strategic thinking; if starting with an LLM draft, rewrite it in your own words so it doesn't look machine-generated and accurately reflects what you did.
- Career advice: know your unique value — keep an updated operating doc about who you are and how you work — and build regularly, keeping hands dirty with firsthand AI usage without overdoing it to anxiety. [[ref:8947131:L130:L130]
Meta PMs now vibe-code prototypes and demo them to Zuckerberg, and Meta's product sense interviews include a live prototyping round — a signal that AI prototyping is becoming a core PM skill . In Productboard's survey of enterprise product teams, 60% already use two different AI tools just for prototyping .
Why the PM job changed: PMs prototype themselves instead of waiting on designers, and cheap, reversible ideas now get shipped behind feature flags and measured in production rather than run as separate experiments — prototype and feature are closer than ever, with the boundary blurring . Context: Marty Cagan says at least half of ideas won't work; good teams assume at least three-quarters won't perform as hoped. At the author's last PM job (7-8 engineers), any build took 2-4 weeks, so Figma prototyping was the discovery standard .
Framework — Iterate, don't spec: spec-based development with agents is a fancy way to describe phase-gated waterfall — an upfront specification is never correct (Allen Holub, April 2026); the alternative is iterating . Define strategic context first — users, problems, what matters most (jobs to be done) — stored in CLAUDE.md, or AGENTS.md outside Anthropic tools . Ready-to-use prompts: for a new feature, 'Prototype [feature]... Users / Problem / The specific job it solves / What we know... my idea is not binding — propose alternatives if better' ; for a new product, pass 'context, not requirements' (users, problems, JTBD, out of scope, rough idea), let the agent decide the screens, ask up to 5 questions, and save the context to CLAUDE.md — a one-line prompt also works, especially with the 'ask me 5 questions' line .
Tool trade-offs from building the same CRM in all four:
- Lovable — fastest path from prompt to published app; hosting and Google auth solved in one click, you pay for the editor, hosting nearly free; can import a design system (design.md or zip). Watch: vendor lock-in (no click to stop using Lovable Cloud; engineers unlikely to build on it); one database for every environment; unknown LLM .
- Google AI Studio — free version; test an idea today; can create Firestore database and auth. Weakest UI, default model Gemini Flash; Google ecosystem lock-in, but projects can sync to GitHub and continue in Claude or Codex .
- Claude Design — best-looking prototype, but interviews you first; no tracking, analytics, or databases; can't build features end-to-end .
- Claude Code — most setup, zero lock-in; real code in your repo, instrument anything, strongest handoff to engineers .
- Not recommended: Bolt, Magic Patterns (breaks when multiple people work on the same design), and ChatGPT-style chatbots (not for professional environments; can't be instrumented — use Google AI Studio instead) .
Security lesson from the live build: answering Lovable's interview ('small team, shared data') did not set the row-level security policy — Lovable generated USING true on contacts, so any signed-in Google user could see all data; an attendee confirmed the leak from outside 62 seconds after the link was shared. Check More → Cloud → policies before publishing and ask 'users should see only their data.' Per-user isolation is right for a demo; a team CRM needs an organization ID on every record .
- Job-market views for PMs considering a switch are split: one commenter calls it “HORRIFIC” and advises staying in a VP role , while another senior/principal PM — searching while employed — reports 12 screenings, 4 final interviews, and 3 offers from 300–400 applications, saying the market “feels okay” at his level . A third credits the positive result to being employed rather than laid off , which the searcher disputes .
- A former silicon-startup director now four years into IC roles describes a mixed bag: pay differed ~25%, he averages 30-hour weeks, day-to-day work is more fun, and as a strong IC he feels as much product input as his director/VP (CPO holds veto) — but a bad boss is “10x worse” as an IC, scrum ceremonies “suck,” and his once-valuable SQL/code/wireframing skills have “diminished to basically zero” .
- A VP who transitioned to IC after a layoff had the role cut a year later and now struggles to get interviews even for IC roles; they say only “old FAANGs” and AI model companies support in-and-out IC/manager mobility, and warn against companies without a real mission, urging ICs to retain ownership .
- A former Fortune 5 director who landed an IC role at a small company calls it “a blast” — hands-on building, autonomy, slight pay increase, and a quality-of-life upgrade from shedding governance overhead — while missing people development and noting more friction without a heavy title; “a step back isn't the death knell we're conditioned to think it is” .
- Advice for would-be transitioners: define what the IC move should give you (hands-on work, proximity to building, different stage, autonomy), compare scope, decision rights, compensation, and success metrics, and treat it as an experiment with an intentional narrative rather than a reaction to disgruntlement ; a simpler option is to apply while staying put .
- Compensation reference: Principal/Sr PM IC salaries in the $200–250k range; “beefier” IC titles are negotiable .
A fintech PM asked how to handle a Product Lead with zero technical delivery experience: no product roadmap, box-ticking 1:1s where priorities are accepted without strategic challenge, and reliance on AI instead of domain guidance; the PM weighs skip-level escalation vs. an exit . The lead is passive-aggressive , the OP is documenting decisions via email , and the team juggles 20+ local and global dependencies the lead doesn't understand .
Community tactics for this situation:
- Reframe the lead's role: a non-technical lead can still add monetization, GTM, vision articulation, cross-functional facilitation, and business cases — company need, not technical delivery, defines the role . Technical depth is not a deal breaker; a lead needs grounding in logic and trust in the PMs .
- Manage up: steer 1:1s toward topics you want to progress and ask pointed strategic questions; escalate or move if the lead is wholly unengaged . Send written notes with status, risks, and questions that force a real decision, then let the silence do the talking . Take ownership — build the roadmap yourself with the lead's buy-in and have them handle stakeholder persuasion ; sign-off demonstrates leadership, rejection surfaces what is going on .
- Don't cover up the lead's gaps — let management see them; asking about next-quarter goals and release results gets them thinking about the right things .
- Build evidence from customers: identify the most active users, learn what problems they solve and where the product falls short, share findings with the lead and skip, and carry them into weekly 1:1s .
- Skip-level escalation rarely resolves anything ; without metrics proving the lead is failing, nothing changes — step up or move . One dissenter calls managing up always terrible and recommends finding a new team .
- Define 'technical' concretely: PMs must proactively provide expected user ranges, concurrency, performance expectations, and platform context — not pick databases or architecture .
- Structural red flag: leaders without practical skills often appear when product reports to a CTO rather than a CPO, and the hiring manager is usually satisfied, making skip-level feedback futile .
- Self-check: criticisms of the boss may apply to yourself — "Everything that annoys us about other people tells us something about ourselves" .
Building for agents requires an extremely opinionated product: agents deliver outcomes without the user manually configuring software, so the product must enforce a single best-practice system; that opinionation creates a data advantage and moat that generic tools like Claude/ChatGPT can't match, because it encodes what components/CTAs correlate with sales and SEO outcomes.
In AI-native products, engagement metrics invert: high DAU/WAU/MAU no longer signal success — every manual login to intervene means the software failed; the goal is low-touch experiences where the software continuously executes best practices on the user's behalf.
Pivot case study — Owner: The restaurant-website/ordering/marketing platform (raised >$89M, on a "triple triple double double" growth trajectory) faced existential pressure in early 2023 from AI-native startups and large incumbents cloning its product. At the International Pizza Expo, restaurant owners (e.g., a 55-year-old PA pizzeria owner) showed genuine excitement about AI, contradicting industry experts and prior discovery interviews — prompting Owner to go all-in on AI.
Gradar — the AI-first product: typing a restaurant name triggers the AI to crawl the open web, audit ~90 SEO/CRO factors (Google profile, reviews, competitor landscape, photo quality), and in <5 minutes rebuild the website with AI upscaled photos, motion video, and copy reflecting what customers say on social platforms. It's free, has driven 83% of new customers to start with it (up from 0% two years earlier), helped Owner grow faster in 2025 than 2024, and is a large part of crossing ~$100M ARR.
Internal AI-native product development — Owen: an internal agent handles 90% of builder coordination work by continuously listening to GitHub, Slack, Notion, Linear, and Google Meet transcripts, and it also writes first-draft PRs for front-end bugs (e.g., a Slack-reported "bullets look too small") by calling Claude Code, saving highly leveraged engineers from monotonous fixes.
Product Insight Command Center: aggregates transcripts from Salesforce, Intercom, Momentum, TalkDesk and surfaces real-time dashboard insights on where to remove customer-journey friction and what to build to drive revenue — replacing the lossy process of manually interviewing support/sales/CS teams.
AI-native pre-call research (AIPCR) for sales: upon lead submission, agents deploy to auto-research — generating the Gradar report for problem awareness, identifying the nearest successful customer for social proof, and estimating gross payments volume within ~$250 to prioritize leads. This drove a >90% increase in call volume/rep time with customers and substantially raised close rate. Separately, automated sharing of positive customer quotes (via Momentum) boosts sales reps' confidence/conviction against constant rejection.
Leadership through AI transformation: the CEO models AI-native behavior — he personally built "Owner Photographer" in ~6 hours on a Saturday to solve a customer's $2,000-menu-photo problem, and it's now used by hundreds of customers. The right post-AI question isn't "how many fewer people do we need" but "how much more can we build"; Jevons paradox holds — AI unlocks a golden era for high-agency people, so leaders should expand ambition, not shrink headcount.
Internal tools PM roles are debated as a 'holy grail' of WLB. The original poster argues internal PM offers lower stress, better balance, and no monetization pressure at somewhat lower pay, provided stakeholder relationships are good . Practitioners confirm WLB can be significantly better than external/demand roles , but stress depends heavily on team and company culture . Others find it just as demanding — expectations stay high because the PM gates key features, and non-revenue teams are lean with many hats .
Unique pressures: proximity, politics, and program-management drift. Internal users can ping PMs directly, escalate to their directors, and even reshape the roadmap if loud enough . PMs spend significant effort tactically managing stakeholders, negotiating scope and timelines, and aligning dev teams; UAT is 'hell' . Multiple PMs describe the work as closer to program/ops management than product .
Career risk: hard-to-prove value and layoff exposure. Internal tools PMs are often in smaller teams, seen as a cost centre, and first to be cut because their impact is difficult to quantify . Senior management may not recognize non-customer-facing work , and group-level internal PM can be '100% organizational politics' . Staying visible and building rapport is the survival advice .
Prioritization is harder without clean value signals. Internal PMs rarely get usable usage or value statements — features are 'enablers' with unquantifiable impact, and urgent company initiatives skip roadmap scrutiny . Users often pitch solutions instead of problems, making requirements hard to reverse-engineer .
The upside: business-critical internal platforms and chill orgs. A PM on a business-critical platform reports full staffing, smart users, and technical bosses — '10/10' . Others value easy user access and WLB in relaxed/apolitical companies, calling it a good coasting role but not for the young or ambitious .
AI may shift demand for internal PMs. One commenter predicts AI flips build-vs-buy economics, making bespoke internal tools cheaper than SaaS and expanding internal PM demand across non-tech industries ; a counter-signal is that vibe coding may make these roles less chill . Industries with complex processes such as manufacturing and insurance are seen as best suited to internal tooling investment .
Case study: an internal CRM bug cost ~$250K/hour. A partial-refund bug in an internal CRM refunded whole orders for five hours (~$250K/hour) before being unwound; the PM's lighter testing was rationalized by the tool's small internal user base — showing internal tools can still cause major financial damage .
Career trajectory guidance is split. Some experienced PMs warn internal PM 'will worsen your trajectory' if tried early and suggest it only after external product experience ; another fears it restricts growth . A counterpoint: one PM moved from customer-facing startup PM to internal PgM at a large tech for WLB and more pay .
- Hiten Shah argues local AI models have finally crossed the quality bar for building real products: Qwen reports its 4B Qwen3 rivaling the prior Qwen2.5 72B Instruct, IBM says Granite 4.1 8B matches or exceeds the previous 32B MoE generation, and Google has a 12B multimodal Gemma designed for consumer laptops with 16GB RAM .
- Framework — judge models by the quality bar of the specific job, not by cross-model comparisons: a coding agent needs reasoning and a huge context window, while inline writing assistance cares about latency, voice, and whether the completion lands at exactly the right moment; "the smartest available model and the most useful model for a product can be two different decisions" .
- Case study — building a local writing product with autocomplete: once the model cleared the quality bar, small product decisions (where the suggestion appears, how much it writes, whether you can ignore or steer it without breaking flow, how native it feels) determined whether the experience felt impressive or like something worth leaving running all day; speed, context, and control mattered most .
- Product opportunity — "work below the threshold of asking": finishing six words in an email, cleaning one dictated sentence, classifying a file when it appears, extracting a single fact, or keeping an index up to date are jobs too small for a chatbot prompt; local models let software afford to care about these small, frequent tasks so "intelligence can start disappearing into the product" .
- Placement strategy — small, frequent, personal work with latency, offline, and privacy needs belongs on-device; the hardest reasoning, shared work, collaboration, and large context belong in the cloud; "great AI products will use both and get increasingly good at deciding where each piece of intelligence belongs" .
- Caution and mindset shift — a team can spend a week tuning an experience only to have the next model release matter more than everything it did, because the model set the ceiling ; once capability clears the bar, the remaining issues (speed, defaults, missing what the user meant) are "product problems" that can be observed, tuned, and tested by putting software in front of people .
- Maturity signal — local AI matures when running locally stops being the product story: users care that the writing assistant feels instant, keeps working on a plane, and keeps personal context close, not about the underlying architecture .
Lenny Rachitsky's interview-coach project in Claude Code — credited to @lennysan and @noamseg by user @sanika_mehta98 — is called "a serious game changer when prepping for interviews" . Rachitsky agreed and pointed to his guide "How to use AI in your next job interview" and to an "AI coach" at lennysjobs.com/coach that has "all of these skills baked in" .
Lenny Rachitsky created a Grok Bot trained on his 500+ podcast episodes and newsletter posts, positioned as a product/strategy/growth/career advisor . Suggested queries include how to find the first 1,000 users, how to get promoted, non-obvious growth ideas, great PM interview questions, and delivering hard feedback . The bot uses a custom MCP connector (https://mcp.lennysdata.com/mcp) for access .
@signulll reports using local Apple intelligence models in their product for many small tasks, especially personalization and copy, with excellent results; because the models are cacheable, they create subtle, tailored experiences for free . Hiten Shah notes that once inference is cheap enough, intelligence can be applied to details previously too small to bother with, making software feel "incredibly thoughtful" .
Hiten Shah: taste (product judgment) is hard to teach because it comes from caring longer than others — looking again, asking why, and noticing the small thing that feels off; judgment gets faster as attention gets deeper .
For transitioning into PM without a product team at the current employer: reframe your resume to reflect product thinking, ownership, and cross-functional teamwork; target adjacent roles (Product Analyst, Business Analyst, Chief of Staff); build a portfolio with product decks and AI projects; attend PM meetups/conferences; and actively use LinkedIn to post PM content and engage PMs. An MBA is not a prerequisite — the responding PM transitioned without one.
A PM's AI-focused portfolio should cover six categories: traditional ML/LLMs/GenAI architecture; AI product evaluations; AI economics; AI UX (copilots, chat interfaces); AI engineering literacy (e.g., chunk size, embedding models); and AI strategy. Portfolio artifacts can include blogs, articles, decks, and projects.
A Master's is not essential to land a PM or consultant job in Germany; existing Product Owner experience can support direct applications.
One commenter reports receiving feedback from industry contacts that the PM job market is currently slow.
- A Product Lead asked whether it's reasonable to expect a designer to define states and interaction behavior beyond the happy path (e.g., when validation happens, error/empty/disabled states, behavior after correction), without requiring 50 screens — seeking an annotated flow or state spec instead, and asking where the PM/UX/engineering line falls . Designers broadly called it table stakes: "Not unreasonable. Table stakes of the job" , "You work with artists, not designers" if this happens , and engineering shouldn't be left guessing missing states .
- A widely-upvoted designer-turned-PM says the expectation hinges on environment: in established products engineering should already know common validation patterns; at startups with one designer covering many tracks, afford slack on well-established patterns like date fields; with offshore by-the-spec engineering, explicit state definition is required for success. PMs should still be able to assert "these fields are required," and designers should adapt to engineering needs .
- Tactics to close the gap: ask for Figma Make prototypes simulating happy path, error states, and key interactions instead of static screens — though one designer counters it's a skill problem, not a tool problem , while another found prototyping helped them reason in use cases . PMs should document validation business rules that deviate from standard (e.g., "cannot be a past date") but not generic standard fields, and not every little thing must be specced — engineering should apply common sense . Also check whether the designer is UX- vs UI-trained (rarely both) and whether the product already has established patterns to reuse . A reference to share is "50 things you probably forgot to design" .
- A helpful framing from a designer: fidelity tiers — PM is tier 1 (business needs, metrics, ideas), designer is tier 2 (solutions), engineer is tier 3, and code is the highest fidelity; what level of design is needed is a design-engineering compromise, aided by a design system .
- Cautionary case: one PM hired a "Senior Designer" whose prior work was simple web apps; the designer repeatedly missed interaction detail for a complex app, took months of iterations, had no senior mentor, and was eventually let go — the company then resorted to AI for UXD, and "the AI actually reads my requirements" .
In a r/prodmgmt thread on an experienced AI PM exploring VC scout programs, a commenter working in VC said scout programs still happen but are typically extended to people with adjacent expertise (investment, venture studios, founding successful startups); traditional product experience doesn't overlap with VC as much as people think. They advised that PMs need an industry edge such as founding a successful company, working at an internal VC org at a tech company, or an accelerator . The original poster, an AI PM with VP of PM offers, said VCs he dealt with "know very little about the actual AI tech" despite using the right terms, and argued his background building successful 0-1 AI products gives him an edge in evaluating whether AI products are well built vs. demos . A second commenter countered that the poster's background "sounds really similar to like 90% of product leaders (in somewhere like SF)" and not relevant enough to pivot into proper VC without an industry edge .
- Analytics stack switch context: A PM at a B2B2C foodtech platform (think SYSCO) is weighing an analytics-stack overhaul away from FullStory: management favors Pendo for its product guides, but the PM finds Pendo more rigid than FullStory or PostHog for quick queries; keeping FullStory and adding Appcues for product guides is also on the table.
- Cost: Pendo is expensive — one commenter calls it pricier than other options and another says its cost/licensing model did not work at two companies; FullStory is also called expensive; PostHog is cheap to start but more technical; Amplitude is expensive but more polished than Pendo.
- Tagging and data-access trade-offs: Pendo supports retroactive tagging (historical data after tagging post-launch) and API export (e.g., Qlik), but is clunkier and harder to learn; FullStory has more flexible in-app reporting and session replay, but one commenter believes it lacks API export and requires pre-tagging for historical element data.
- AI/MCP impact: PostHog's MCP integration is called a "game changer" that removes barriers to what you can do, and in-app AI/wizard tools are reducing the need for technical skills in analytics.
AI-driven design cuts push designers into PM roles. A UX designer at a major US company reports that after layoffs, all design work is fed into Figma Make and its outputs are used as-is; leadership no longer sees designer value and is converting designers into PMs to run leaner, AI-assisted teams . Commenters see this as part of a broader shift: demand for traditional UX design is declining, and junior design roles may not exist in 3–5 years .
Transition advice for designer-to-PM: lean into the product discovery and "why" instincts already built in UX; business cases, decks, collaboration, and stakeholder management can be learned — AI can even produce decks and strategy docs — and sound product strategy matters more than extroversion . Design backgrounds can be an advantage: designers think end-to-end, focus on journey touchpoints, and can grow into UX-focused PMs who span vision to implementation; the forced move can be treated as paid schooling .
PM role, simplified. A designer-turned-PM's struggle is the scope — business requirements, engineering dependencies, timelines, stakeholder decisions, priorities, metrics, Jira tickets, meeting decisions — but one commenter argues the job reduces to: understand stakeholder wants, work with Eng/UX on estimates, prioritize, have hard conversations about feature creep, and stay current via a weekly board review or AI summarization (5–10 min) .
Onboarding playbook for a new product/team: map mutual dependencies; learn goals, roadmap, feedback, technical limits/dependencies, and revenue/P&L; map stakeholders; always meet customer operations (customers can be internal — just talk to them); and know the product inside out from docs and flows .
Quick upskilling: a 2-day CSPO course teaches PM/Dev terminology and Agile/Scrum mindset — performative but enough to "play ball" .
Counter-perspectives: designer-to-PM can triple what's required of you with less creative focus time , and being forced into PM while leadership pushes AI-generated designs may be reason to polish the resume and leave .
Compensation upside: a designer who was forced into PM says earning potential far exceeds UX/UI, senior PMs regularly make over $250K/year in conservative organizations, and the role brought ownership and fulfillment .