We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Treat AI spend as a team-level investment, not a token score. A new product-management essay argues that “return on tokens” repeats the old hours/capacity mistake: teams focus on measurable inputs, favor short-term attributable use cases, and confuse ease of measurement with value. The better unit is the team: define its cost, causal model, demand, durable lane, lifecycle expectations, and validated leading proxies; use flow metrics for improvement, not investment attribution. For each AI bet, state what bottleneck it reduces, what downstream cost it may create, what durable asset it builds, and what evidence would change funding. ROI should be the output of those hypotheses, not the hypothesis itself.
Tactical Playbook
When CTR is healthy but demos are zero, recruit conversations before running a survey. One B2B SaaS campaign had decent CTR and CPC but no demos; the operator wanted 10–20 conversations with the exact buyer before spending more. The recommended sequence is 8–15 incentivized calls—prioritizing people who clicked but did not book—then a survey to measure how common the repeated objections are. Zero demos may indicate that the ad and landing-page promises do not match.
For a first or only PM, map the decision system before writing a roadmap. In a Series B onboarding thread, the useful first move was to talk to everyone, learn workflows and political hierarchies, and build trust that you can discover the “money maker.” Otherwise, the role can collapse into forwarding decisions to engineering.
Case Studies & Lessons
Fin’s AI rollout shows why productivity metrics are not the outcome. The company reported tripling PRs per person per month across R&D; 94% of PRs were Claude-authored, 19% auto-approved, product changes doubled, shipping was 39% faster, and nine major launches shipped in two months. The speaker called PR throughput crude; the strategic shift is that agents own the middle, moving PMs further upstream and making problem framing, decision quality, and product cohesion the new constraints. Apply the lesson with clear briefs, success criteria, deliberate pause points, and shared quality standards before scaling output.
Stripe channels agent capacity into customer value. Stripe says Minion-created PRs rose from roughly 1,200 per week to about 7,000, or 30% of PRs; Stripe Projects was led by a PM and senior engineer in a few weeks, and an eight-person team was doing three times more. Its stated alternative to AI-driven cost cutting is to work through unmet user asks faster. To scale quality, teams are told to use PII-free simulated accounts with realistic disputes, refunds, and seasonality—not just rely on review after shipping.
Payroll is a compliance product, not a feature. Practitioners responding to an in-house payroll question warn that US payroll spans 50 states and is either compliant or not; the inherited burden is filings, support, and maintenance after customers depend on it. First verify that customers need the capability; if embedded UX matters, one proposed route is an API partner that owns filings, compliance, and payroll operations.
Career Corner
Positive performance feedback is not the same as promotion availability. A promotion thread describes capped slots and forced curves; one candidate was one of three people deemed ready for a single opening. HR-safe feedback may require naming development areas rather than revealing that the constraint was simply slot availability. Separate what you must improve from whether a promotion slot exists, and ask what evidence and timing would actually change the decision.
Tools & Resources
Use graph engineering selectively. A 100M-token experiment tested four graph designs on 40 PM tasks: graphs won 25, but a single-node prompt won 15, including TLDR and email reply. The useful patterns were task-shaped: an assembly line for launch kits, a backward chain from metrics for instrumentation, and parallel validity checks followed by a checker that re-derives experiment numbers. The linked 40-design library is free to founding newsletter subscribers.
Stripe's AI-era product playbook
Product strategy — "win all the startups and win them again" (an endorsed phrase from Clerk's Colin): winning startups early is both a growth model and a quality engine — startups are ambitious "canaries" with the highest standards, which pulls Stripe upmarket . Enterprise needs a different sales cycle and post-sale activation, but the same principle holds: stay close to the user and be provably better on the metrics they care about .
Case study — free-trial fraud at AI companies: with software now carrying real usage costs, free-trial abuse became material — Cursor was the first Stripe customer hit, with ~1 in 6 free-trial users abusive . Stripe stood up a pipeline in a weekend using a foundation model over embeddings of the entire Stripe network plus a reasoning layer that cites signals; ElevenLabs now blocks 2,000 abusers/day off Stripe signals . Detection compounds via network effects across customers .
Velocity doctrine — founder-like agency: to ship more, Stripe optimizes the critical path from user asks to shipped product, removes centralized-process overhead, and gives everyone founder-like agency . The average AI company already uses ~11 Stripe products, and Sessions included 288 launches, across ~25–30 headline products . Resulting org shape: flatter and smaller teams with fewer orchestrating layers — Stripe Projects shipped in weeks from one PM and one very senior engineer (who now orchestrates 16 agents) , and a manager-led team of ~8 delivers ~3x the output .
Stripe Minions — one-shot agent PRs: minions take a single prompt, build it, run CI/CD and testing, then hand off for review — no planning mode or iteration . % of PRs created by minions is a key internal metric ; minion PRs grew from ~1,200/week in Jan–Feb to 7,000/week, ~30% of all PRs .
Use AI productivity to build more, not cut: Stripe rejects the "fewer engineers" path — "the best way to optimize your cost structure is to grow more"; cost optimization is finite ("going short") while building more is "going long" . Internal AI tool Kai (built by 2 people) hit 83% weekly / 60% daily actives and lifted seller productivity 20% — the response was to hire more sellers (Jevons paradox) . Evidence of the software boom: H1 signups +50% YoY; the 2026 new-company cohort generating ~50% more revenue than 2025's (which was ~70% above 2024's); the 2026 new SaaS-platform cohort 103% larger than 2025's . Leaders are still advised to create "resourcing back pressure" now, since it forces more efficient use of new tools .
Roadmap compression with agents: with agent files and templates in every repo, work hands off to agents (including code review), compressing timelines "again and again" — e.g., global filing for Stripe Tax shipped in ~1/3 the time US filing took, despite more complexity .
Scaling product quality ("taste"): two mechanisms — (1) a top-down mandate repeated relentlessly ("talk about quality and talk about it again"), and (2) actually using the product, backed by heavy investment in simulated usage: PII-free, randomized-growth accounts that feel live (disputes, refunds, seasonality) so teams experience what users experience; EMs own this and can dedicate sprints to quality .
Career path: engineers are Stripe's hero ICP and have always been some combination of engineer, PM, designer ; Stripe plans to act as an "incubator" for new grads and early-career engineers to pick high-agency user projects with paved paths . Adjacent opportunities get pulled forward: one engineer picked up spend management (roadmapped ~2 years out, adjacent to Treasury) and is building it solo .
Agentic commerce — the next frontier: agentic commerce is at the "missing primitives" stage: with Tempo, Stripe created the machine payments protocol (a service answers with a 402: "here's how you buy me") ; it shipped the Link agent wallet and Stripe Projects, which it calls a way to "provision B2B services agentically" . An agent can adopt Vercel for hosting without a human touching the website . The interviewer notes this "agents as shoppers" framing has informed their firm's recent developer-tool investment theses . Microtransactions are expected to be necessary for this economy — ephemeral, budget-constrained, one-time consumption — and are now feasible via stablecoins .
Early-stage product validation and MVP tactics from a r/startups thread where a first-time, non-technical founder asks when and how to build a team for a pre-revenue app:
- Validate demand before building: for a typical subscription app, settle a price and collect ~20 commitments to pay at launch (~6 months out), assuming ~3/4 will bail — the explicit purpose is to learn early whether the business is viable . The founder's test: free tier plus premium at $10–40/month depending on credits; get commitments now but only take payment once the product is done .
- Build the MVP before the team: 'if you can design it with AI, you can build an MVP with AI' — build the MVP, get users, and only then monetize or raise and hire with real paychecks (ideally from revenue) rather than recruiting strangers pre-revenue .
- Close skill gaps with domain experts: partner with people expert in the field who deeply understand the problem being solved; a design partner from a canvassed target business can ensure the product meets a real need and champion the launch .
- Plan defensibility, not just first-mover status: once demand is proven, a more resourced team can enter and catch up quickly, so define what makes the product difficult to compete with .
- Scope security-sensitive features for MVP: for data-sensitive products, taking money before production-ready is 'reckless' — risk of lawsuits and lost prospects without a technical cofounder; mitigate with third-party ID verification (the founder found Plaid) or by deferring verification past MVP .
- Akash Gupta's $3,000 "LandPMJob" cohort drew near-unanimous community condemnation: called a "grifter," material described as "AI shitposts," with detailed allegations of AI-generated resume reviews and 1-on-1 calls, gaslighting when students fail to land jobs, and kickback-based positive testimonials; a separate thread documents his "false claims." The OP (3-year PM aiming for tier-1 opportunities, wanting interview skills and PM fundamentals) canceled enrollment after the feedback.
- Paid prep alternatives: Product Alliance ($800 lifetime) is endorsed by a user who recruited last year as "wonderful" for cracking PM interviews and leagues ahead of Rocketblocks and Exponent; Maven cohorts vary by instructor, many being "overpriced slide decks." A $10k/3-month Alex Rechevskiy program is flagged for refusing to share details pre-payment and lacking guarantees/support.
- Interview strategy: landing interviews is ~90% of the problem; networking on LinkedIn and building GitHub side projects helped one user land interviews. For platform PM roles, side projects signal technical know-how — a FAANG interviewer even built a case around a GitHub AI project — but they're less relevant for user-facing roles.
- For product-sense practice, users recommend mock-interview repetition over passive courses: StellarPeers or PM Discords for repetitions, Lewis Lin's Slack (via his ~$20 book), LinkedIn connections willing to mock-interview, and AI as a structure/creative soundboard when practicing alone.
- Senior advice: a self-described senior product leader says PM courses/certifications get $0 value from hiring leaders; spend the money on an LLM subscription, build your own product, and tell that story in interviews. Another user suggests building an LLM-powered "self-made pm" agent for daily learning. The tier-1 gap is "execution depth and product sense under pressure," not missing frameworks.
r/ProductManagement overwhelmingly advises against building payroll in-house: the build is doable, but the hidden cost is everything inherited after launch — filings, compliance, support, and the consequences once customers depend on it . Payroll is effectively a compliance product with no "good enough" — it is either compliant or not — and US coverage means 50 states' own complex rules, garnishments, and retirement/401k administration . Practitioners cite constant oversight — "the amount of oversight required will kill your soul" , mission-critical stakes (lawsuits, employee churn), and note that part of what you pay a vendor for is liability when things go wrong .
Useful build-vs-buy heuristics emerge: delegate anything requiring constant compliance ; ask "what if we made our own scalpels?" before building ; and remember the Intercom CEO's retort to feature creep — "Yeah. But then we'd have all the problems of an analytics company" . The pattern: the idea is easy; 99% of product work is maintenance after launch .
The recommended middle ground is embedded payroll via API partners that keep the in-product experience without owning compliance — e.g., Rollfi , Check , or Gusto — which the OP ultimately endorses: "I'd rather not own the compliance side of it" . If you must evaluate in-house, start best-of-breed off the shelf, weight ease-of-integration at least 60% of the vendor scorecard, and only later consider bringing pieces in-house once stood up and talent exists . Also start with the customer problem — "Why build something complex if your customers may not need it?" — and whether it grows revenue or only saves vendor costs . The lone caveat: in-house may make sense if solving for a single jurisdiction only .
OpenAI’s Head of Design, Ian Silber, argues designers are currently the unhappiest people in tech, citing Lenny Rachitsky’s tech workforce survey: designers are the most overwhelmed, anxious, tired, and least likely to recommend their role. He attributes this to engineers seeing 10–100× AI productivity gains while designers haven’t, because design is inherently messy (try, fail, gather feedback, realign the org).
Silber: nobody has the new design process figured out—including people inside OpenAI—so nobody is behind; the best response is constant experimentation with AI (throw ideas into an agent at the very start, prototype, re-test constantly), because what didn’t work yesterday might work today. “I strongly believe this is the best time in the world to be a designer.”
For overwhelmed teams, Silber’s counterintuitive advice is to do less: extend an existing feature, build on an existing component, or question whether the thing needs to exist at all. The skill he says is becoming most important is systems thinking—building primitives that compose into a cohesive product.
ChatGPT serves the widest audience spectrum in history, so OpenAI operates on capability overhang: keep the mainline experience extremely simple, put cutting-edge features where the people who care will find them (desktop app, Codex), and only distill something into the default once it no longer requires a mode or switch.
PM/engineering/design roles are blurring but not going away; at any real scale you still need people responsible for different things, because one person who can design, engineer, align a company, and rally teams is vanishingly rare.
Silber’s hot take: AI is already an incredible product designer—not better than humans at visual design yet, but broadly great and accessible to everyone. Humans retain the edge where there’s no training data: understanding what people need, watching them use things, and inventing new paradigms (multi-touch, Instagram feeds, disappearing messages).
OpenAI designs at two speeds: for ChatGPT (over 1 billion users) they “try 100 things, and we throw out 99,” with full A/B testing and user research; for other things like much of Codex, they go from idea to ship in four hours, building in public for instant feedback.
The “super app” vision is one universal input that knows when to answer quickly, chat, or go do the work; the north star is that users shouldn’t have to think about how it works, which model, or speed—expose controls only for those who need them, make the default great, and make the experience more proactive (richer voice, interactive visual outputs, durable workflows).
Even the head of design at OpenAI initially felt bad at the job; his advice is to be humble about how early this all is, have fun, and focus on the outcome, and to find an impartial mentor/buddy outside the company to turn imposter syndrome into shared, solvable challenges.
Talent market mismatch: Commenters report oversupply of inexperienced grads and shortage of experienced/specialized talent at startups, with startups increasingly seeking veterans over juniors . One founder says 99.9% of applicants want high-paying 9-to-5s and prefers leaving roles vacant over hiring a non-perfect match ; startups also need people willing to wear multiple hats and accept low pay plus equity, which most aren't . A dissenting view says no real shortage—companies just demand 'unicorns, cheap, 10~15y experience, 150iq, PhD' . One estimate: 90% of startups suffer a talent shortage, deeper in deep tech; a robotics startup lost a second CTO in 12 months to a 400k+ offer .
Compensation/equity math: Startups pay ~30–50% of big-tech salaries at senior levels; equity is 'lottery tickets' that only make sense for VCs who pool risk across many startups. Fractional talent engagements at comparable hourly rates are an alternative, but harder to land and short-term .
Career progression contested: One commenter argues you become less replaceable after 3–4 years and 'totally indispensable' after ten if driven ; others counter that being indispensable likely means you're doing something wrong and that after 10 years you may be replaced by younger, cheaper staff .
Hiring for attitude: A founder advises 'hire for attitude, train for skills,' preferring new grads with strong mindset/character over experienced technical hires who don't fit startup culture; leadership character provides job security regardless of industry .
Deep-tech specialization strategy: For early-stage deep tech, bring demonstrable domain knowledge (e.g., CS double-major in the field, open-source/thesis project). Frame searches as 'what company is doing deep tech in the area I have deep knowledge in,' since tight funding and long revenue horizons mean companies won't take flyers on unproven candidates .
Finn (formerly Intercom) tripled R&D productivity within a year of going all-in on AI-assisted development (PRs per person/month across design, research, engineering, and PM): 94% of PRs authored by Claude Code, 19% auto-approved, 2x product changes, 39% faster shipping, and nine major launches in two months.
AI compressed iteration cycles from weeks to days and enabled parallel streams; new bottlenecks are non-technical — problem framing, decision quality, judgment, and product cohesion.
PMs and design move further upstream to strategy and roadmap; design also works downstream on front end; engineering owns larger end-to-end projects. Design shifts from gatekeeper to orchestrator, building shared infrastructure (design systems, Surge Intelligence codifying taste for Claude) and codifying quality so anyone can ship high-quality work.
Agents displace UI: navigation, settings, and dashboards disappear; users shift from managing the product to approving agent output. PMs should ask what's left of their product when AI handles the jobs it was designed to do.
Advice for builders: get hands-on AI fluency; make AI capability a shared organizational standard with infrastructure; be obsessively clear on goals and success criteria; codify taste and standards so quality scales; and shift focus from shipping speed to 'should this exist?' and product coherence.
"Return on tokens" echoes old measurement failures. Companies that gave up on value architecture are now fixated on token ROI, repeating the same problems as hours and capacity: more effort on the "I" than the "R" of ROI, myopically picking short-term attributable use cases, and gravitating to whatever is easiest to measure — tokens are very easy to measure and give a "beautiful meter and invoice" that creates a much stronger illusion of a usable ROI denominator .
Why hours fail as an investment metric. Time isn't fungible across skills, team context, or time of day (an onboarding expert can't be swapped into legacy backend work; the "magic hour" of morning productivity ≠ 4–5 PM); allocation says nothing about quality (ten people × ten hours ≠ one person × one hundred hours); context switching is multiplicative (alternating two tasks every ten minutes for six hours costs at least three hours switching); time→outcome is non-linear (the ninth hour can unlock all the value); long-term focus compounds (5% longer per enhancement to pay down debt leaves a team "absolutely flying" three years later but is unbookable); and allocation buckets are causally related, not mutually exclusive .
Flow metrics and story points. Cycle time, lead time, WIP limits, and throughput are "helpful, when focused" and remain required learning for product developers — but mainly for continuous improvement (optimizing around a demand type, finding waste and bottlenecks) . Manufacturing assumptions misapply though: "classes of service" segmentation is required or metric changes just reflect mix changes; product work is R&D-like where waste buys knowledge ("try five things and one works"); work units and system boundaries are mushy (lead time from when? done when merged, deployed, or adopted?); capacity is an emergent quality of system design, not a fungible spend; the metrics presume a stable flow system that exploratory work violates; and story points should be only a disposable tool to spark discussion or reality-check a near-term cycle commitment — "Any effort to use story points [beyond that] is a dereliction of duty" .
Alternative: team-level causal business cases. The only ROI framing that works is keeping the cost side broad and applying rigor to the causal model: (1) treat the team as the cost unit ("This team costs roughly $1.5M per year") rather than decomposing into hours, points, or features; (2) connect each team to at least one causal model linking actionable inputs and leading indicators to mid- and long-term differentiated growth; (3) be explicit about the types, sources, and variability of demand a team serves; (4) fund durable lanes of focus over one-off projects; (5) maintain a standing team business case (causal assumptions, proxy validity, expected returns, uncertainties, change triggers) that transcends projects; (6) evaluate by business/product lifecycle — emerging idea, scaling product, and margin optimizer should not share the same expectations; (7) judge return through movement in validated proxies — "Are we more or less confident about this value hypothesis?" — rather than attributing revenue to individual units of work; (8) use hours for time leakage and flow metrics for continuous improvement, never as the investment proxy itself .
Tokens vs. human capital. Comparing a $50M AI/token investment to people surfaces seven tensions: employees create organizational capital, knowledge, and institutional memory beyond assigned outputs; salaried labor is committed/fixed cost while tokens are variable cost; AI spend leaves durable assets (code, data, workflows) only if the organization captures them; marginal vs. average returns (the first $1M of AI spend targets obvious high-value use cases, the fiftieth is marginal; premium models complicate this); returns depend on complementary assets — in augmentation the relevant system is human + AI; cheap generation moves bottlenecks downstream and creates overproduction; and a cheaper/faster build is not necessarily a cheaper asset since most software economic consequences occur after production .
AI business cases should state the theory, not the ROI. Instead of "We will spend $10M on AI and generate $30M of value," a serious case answers "What theory of the system are we betting on?" via ten explicit hypotheses (e.g., using AI for will reduce without materially increasing ; AI will augment/replace resulting in ; increased AI-enabled production can be absorbed without excessive ; downstream costs of AI-generated stay below ; a premium model produces enough additional _ to justify the premium). ROI is then the output of the hypothesis, not the hypothesis itself — "extremely important given that everyone is learning at the moment. No one has figured this out" .
Team + AI as one investment. Teams should be able to frame themselves as "we cost $1.5M a year in salaries plus $1M in tokens — what is our business case here?" The same demand/causal-model/durable-lane logic applies, and this kind of business case may be a prerequisite for giving teams meaningful responsibility for AI spend — so they can make intelligent tradeoffs between people, models, tools, and other capacity .
OpenAI Head of Design Ian Silber opens up to Lenny Rachitsky: he calls designers the unhappiest people in tech , then explains why he still believes this is the best time in history to be a product designer, makes the hot take that AI is already an incredible product designer, and describes how OpenAI designs at two speeds . Silber also argues there's no training data for the next great product idea: 'Models learn from what already exists. Everything we're doing is trying to design something that's never existed before' . The full conversation is at https://youtu.be/BV0hy6NET-U.
B2B customer-validation playbook — a B2B SaaS ad campaign with decent CTR but zero demo bookings signals a need to validate the target buyer (mid-market CS/onboarding leaders) before spending more budget, via 10-20 direct conversations within ~$1K .
- Treat it as a recruiting problem, not a survey problem: use B2B panels (User Interviews, Respondent), screen for exact titles, pay per-session incentives; ~$1K buys roughly 8-15 conversations, enough to hear objections repeat .
- Interview people who clicked the ad but didn't book; decent CTR with zero demos usually signals the ad promise and landing page promise don't match .
- Sequence matters: interviews first to surface real objections, then a cheap survey to quantify how common each objection is; survey-first gets confident numbers about the wrong questions .
- Alternatives offered: route own ad traffic to a survey link placed where the demo CTA is to catch non-bookers, or niche B2B panels (Respondent, User Interviews, Wynter) ; QuestionPro was ~$1K when last used in 2021 .
Founders who outsource development often discover at handoff that they don't control their own infrastructure—GitHub, cloud accounts, databases, domains/DNS, app store/API credentials, deployment knowledge, and backups sit with the old dev/agency. The fix: own all accounts and keys before work starts , and invite hired devs to your projects rather than giving them sole ownership ; a ghosted dev left one client without its production database, costing the first week and a half of live users.
Handoff surprises are almost never the code—typically a domain/DNS in the old dev's personal registrar, API keys tied to personal accounts, undocumented deploy processes, and backups that were never test-restored. Catch these with an end-to-end operational walkthrough while the old dev is still reachable.
Recovering access and transferring infrastructure typically takes one day to two weeks; devs bill for transition work such as new deploy scripts, server setup, and testing, and require written approval if it comes up after the estimate.
When onboarding a new developer, audit the git history for previous problem areas, architecture/planning, security (unsecured endpoints/exploits are common), and scalability for 100 vs 1000+ users, including load balancing and database sharding.
Before switching agencies, ask whether you actually need new developers or just someone to manage the process; switching is costly, so try repairing the relationship first. If you do terminate, stay professional, get the code first and logins second, and withhold final payment until accounts are transferred. Vet the replacement team with technical help, since founders often hire a new agency just as bad as the old one.
Outsourcing caveats: outsourced development is "the surest path to burning runway for nothing but pretend progress" unless a competent technical owner who can review code-level implementation is managing it; a great technical co-founder is called "not optional", and a mediocre one "almost the worst possible outcome". Outsourcing an MVP is defensible only as a throwaway that will be rebuilt for production.
Despite positive feedback, PMs often miss promotions because companies cap the number of promotions per cycle and forced grading curves mean only a subset of qualified people are promoted . In today's low-hire, 'job hugging' economy, promotions are even harder: low churn means openings don't appear, especially with layoffs and flattening, and the assumption that 'N years at level A → promotion to B' is not how the process works .
A director explained that when delivering 'almost but not quite' feedback, HR requires naming at least one specific development area and forbids candid reasons like only 1 of 3 candidates getting a slot or relative tenure, for lawsuit defensibility — so the stated feedback can hide the real constraint . His own case: he was 1 of 3 ready for Senior Director with one slot, didn't get it, and the subsequent merger later eliminated all Director+ roles .
Career tactic: one PM left to get promoted, advising a free-agent mindset — move when you hit a ceiling or when income isn't growing every two years, since not all companies promote and waiting to be rewarded keeps you behind .
Morgan Brown, reflecting on Hacking Growth nine years on, argues AI has made marketing execution "approximately free," but velocity was never the real scarcity in growth — alignment between product and marketing was. AI doesn't fix misalignment, though it collapses org charts and turnaround time dramatically .
He identifies idea validation as the 2026 constraint: models can write headlines, set up tests, and design ads, but nobody knows if an idea is good enough to stand out or work; while AI increases shots on goal, bad ideas still carry real opportunity cost .
Brown reports that at Instagram, 75%+ of growth work was fixing bad UX, errors, and broken features, not big experimental swings — yet most practitioners still bemoan the lack of big bets, undervaluing compounding improvements .
Hiten Shah notes companies have terrible institutional memory for past experiments: a test fix gets forgotten, and six months later the same idea resurfaces with no one knowing it was tried. He suggests agents can retain that context so the next loop starts where the last one ended .
Wispr Flow raised $280M in Series B funding at a $2B valuation led by Menlo Ventures; its founder observes that in a little over a year, voice input shifted from being widely doubted to relied on, with users reporting time savings from talking vs. typing. Alongside funding, they previewed Canto, a 2B-parameter proprietary speech model trained for real-world acoustic conditions (loud rooms, wind, background noise, mixed languages). The roadmap is a rapid succession of larger speech models, each intended to deliver a noticeable dictation improvement, toward the founder's five-year vision of voice as the primary device interface — a category he claims doesn't exist yet.
Hiten Shah (@hnshah) countered the argument that every layer of the AI stack — models, IDEs, harnesses, app builders, wrappers, inference providers, voice layer, data labeling, infrastructure, neoclouds, generative media — is moatless, with only the venture firm exempted , asserting that the only moat in AI is brand .
- For early-stage first VC meetings, lead with an engaging story of the problem and solution, not metrics: VCs assume first-meeting numbers are inflated, and a 30-min meeting can't substantiate them; keep data ready only to answer questions .
- Recommended early-stage deck order: opening story, team, problem, solution, why now (unique insight), market size and path to 10x, product, distribution, competitors, ask + use of funds; leave the tech stack out entirely. Investors assess conviction and grit on vibes in 30 min, so aim to leave them feeling good about you .
- Know revenue, growth, retention, CAC, runway, margins, and next milestones cold, and remember VCs look for 10x+ returns . Also vet the investor: later-stage-focused VCs give worthless pushback for early-stage founders .
- One experienced operator's counter-framework: before the meeting, answer whether and why you need funding, how much, and ensure the person is the right investor; then open the call by asking about the fund, check sizes, and target areas, deliver a 5-6 minute pitch, and leave 10 minutes for questions — you control the meeting .
A solo pre-seed founder shared a shutdown post-mortem: 7–8 months of building at 70–80 hrs/week, shipping everything imagined, then shutting down with zero paying customers — "the build was never my bottleneck," the failure was never proving anyone would pay before building . The same thread's OP, seeking grants/credits for an AI subscription to build, was told "you need more traction" . Community guidance: traction means people waiting for a product because it solves a real problem, and it can be demonstrated before any product exists via a website, an offer, and a waiting list with a timeline . A commenter argues GTM matters more than the idea or anything you build .
First-time PMs joining as the only PM at a Series B startup should focus on building trust and understanding the organization, not just mechanics. One practitioner warns that "first PM is a dangerous place to be" because founders and engineers are used to making decisions, so you must quickly assess whether you're acting as a real product manager or just a project manager .
The core advice for the initial days: talk to everyone, learn the workflows and processes, and map the political power hierarchies—who has been making decisions and who currently does . If you fail to build trust that you are the one who can discover the "money maker," you will be reduced to a product owner who receives decisions made without you and spends 80% of time forwarding them to engineering .
APM program eligibility for 2025 grads with 1 year of full-time technical experience: most APM programs accept this profile, capping experience around 2 years, though Google's program is basically new-grad-only; Meta RPM and others take people with 1-2 years of experience. A technical background is a strong asset for these roles. The one catch is programs with hard graduation-date cutoffs, so applicants should check each posting before investing time .
Founder-led customer discovery: framing cold outreach as validation rather than sales — e.g., "I built this thing and I'm ringing round to find out if I'm wrong about who needs it" — earns more gatekeeper pass-through and genuine interest because it's true and doesn't sound scripted; people are far kinder to founders than to hired reps . Before optimizing a discovery script, plan for a few hundred conversations — a few calls are too small a sample to judge whether one opener works better than another .
r/ProductManagement comment by u/Ok-Bee2272
Planning to take LandPMJob with Akash Gupta - any feedback?
I plan to pay tonight as cohort starts tonight. Its about $3000 want to hear from those who actually took the course, what is their feedback?
Also if anyone has alternative courses that are better I’d appreciate it. I’m a PM by role (3 years) but aiming for tier 1 opportunity so want to up skill my core skills and also Interviewing skills
UPDATE: NO LONGER PAYING FOR THIS COURSE. thanks for feedback, please suggest alternatives. need structure and accountability, has anyone done the maven courses?
his writings come across as AI shitposts. dont waste your time and money.
- Akash Gupta's $3,000 "LandPMJob" cohort drew near-unanimous community condemnation: called a "grifter," material described as "AI shitposts," with detailed allegations of AI-generated resume reviews and 1-on-1 calls, gaslighting when students fail to land jobs, and kickback-based positive testimonials; a separate thread documents his "false claims." The OP (3-year PM aiming for tier-1 opportunities, wanting interview skills and PM fundamentals) canceled enrollment after the feedback.
- Paid prep alternatives: Product Alliance ($800 lifetime) is endorsed by a user who recruited last year as "wonderful" for cracking PM interviews and leagues ahead of Rocketblocks and Exponent; Maven cohorts vary by instructor, many being "overpriced slide decks." A $10k/3-month Alex Rechevskiy program is flagged for refusing to share details pre-payment and lacking guarantees/support.
- Interview strategy: landing interviews is ~90% of the problem; networking on LinkedIn and building GitHub side projects helped one user land interviews. For platform PM roles, side projects signal technical know-how — a FAANG interviewer even built a case around a GitHub AI project — but they're less relevant for user-facing roles.
- For product-sense practice, users recommend mock-interview repetition over passive courses: StellarPeers or PM Discords for repetitions, Lewis Lin's Slack (via his ~$20 book), LinkedIn connections willing to mock-interview, and AI as a structure/creative soundboard when practicing alone.
- Senior advice: a self-described senior product leader says PM courses/certifications get $0 value from hiring leaders; spend the money on an LLM subscription, build your own product, and tell that story in interviews. Another user suggests building an LLM-powered "self-made pm" agent for daily learning. The tier-1 gap is "execution depth and product sense under pressure," not missing frameworks.