We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI’s next surface is ambient micro-work. Hiten Shah argues that autocomplete, extraction, classification, cleanup, and routing are often “over-modeled”: small local models are already good enough for many of these jobs, especially when they need to be fast, private, and always available. He describes the next product surface as work too small to ask for—finishing a few words, fixing a sentence, extracting a fact, or classifying something as it arrives—and says local AI should disappear into the software rather than expose model setup to users. Scott Belsky’s shorthand is that agent personality, proficiency, and personalization are becoming the new UX.
AI is expanding PM self-service, but context and validation remain the boundary. One PM reports getting usage metrics in about five minutes instead of sometimes waiting a week, and answers about features, code, databases, analytics, and logs in five to 10 minutes instead of several weeks. That speed depended on analytics coverage plus read-only access to the codebase and a database copy; the agent also surfaced existing but hidden product functionality. The practical limit is clear: machine-readable context works well for analysis, while agent-generated changes are riskier when the codebase is stale or a change touches shared state or core flows. A product-craft proposal offers a useful division of labor: keep strategy, hypotheses, metrics, success validation, and trust-building human; automate synthesis, monitoring, and research. Messy data, regulated environments, research context, and model accuracy still demand expert review.
Tactical Playbook
Turn “grow” into a choice architecture. For a PM inheriting a neglected portfolio, use Roger Martin’s Playing to Win sequence: define point A (current revenue or users) and point B (the growth target); identify the gaps; choose non-contradictory actions to close them; then test those choices with internal and external stakeholders. Add a field-level scan of the customer journey and after-sales experience, stakeholder alignment, competitors, market size, and company portfolio before budgeting. Look for a distinction that makes a target segment prefer you, but check whether that niche can reach the company’s ambition; iterate until the choices and expectations align.
Move roadmap tradeoffs upstream. A roadmap that lists commitments without showing what each one delays or makes harder makes every item look independently reasonable. Capture those opportunity costs and the reasoning in planning, BRD, or PRD material; keep the shared roadmap as a clean statement of direction rather than asking it to carry the full decision debate.
Case Studies & Lessons
A feature gap became a design partnership. At Rippling, a customer wanted Excel- or Google Sheets-style financial calculations that the platform did not yet support. The technical product manager acknowledged the gap, escalated it to product with a concrete date for an answer, offered an interim workaround, and kept the customer involved. The customer ultimately helped design and architect the feature, becoming a design partner rather than an adversarial escalation. The repeatable play is: separate what works from the one product gap, avoid promises without product confirmation, give a dated next update, and keep communicating even while the answer is pending.
Career Corner
AI PM interviews reward problem selection over AI vocabulary. Advice from a current AI PM is to distinguish problems that genuinely need AI from processes or systems that simply need improvement. A candidate who recently received two AI PM offers says interviewers focused on whether she could identify a real user problem, define AI’s limits, phase the work, understand the workflow, and compare the bet with the existing roadmap—not on advanced model theory. Prepare two cases in that format, while learning where MCP, RAG, APIs, and the company’s cloud architecture matter.
Data-centric AI strategy and market. YC Data Club host François frames data sets and RL environments as products that determine whether LLMs can do domain jobs (doctor, accountant, lawyer, therapist) and proposes that the number of viable data companies roughly equals the number of apps on a phone; most domains, he argues, will be won by specialist companies (e.g., a focused 'AI doctor' with curated data and a doctor network) rather than by OpenAI/Anthropic/Apple building in-house — the Apple/Instacart analogy — except where the capability is cheap, like a flashlight . VCs once put data businesses' terminal value at zero; instead they created $100B+ in market cap over ~10 years and became one of YC's best investment categories .
Building data as a product. Dataset quality is product craftsmanship with edge-case taxonomy decisions: Focal Systems spent extensive time on in-stock/out-of-stock data (e.g., whether shelf 'product pushers' should be a separate ontology class or classified as out-of-stock, knowing it could confuse the model) . Data also rots: when Salesforce changes its UI, captured traces and screen captures stop working, so even 'all the data you could possibly capture' is never enough — data is the bottleneck, not architecture, GPUs, or watts . When a model plateaus (interview question: 85% F1 on hot-dog/not-hot-dog), the answer is to examine false positives/negatives, bucket them, and fix the biggest issue rather than change architecture; data matters more than architecture, and the balance flips from ~5% data attention in research toward data dominance in production (per Andre's estimate) .
Evaluating senior-level coding agents (Snorkel). Vincent Chen (Snorkel founding team; leads benchmark/eval research) says teams trust coding agents with senior-level architectural decisions yet still evaluate them like junior engineers; Senior SWE-bench task design instead uses realistic high-level instructions (Slack-message-style) rather than over-specified step-by-step prompts . Core methodology: experts write a short 'validation spec' (user stories plus functional/non-functional requirements, deliberately not over-prescriptive), and a validation agent converts it into deterministic test scripts executed against the candidate patch, with LLM judges checking sanity, fidelity, completeness, and collusion/reward hacking — a middle ground between unit tests (reliable but penalize valid alternative solutions) and pure LLM judges (flexible but reward plausible-but-wrong solutions) . Outcomes: a 'tasteful pass' metric scoring mergeability plus codebase-aligned taste (including patch bloat) — a live benchmark where leading frontier models tied for first — and the observation that basic evals (HumanEval) have saturated while harder terminal-agent benchmarks remain nearly unsolved (latest models ~1%) .
Benchmark-vs-production gap (Inception Labs). The most widely used voice-agent benchmark is 'extremely benchmaxed': most models score in the 90s on it, but the same models score far lower — with much more variance across model sizes — on real-world production logs, and it contains an order of magnitude fewer specs and tools than real customer-support settings, making leaderboard scores a weak predictor of production performance .
A PM uses a coding agent with read-only access to the app code and a read-only database copy, plus analytics across nearly every component, to self-serve usage metrics in ~5 minutes (vs. a week waiting on the data team) and answer feature/codebase questions in 5-10 minutes (vs. weeks via developers). The agent sometimes offers to implement changes immediately; the PM is weighing letting it write changes for developers to review. The same PM found the agent can surface hidden, unactivated features that already solve UX problems without development.
Reactions are mixed. One PM says 'Yes. 1000%' - data teams and engineers now only do what the PM can't ; another says no because MS Copilot lacks access to the systems holding product data and serves as a search/market-research tool ; another already self-serves usage metrics and does not want the dev team's job of avoiding duplicate features and technical hygiene ; another uses Claude to offload intern-level tasks and sketch ideas to take to design .
For quick internal metrics or usage data, agents get there faster when built on structured data with read-only access to the codebase and analytics; poor results usually mean asking an agent to work with context that was never set up to be machine-readable. Agent-generated code removes the spec-to-code translation step, but failures are harder to diagnose because the agent works from a slightly outdated codebase picture - fine for simple changes, dangerous when touching shared state or core flows.
Caveats: messy data and healthcare guardrails can make an agent struggle, and AI lacks context for research ; validated against developers, 'nearly every performant model' still misses on accuracy, so AI is strong for curated work with a knowledgeable human in the loop but not team-replacing - 'maybe in 1 year, likely in 3' . Another commenter advises keeping a healthy dialogue with technical experts about hallucinations.
On r/startups, a technical founder who froze on marketing copy because—unlike code—it had no spec, scope, or definition of done built an engineering-like content system: a closed list of four angles (a decision made incl. rejected options; a mistake and its cost; how a product mechanic works; a pattern heard across user conversations), every marketing item tracked as a scoped ticket with a done state, a fixed non-negotiable publish day, process metrics tracked separately from outcomes, and a 10-piece review loop that cuts any angle with zero replies/follow-ups, unprompted DM quotes, or inbound questions; he flags it as unproven beyond producing consistent output .
Commenters converge on sourcing topics from customer signals: sales objections, support tickets, customer questions, and edge cases; the trigger is the second time the same question or frustration appears (the first is one confused person, the second is a pattern), and the customer's exact words should be saved because they become the post title . A formalized version: log a raw note per customer conversation, promote it to a content ticket when it names a decision at stake and recurs or blocks progress, then in a weekly review group notes by decision and pick the cluster with the highest frequency or cost of confusion .
Two caveats from the thread are worth routing: the three review signals lag by weeks-to-months, so run each angle for a fixed six-to-eight-week stretch and add a same-day leading signal (real comment/question vs. just viewed) ; and the product-mechanic angle is where technical founders drift for comfort even though buyers care least about it unless they're engineers—a run of mechanic posts signals procrastination . Heavily formatted, numbered posts also keep drawing AI;DR reactions, which is feedback to act on .
- Lenny Rachitsky launched a Grok Bot trained on his 500+ podcast episodes and newsletter posts, positioned as a product/strategy/growth/career advisor .
- It answers questions like finding the first 1,000 users, getting promoted, non-obvious growth ideas, PM interview questions, and delivering hard feedback .
- Setup: use the custom MCP connector at https://mcp.lennysdata.com/mcp with the native connector flow (email sign-in), then verify by searching the archive for "product-market fit" .
- Lenny suggests this may become the best way to consume his content .
- He later shared the most common questions received so far in a follow-up post .
Hiten Shah (Crazy Egg, KISSmetrics, Nira) argues 'There is no progress without motion because motion creates contact with reality'; as AI makes execution cheaper, founders can get far more reps against reality, with every rep a chance to sharpen judgment . In a conversation with @daraladje, he says The Social Network ruined Silicon Valley by turning startups into an outcome to pursue rather than something you do because you love building — attracting hype-chasing tourists instead of true builders — and, after 20+ years building Crazy Egg, KISSmetrics, and Nira (acquired by Dropbox), inventing playbooks the industry copied, and returning to run Crazy Egg again as CEO, offers the advice that 'startups really aren't that deep. Have fun. Do things. Get in contact with reality.'
- Clarify what you need to know rather than adding more analytics SDKs; one practitioner ran six analytics tools in parallel without performance issues, but noted installation gets harder as tools wire into pages similarly .
- PostHog's MCP can be connected to Claude or GPT to discuss business objectives and build tracking dashboards , though AI-generated dashboards were questioned for potentially making up data points or jumping to conclusions .
- In highly regulated EU B2C settings, one PM avoided PostHog entirely for GDPR approval reasons but still gained insights from traffic segmentation; session recording was considered overkill at high traffic . Recommended: form a two-person 'brainpool' to define the analytics problem and prepare with an LLM .
A bootstrapped solo founder with 200+ pre-sale paying customers and a product still under development is weighing raising capital versus freelance/full-time work, which would prevent both. The founder believes a strong product-market fit exists, wants to stay lean, and would only hire in a no-brainer situation .
Demand-validation guidance: with 200 paying customers, demand is already proven — raise only if the money buys ~12 months of full-time building and the founder can accept monthly growth scrutiny. The real cost of raising is the right to stay small; an alternative is pausing new sales to finish the product for existing customers .
Customer-development practice: collaborate with pre-sale customers to ensure the product meets their needs (and consider advance payments or loans); the founder confirms they are already working with pre-sale customers to shape the product .
Case study — a founder raised an $800K VC round for 12.5% equity, paid himself, hired a team, and gained legitimacy selling to B2B customers; investors never pressured him, he kept a solo board, built the company to profitability, and closed in ~3 months. The caution: the market turned out far smaller than assumed, so they cannot raise again — validating market size before raising matters .
Raising VC implies 10x-100x return expectations and pressure to grow as fast as possible; counter-advice is to bootstrap until investors come to you to keep the power dynamic, while acknowledging governance costs such as investors taking board seats .
A 5-year PM getting few callbacks while applying for roles (goal: move to Zurich or London as a PM) is evaluating the AI PM accelerator from Nancy Li despite its high price tag. The program includes launching their own AI product with a team of 5 AI engineers in 11 weeks, plus unlimited referrals and CV/interview prep . The poster cites mixed community feedback on the program from posts a couple years back, questions whether it sounds too good, and asks for positive experiences or similar PM career programs with an active mentor/coach .
Hiten Shah frames the next big AI product surface as "all the work too small to ask for" — micro-jobs like finishing six words, fixing one sentence, extracting one fact, or classifying something when it arrives . He argues local models make these tiny jobs cheap and fast enough to disappear into the product , pointing to a "Local Models 101" session on Friday at 10 AM PT at hiten.com/local-models-101 .
Forward deployed engineering behavioral interview with Rippling founding FDE Kamlesh Vadula surfaced PM-relevant tactics:
- When a customer asked for Excel/Sheets-style financial macros Rippling didn't have, he positioned it as already on the roadmap, escalated to product with a promised MMDD, and provided an interim workaround; the client later helped design the feature and became a design partner. For more obstinate clients, he recommends empathy, checking for earlier miscommunication, making the request the top priority, and showing concrete progress/dates so clients feel heard rather than rejected.
- In cross-functional discovery with sales and clients, tailor language to the audience (CTO vs HR admin), watch for silence as a disengagement sign, and ask needs-oriented questions; when a product gap emerges, route it to the right product contact, avoid on-call promises, and follow up even without an update.
- To close product gaps with engineering, offer to implement small items yourself when engineers are backlogged, which earns respect; in discord between client asks and internal priorities, recognize not every request is number one (escalate when many clients ask the same thing) and rely on communication, documentation, and flexibility while acting as the client's spokesperson.
Handling a top-down project whose low-value requirement survives data-driven pushback and failed escalation :
- Find an ally, document your reasoning with data, and ask them to explain the value — it may be political; if so, email that the team will build it but note it derails higher-value projects, protecting you and preventing the PM/EM from claiming ignorance of costs . If rolling over, frame it to the team as building leadership trust that funds meaningful work later ("suck it up — it's only 2 sprints") and keep notes to bank leverage for future fights .
- Reduce wasted effort by breaking the requirement into its own increment to ship and beta it sooner, then continue development later as a continued effort or with enhancement allocation .
- While the project is alive, extract value from its periphery, run stealth/exploratory work that becomes valuable when the project flops, and carefully define GTM/user expectations so the failure doesn't look like yours .
- Before concluding it's low value, check for hidden drivers — customer commitments, contract obligations, executive AOP, politics, or bonuses tied to it — since engineering may not have full visibility .
Hiten Shah argues that many AI workstreams (autocomplete, extraction, classification, cleanup, routing) are "wildly over-modeled," and that plenty of these jobs already work well with small models running locally on a user's own computer . He's hosting a session on what he'd use locally at 10 AM PT Friday, via a Local Models 101 link .
Hiten Shah argues many AI products are overpowered: teams are spending 'frontier intelligence' on jobs that mostly need to be fast, private, nearby, and good enough to run constantly . He announced a Friday 10 AM PT presentation where he'll show 'the jobs I’d already move onto the computer you own,' with a sign-up page at https://www.hiten.com/local-models-101.
- A widely debated stance: a roadmap without explicit tradeoffs is "just a list of promises"; each roadmap commitment should be paired with the opportunity cost it creates (what it delays, removes, or makes harder), though practical documentation methods are still open . One commenter adds that each decision should include pros, cons, and a recommended ranking, all tied back to team and company mission .
- Many commenters argue the roadmap itself is the wrong place for tradeoffs: decisions and tradeoffs should be discussed during planning/roadmap reviews and captured in BRD/PRD-type docs, while the roadmap stays a clean visualization of direction . Embedding tradeoffs in the roadmap adds uncertainty and invites stakeholders to challenge the plan .
- In big corporate settings, roadmaps are "theatrical yet symbolic" but still matter: they reassure clients, help sales land prospects, and serve as proof-of-work against leadership pivoting, short-termism, and misaligned executive/department roadmaps. Detailed tradeoff documentation can be kept in a private product roadmap .
- A useful distinction: product roadmaps (vision, direction, mission, revenue targets) vs feature roadmaps (detailed delivery items). Feature roadmaps are considered useless in most orgs — they over-guess long time horizons and make the org rigid — and are best used only as a sales asset for enterprise customer relationships .
- Sceptics hold that a roadmap is inherently "a list of (vague) promises" representing problem areas — or that roadmaps are not useful at all .
- A career switcher from biology (master's in information management, side projects) reports being unable to land a PM interview despite building technical skills .
- A commenter calls the current junior PM market "a joke," claiming few junior roles exist and they all want five years of experience; recommended tactics include LinkedIn networking, messaging PM graduates from your program, joining local product meetups, seeking referrals and informational chats, and tailoring each resume to the posting .
- Another commenter suggests trying PM internships as an entry point .
Context: A PM ~8 months into the role owns four equipment products used in non-overlapping applications across industries/geographies; no one owned them for 8-10 years; they're tasked with creating a growth strategy and feel stuck because 'sell more' and customer visits aren't strategy.
Frameworks: Roger Martin's Playing to Win — strategy is a set of actions to get from point A (current revenue/user base) to point B (growth target); identify gaps and make non-contradictory choices to close them; must involve internal and external stakeholders, not done in a vacuum.
Key Roger Martin takeaways: find a distinction you can leverage so your target customer segment prefers you over competitors — that's your growth motor, but don't copy them. However, a niche distinction can limit growth, so check that point B aligns with company strategy; if company strategy won't change, change point B; iterate until stakeholders align. Strategy is hard work, not a two-day retreat.
Practical 5-step discovery process: (1) map the customer journey incl. after-sales, (2) assess product-stakeholder alignment across journey and after-sales, (3) discuss with stakeholders and customers to establish where you are and why, (4) scan competitors, market size, and company portfolio, (5) then build strategy and budgeting.
Basic advice: talk to users and try using the equipment yourself.
AI-assisted planning: one commenter suggests giving Claude exact details for a plan; another questions viability, citing community pushback against using it for strategy.
A 29-year-old PM with multiple short stints is weighing whether to reset to a junior PM role at an MNC for stability, or something else . They describe 4 orgs in 3 years, with one org extending probation (leading to resignation), another putting them on a PIP, and a third laying off 100 people as part of bottom-quartile filtering, attributing the pattern to their PM performance in startups not being up to mark . The thread crossposts a question originally from r/ProductOwner .
PMs report that quarterly roadmaps are undermined when stakeholders and leadership change direction mid-quarter; teams are "measured by output but judged by outcomes," making delivery feel impossible . Some PMs also say honesty at work carries consequences — they must manage everyone's feelings while their own go unnoticed — and that criticizing groups adds to the risk, even though PMs often have the best sense of user, company, market, and product .
- A computer-science grad with no PM experience is weighing a startup PM-intern offer to move beyond coding; commenters uniformly advise taking it, since getting a foot in the door is the hardest part of the PM career path , and an internship is a low-stakes way to test the role — if it doesn't fit, the internship ends or the startup goes broke .
- For a first PM role, take a deliberately passive learning posture at first: learn how the business truly works, the operational landscape, and "who is who" before trying to change things; advice aimed at experienced operators is often counterproductive early in a career . Consistently probe the deeper "why" behind every question and answer, since people give the solution they want, not the problem they have . PM confidence and job satisfaction follow an inverted bell curve early — the role swiftly reveals whether it's for you .
- Internship value scales with startup maturity: pre-revenue 0-to-1 startups lack structure and the experience depends on the craft of the people around you; a 200–300-person startup with a running product operating system teaches frameworks, alignment, and political skills. Learn the standard at a big company first so you know where to break the rules .
- Main risk of a startup first role is lack of structured mentorship — no formal training, so you figure out writing specs and running standups on your own. A CS degree is a key asset: engineers respect PMs who understand technical constraints and don't write hand-wavy requirements; use it to build dev-team trust early, and focus on learning to prioritize features when everything is on fire .
An r/ProductManagement post asks how PM teams are leveraging agents in their workflows and whether agentic practices are formal yet, noting ADLC gaining traction on the engineering side . The author's personal view proposes a split: hypothesis-to-strategy connection, success validation, and trust-based communication stay human; synthesizing, monitoring, and research can be fully agentic . He also questions whether PRDs, alignment, and prototypes are still needed if teams can ship to prod and evaluate, how roadmaps work when bets take under a week, and whether AI customer interviews can replace human ones . He argues traditional research/prototyping existed to derisk expensive engineering; with that cost gone, teams could do less and validate with real customer data . One commenter reports using an agent to update Jira tickets, hoping to never have to use Jira again; a reply asks what's wrong with Jira .