We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI is turning personal speed into an organizational benchmark. Zara Zhang argues that talented individuals can reach 10× their potential with AI on their own work but see at most a 20% gain inside a large organization; Hiten Shah’s sharper framing is that AI gives people a reference point for how fast they can move, after which every organization is measured against it. For PMs, use that benchmark diagnostically: measure decision latency, handoffs, access, and review queues alongside output. If output accelerates while those queues do not, the bottleneck has moved.
Local inference is becoming a self-managing fleet. Shah describes a Mac mini running a Hermes Agent that manages six Macs; the agent created its own observability and optimization tooling and uses them to operate the fleet alongside other local AI workflows. The product implication is a broader AI-infrastructure surface: fleet orchestration, observability, optimization, and safe autonomy—not just model selection.
Tactical Playbook
Build an AI-speed delivery contract instead of using the demo as surveillance. The triggering question was whether AI-enabled engineers “blasting out code” leaves PMs out of the project until the sprint demo. A practical contract from the discussion:
- Put enough implementation detail into acceptance criteria for engineering to proceed while the PM works elsewhere.
- Require uncertainty to be surfaced early, with the engineer explaining the judgment behind an autonomous decision.
- Trust the team and treat mistakes as shared problems to unblock, not occasions for blame.
- Use a preflight before broad stakeholder demos: an internal Eng/PM demo can be loose, but a larger demo without PM and engineering alignment is a “huge misalignment.”
This preserves PM attention without making delivery a black box; the handoff is explicit, and the first stakeholder demo is not the first integration point.
Prioritize proof before features. When requests exceed engineering capacity, a PM’s prioritization framework says scoring methods help, but the harder decision is which evidence deserves the most weight. It recommends weighing customer pain, strategic alignment, impact, urgency, and effort; prioritizing the problem first; and choosing the feature that tests the core assumption. In practice: write the assumption, identify what could falsify it, and choose the thinnest experiment rather than the most-requested feature.
Case Studies & Lessons
A waitlist is a question, not product-market proof. A founder’s social app for meeting new friends collected around 52 signups in eight days from low-budget Meta ads, while still trying to determine what people might eventually pay for. The follow-up numbers were 6,758 impressions and 272 clicks; a commenter warned that the signal might be weak and recommended checking click-through-without-signup behavior before investing further.
The next move is discovery, not more features: ask signups what they thought they were signing up for, then use a short survey or conversation to test the problem and intended use. Treat the campaign as evidence about message and problem understanding—not as proof that a subscription roadmap is justified.
Career Corner
Choose organizational stage for the reps you lack. A community model says lean teams make PMs direct decision makers, while mature teams shift the challenge toward defined roles, politics, stakeholder alignment, and visibly demonstrating progress. The harder skills to build in lean teams include stakeholder management, politics, and coordination across teams, time zones, and departments. A second breakdown calls the 25–250-person scale-up stage especially awkward: roles exist, but instrumentation often does not, so people manually prove their value.
Also verify actual ownership. In founder-led companies, founders may retain control of product detail after hiring a PM, leaving the role with minimal product ownership until growth forces delegation. In interviews, ask who makes feature decisions, how cross-team dependencies work, and what evidence shows a product is blocked; the answers reveal the learning environment better than the title.
Tools & Resources
Model discovery: Hiten Shah calls OpenRouter and Hugging Face “Product Hunt for new AI models.” Use them as discovery surfaces, then evaluate candidates against the task, latency, cost, and operational constraints of the product.
Reddit's r/startups thread on books that made better founders surfaces several titles directly relevant to product management:
- The Mom Test (Rob Fitzpatrick): short and practical; teaches how to talk to customers without fooling yourself; especially useful for startup newcomers .
- The Lean Startup: shifts mindset from fixed execution plan to continuous experimentation to arrive at the best business model .
- Zero to One (Peter Thiel): framed as a way to think — pursue valuable monopolies instead of copying competition; forces sharper questions about why a business should exist; a good pre-tactical starting point .
- The Innovator's Dilemma (Clayton Christensen): though questioned as being for larger orgs , one recommender argues it helps startups design a wedge incumbents struggle to close, because it shows how good management and listening to best customers create openings .
- When Coffee and Kale Compete: useful for understanding user needs, jobs to be done, and customer mindset when choosing products .
- Just Enough Research: helps avoid going too far down a path without validation .
- Rework (37signals/Basecamp): chapter-per-problem style, widely applicable .
- Paul Graham's essays are recommended as a whole .
One commenter recommends a staged reading program: Zero to One, The Hard Thing About Hard Things, The Lean Startup, The Mom Test, High Output Management, Only the Paranoid Survive, The Innovator's Dilemma, and Crossing the Chasm as foundational; later Founders at Work, biographies, and thinking books .
Counter-signal: several commenters caution that reading books is no substitute for trial and error — "a well selling book won't help you" , and "the whole way you get better at it is by doing it and internalizing the lessons for real from experience" .
Founder validating a social app for meeting new friends threw together a proof of concept and ran low-budget Meta ads to a waitlist, aiming to build things people would eventually pay subscriptions for; it collected ~52 signups in 8 days, and the founder asked whether to interview signups via email or call before building . Ad performance: 272 clicks from 6,758 impressions; a commenter read low signup interest as possible negative feedback and advised checking shown/viewed and click-through-without-signup metrics before investing more .
Validation tactic: email waitlist signups to clarify what they believed they signed up for, ask what direction they pictured and what would be useful, using a short poll that frames the concept as still in development . The founder positions the app against a direct competitor with few users that does not cater to virtual events .
Cautionary experience: a commenter who built a similar product in 2014 grew to 15k signups in the first 24 hours and 100k+ over a few years, but warns subscriptions are very hard to monetize, ads are the only realistic path, and most social networks (including Reddit, per the commenter) are not profitable and rely on investment; in 2026 investors are not funding this category, and acquisition costs plus tightening global social-network regulation create growth and sustainability risk .
A developer with 4+ years in React/Next.js/Node.js/React Native reported little luck joining early-stage startups despite trying Wellfound, LinkedIn, YC jobs, and direct outreach to founders by email and Discord — most weren't hiring or never replied .
Advice from the thread for getting into early-stage startups:
- Don't lead a résumé with years of language experience; lead with taking projects from idea/spec to delivery, product thinking, adapting to customer feedback, and design intuition — startups need people who can execute half-baked specs without much supervision (many now lack product designers and frontend developers), so programming languages go at the end of the résumé. Candidates should also expect questions about whether they've built anything incorporating agentic reasoning .
- A 15-year startup veteran found no magic formula for joining startups; she landed her current role by posting on X, and previously met people by attending many London startup events with varied locations and hosts. Her advice: narrow down your target domain and roles and articulate them clearly to everyone you meet — generalists (e.g., chief-of-staff types) are hard for founders to categorize, and people won't recommend you if they can't 'put you in the box' .
Zara Zhang argues AI creates a widening gap between solo and organizational productivity: talented individuals can hit 10x their potential with AI when working on their own thing, but inside a large organization the same person gains at most 20% — sometimes even less — which is why more talented people are leaving big companies, with top AI labs (OpenAI/Anthropic) as the main exceptions . Hiten Shah adds that AI gives people a reference point they never had — "How fast am I actually capable of moving?" — and once someone knows the answer, every organization gets measured against it, changing the talent market more than people realize .
- A PM compares lean startup teams to toddlers chasing a ball and mature teams to teenagers with defined positions; in lean teams the PM is the decision-maker working directly with management, while mature teams require structure, stakeholder alignment, and internal politics, where "showing you're doing things is just as important (if not more so) as doing the things" .
- Skills harder to develop in a lean team include stakeholder management, politics, coordination across many teams/timezones/departments , and working/coexisting with other PM teams and product orgs .
- In small founder-led companies, founders often keep control of product detail, making the PM an "assistant PM" with minimal ownership; ownership increases after growth and added management layers .
- Communication is called the most important PM skill, demonstrated through difficult conversations: gathering problems rather than feature suggestions, getting access to end users instead of execs, keeping sales setting user interviews even when you won't build their ask, showing internal stakeholders that users care about different things, and explaining to engineers that 2 clicks are "5X worse" than 1 — all while keeping each stakeholder on your side .
- A PM who moved from a startup to a Fortune 100 bank says the roles are "two very different jobs": startup PMs make quick gut decisions, corporate PMs need weeks of research and buy-in and face more politics, and returning to learn the fundamentals and people skills was valuable .
- PM-team maturity can be split into three stages — Toddlers (1-25 people), Teenagers (25-250), Professionals (250+) — with scale-ups described as the worst of both worlds: positions exist but no instrumentation, so you spend energy proving your value rather than building it .
Many PMs report not feeling left out between sprint demos, citing trust in their teams and competing demands on their time (PRDs, roadmaps, stakeholder alignment) . A common stance: being absent during delivery signals well-scoped requirements; PMs write requirements, approve design, and expect demos to match unless engineers flag otherwise . To stay aligned, some PMs ask engineers to surface uncertainty early and exercise judgment in their absence, then own outcomes together rather than micromanage . A caution: PMs should see work before it is demoed to larger stakeholder groups; internal eng/PM demos are fine, but external demos require prior PM review . Contrasting operating models: one PM runs a 1:1 PM-to-engineer "builder pod" for 0-1 transformation/automation work and ships alongside devs all day, while larger products run 1:3-5 . Another PM with a hands-on role (troubleshooting, solution design) says a demo-first view would be unthinkable . Practical tactics: bake implementation details into acceptance criteria to free PM attention ; at least one PM skips sprint demos entirely .
A Reddit post 'What Is the HiPPO Effect in Simple Terms?' links to https://nousimon.com/hippo-effect/; a comment offers the one-line take: 'Yes boss, as you say' .
Hiten Shah observes that OpenRouter and Hugging Face are like Product Hunt for new AI models — i.e., the launch and discovery surfaces where new AI models get released and found .
- A senior QA engineer with 11 years across gaming, gambling, media, consulting, and crypto igaming who dislikes endless meetings is weighing a move into product; a suggested fit is an APM or junior PM role in QA-heavy teams .
- For engineers wanting product without the stakeholder/GTM meeting load, a Product Owner role is recommended: it still involves Agile ceremonies but fewer alignment/GTM meetings .
- Technical PMs are in demand at AI/tech companies; the advice for a QA engineer is to learn PM fundamentals via a book/course, document best/worst practices of PMs they've worked with, and apply directly to Technical PM roles rather than starting at junior level .
For a first B2B SaaS launch, commenter recommends DIYing the core video and spending agency money only on distribution or editing after the message proves itself; agencies become worthwhile only when positioning already converts and the bottleneck is production volume or paid distribution . Launch success should be tracked via qualified landing-page visits, demo requests, and activated trials from a unique campaign link—not views, which can be a vanity metric . Video structure: 45–60 seconds covering one painful workflow, the product doing the job, a concrete outcome, and a CTA; ship 3–5 hooks on the same body and compare conversion . A small paid test can validate signups before agency spend .
Lewis Lin's Slack community for PM interview prep, previously free and heavily used for peer mock interviews, now appears gated behind a book purchase; a user preparing for interview loops is seeking alternatives (Slack/Discord/Reddit/structured platforms) and valued the practice of posting Calendly links to schedule mock interviews with job-hunting peers . A commenter asks whether the mock interview group is still good and would buy the book if mock value is high, noting access to good PMs' time is difficult .
PMs report that difficulty at FAANG varies heavily by org, team, and time zone; one PM who moved from financial services to FAANG found it "materially more stressful, however not unmanageable," with "much higher" compensation . A general observation: "The bigger the company the bigger the politics" . A PM at a large financial institution contrasts their work with FAANG-style discovery: "Do we even do discovery stuff? We just implement or execute what comes from top down" .
Paul Graham reframed a startup's worry that 30% monthly growth was too low, noting that sustained 30% month-over-month growth would require an office 23x bigger every year .