We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI-native teams need product judgment at engineering speed. Oji Udezue describes engineers adopting AI and moving roughly 10× faster while PMs continue discovery and strategy at the old pace, leaving product as the bottleneck. His ProductMind system addresses the layers often missed by engineering-focused AI tooling: 17 skills cover business and product work such as finding problems, deciding what to build, creating value, monetization, direction, and execution. The important design choice is the use of gates: because LLMs rarely say no, a skill can stop the next step and replicate a piece of PM judgment rather than merely asking a PM to edit the output afterward.
Agent value is moving toward data-rich workflow platforms. Aaron Levie argues that if agents generate 100× more code, process large datasets, and make decisions across systems, the platforms managing that data and work become more important—not less; governance, security, compliance, guardrails, and safe data access are part of the product. Scott Belsky makes the related case that a “teamwork graph” improves the efficiency and accuracy of both work and agent actions, while Hiten Shah reduces the strategy question to who controls the data. For PMs, model choice is only one part of the roadmap: define the context, permissions, workflow state, and control surface the agent can safely use.
Tactical Playbook
Put a no-build gate in front of AI-generated features. ProductMind’s Sharp Problem Test asks:
- What do people do today? An easy workaround means there may be no problem.
- How many people have it, and how often? Daily use can outweigh a market ten times larger with monthly use.
- Will anyone pay? Check what they already spend on the workaround.
Fail one question and kill the idea; require a 3× improvement over the current alternative before expecting switching. The associated 11-step scaffold deliberately keeps its first four steps away from code and produces research and product artifacts before implementation.
For B2B discovery, convert interest into a small commitment immediately: when real pain surfaces, ask on the first call whether the prospect will review rough versions. Then ask who can grant access to the relevant ticketing systems or logs; “I’d have to ask” is research about the buying path, not pilot readiness.
Case Studies & Lessons
The Savannah Bananas turned observation into the roadmap. The team videotaped fans and saw them leaving early; the evidence suggested the three- to four-hour game was too slow, so the plan changed from being a conventional baseball team to creating a faster show. Jesse Cole’s advice is behavioral rather than survey-led: put ideas into the world and watch what fans do. The team then tested “banana ball” behind closed doors—nine innings in 99 minutes—accepted that the first version was chaos, and expanded only after fans stayed more than an hour after a show.
The business model reinforced the product test: sell tickets rather than depend on sponsors, progressing from two tickets in the first three months to 4,000-seat sellouts. They still price tickets at $40–$60 with no fees and run a face-value resale market, despite secondary-market prices above $200, prioritizing fan trust over immediately extractable revenue. The PM pattern is clear: observe behavior, prototype narrowly, set a behavioral threshold, then scale—and treat pricing as part of the product promise.
Career Corner
Make judgment visible in senior interviews. Shreyas Doshi says interviewers can learn a lot from the questions candidates ask and points to the subtle cues hiring managers often miss. Prepare questions about decision context, constraints, trade-offs, and what has failed; the question phase should show how you reason, not only what role you want.
Tools & Resources
- Agent Plugins: OpenAI and partners introduced an open format that packages Agent Skills and MCP server configurations so one plugin can work across compatible agent clients. Treat portability as a product requirement for internal agent capabilities.
- PM AI workshops: Lenny Rachitsky’s Head of Education is running free workshops with Cursor, Replit, PostHog, and Supabase on using popular AI tools in day-to-day PM work; registration is available through the linked course page.
- LLM output quality depends on context: models predict next words within a context window (standard ~1M tokens) and drift when one session mixes many topics; without your world-context the AI won't connect dots or prioritize what matters .
- Give an AI the same briefing you'd give a new expert PM — who you are, career stage, how the company decides, your product, customer, and pain — and set behavior explicitly: ask it to guide/teach rather than do the work, especially if you're early in product .
- Case study (investment decision): with context, the assistant rejected the framing — the product had been invested in twice, and both failures were activation problems, not product problems (clients bought but didn't use it); it inferred this from meetings/history before pulling data, and the analysis was kept auditable in sheets with raw tables, formulas and queries as single source of truth .
- The same context-aware assistant served as a communications coach: it applied the Pyramid Principle (start with the conclusion), cut a ~20-minute verbose explanation to ~10 minutes, role-played CFO/HR questions, and produced a presentation the executive audience received well .
- A context-rich assistant moves beyond reactive summarizing: it builds meeting agendas from past meetings, flags items overdue 7 days, detects repeated status slipping, suggests escalation to your leader, and coaches how to open the conversation based on your past style .
- AI returns time, but PMs must choose what to do with it — a week spent running queries produced no decisions; and per Karpathy, you can outsource thinking but not understanding: always be able to explain and verify AI outputs because they propagate errors and wrong decisions .
- Practical AI memory: a markdown file/folder used with Claude Code (CLAUDE.md) works as well or better than memory SDKs (one cited article found no SDK beats plain markdown/text); start with a page covering who you are, how the company decides, your product/customer/challenges, and growth areas .
- AI PM-assistant demo: told that sales closed an 80-restaurant chain and promised an Excel export in the client's format with contract signing Friday, the assistant answered: "the date isn't the problem — sales sold roadmap scope without you and a committed date ratifies that sale," then gave framing questions/responses .
- Builder shift: AI lowers the building barrier for everyone; the hard decision becomes what to build, so product fundamentals and customer-pain focus matter more. The "PM Builder" — owning the path from idea to built product and P&L — is the emerging direction .
- Spec-driven development: use AI to build but invest in a precise spec that follows codebase patterns and keep human PR review — this is what makes AI-written code maintainable. At Stone, a Vibe Flow spec-driven plugin is used on real products and produces code indistinguishable from the existing app codebase .
- Team/career in the AI era: juniors are fluent in AI tools but lack judgment; senior PMs should keep investing in mentoring/coaching and shift from teaching how to build to teaching how to understand/evaluate (via PRD/spec/review standards, shared example prompts, and a product toolkit); product vision/mission/principles remain decision-making context tools .
- Token costs are forcing P&L ownership: spend is now visible per person/team, and Uber's CEO said the company burned its yearly token budget in a quarter without knowing ROI; experimentation is the easier ROI frame, and tooling costs are expected to keep rising .
- Handling AI-inflated top-down pressure: ground yourself in customer evidence/data (a good but not infallible shield); don't dismiss ideas — use negotiation with documented risks, apply 5 whys, sometimes run the experiment to build goodwill; experiment cadence is rising, with Silicon Valley Product Group citing ~6 experiments/squad/week .
- Use AI as a sparring partner and skill provider: one OLX fraud PM asks "how can you help me" and uses Kiro to autonomously run data analysis and low-fidelity prototypes, making her work deeper; best results come from asking AI to question/retort rather than just validate .
- Nir Eyal walked through the Hooked model for habit-forming products: four steps — trigger, action, variable reward, investment — repeated in cycles; retention ROI from bringing users back is far higher than acquiring new customers . He distinguishes habits (behavior with little or no conscious thought) from addiction (persistent compulsive dependency that harms the user), and argues that most entrepreneurs' real problem is users not using products enough, not products being too addictive .
- His implementation guidance (applied to an audience member's retirement-planning wealth app for women): start with a behavior that occurs at least weekly, since more frequent behaviors are more likely to become habits (context: average smartphone user checks their phone 150x/day) . Then find a frequently occurring internal trigger — all products serve one need, mood modulation; the candidate triggers are boredom, loneliness, fatigue, uncertainty, anxiety, stress — couple a contextually timed external trigger to it, keep the action simple, add a variable reward (variable reinforcement, as in news, sports, gambling, day trading; learning something new is itself a reward), and design the investment phase .
- The investment phase (user input that makes the product better with use) is the "biggest opportunity," especially with AI-driven mass personalization to a market of one; habit-forming products appreciate with use, and if you don't do it, competition will . TikTok is the exemplar: boredom trigger, open-app action, low-friction variable feed, and the feed improves via dwell time, scrolling, likes, and comments .
- Eyal developed Hooked after hypothesizing that shrinking screens made habit formation more important; the model became a Stanford GSB course and his investment filter (Canva, Kahoot!, Eventbrite) .
- For leading teams and sustaining motivation, he says motivation is a triangle of behavior + benefit + belief; beliefs are malleable "tools, not truths," and changing others' beliefs starts with leading by example .
- Nikita Bier is stepping back from leading product for X and will continue on as an advisor; he cites running the app being a 24/7 job and needing "to take a breather" .
- He reports unprecedented growth in new users and engagement, record-breaking months, and a 70-spot climb in the App Store since this time last year .
- Over the last 400 days, his team rebuilt almost every aspect of X (Timeline, Android app, onboarding, notifications, chat) and launched nearly 30 new products, including being the first app to show Country-of-Origin on profiles and mounting defenses against AI bots .
- Successors named: @benjitaylor on design, @singhai on core product engineering, @dinkin_flickaa on mobile engineering .
- Lenny Rachitsky — noting Bier "doesn't believe product management is real" — praised the run as "world-class product management" and floated having him back on the podcast to share lessons learned .
- Germany PM hiring has shifted heavily to generative AI: 80%+ of open roles are for, or heavily consist of, generative-AI feature ownership, and they all want prior experience launching "AI" features (usually cookie-cutter chatbots) while traditional ML experience is disregarded; remote roles are virtually gone, and a 15-year PM is considering leaving the country or the profession.
- Job searches are brutal: a 10+ year PM searched over a year, went through 5-7 interview loops more than once, and companies either closed roles or never hired; in one stretch only 2 of 7 companies hired. Another Sr PM remote search ended after six rounds and a take-home when leadership switched to requiring all new hires in office, despite the hiring manager wanting to extend an offer. One PM did receive two technical PM offers in a week after many interviews.
- AI is moving the delivery bottleneck to PMs: with AI plus an extra dev, a 2-3 month project shipped in half the time, devs stopped underestimating, and the PM now feels like the bottleneck.
- Executives pressure PMs to "let AI do the work" but show Gell-Mann Amnesia: a convincing AI prototype is treated as proof to go faster, yet the same "I did this in an hour" excuse holds when it's shown to fail usability.
- Agentic-AI mandates can clash with customers: leadership wants an "agentic product," but customers want deterministic outcomes, rules followed 100% of the time, no hallucination risk, and no chat interface.
- Capacity pressure crowds out discovery: PMs oscillate between scramble-to-fill capacity and "not now" to every request, leaving no space to pause and think about the what and why.
- Leadership behavior undermines execution: last-minute direction changes before launch force teams to deliver in 1/5 the original time; PMs also report orders to build a "solution" with no problem to solve and a lack of leadership direction/support.
- Career sentiment is poor: an 8-year PM says they never really loved the role and mostly feel stress, first mentally then physically, in a corporate context; another simply doesn't want to be a PM anymore.
- Jesse Cole (Savannah Bananas) runs an SNL-style idea and experimentation system: an "idea box" for crazy ideas, Tuesday all-day idea sessions, table reads, and rehearsals to produce a brand-new show weekly. Mindset: "We just try things. We experiment. Some work. Some don't." Examples of experiments: grandma beauty pageant, flatulence fun nights, garbage-can nachos .
- Customer discovery by observation, not surveys: the team videotaped fans, noted they left early, and concluded the 3-4 hour game was too slow; they pivoted their plan from "be a baseball team" to a faster show. Cole: "Don't do surveys, just actually go do it." They also watch reactions to "millions" of social posts and think about future fans' wants 3-5 years out .
- Behind-closed-doors prototyping: tested banana ball (9 innings in 99 minutes) privately before launching; it "never works right away" and "always starts as chaos," then iterative refinement found the magic; scaled only after fans stayed an hour after a show .
- Business model anchored on a product people pay for: "if people don't want to pay to come see it, we had to make a product that people wanted to pay and come see." They funded growth through ticket sales rather than sponsors/advertisers . Early struggle: two tickets sold in 3 months, sold their house, and pushed to opening night with "get to your next bat... swing hard" .
- Marketing: zero dollars on marketing; instead invest in the experience and make it so remarkable that it can be captured and shared; social media amplifies it .
- Fan-first pricing trade-off: despite consultants and secondary-market prices averaging $200, they keep tickets at $40–60 with no fees and built their own face-value secondary market, absorbing the cost, to deter scalping and preserve long-term trust over short-term revenue .
- Measurable results: after the pivot, sold out 4,000-seat college venues nightly ; fans stayed an hour+ after shows ; Party Animals have more TikTok followers than every MLB team, and 170,000 joined the waitlist for Detroit; four tickets alone could sell out 8 straight nights ; Local Beach Coconuts merchandise ranks #2 .
- Career advice: "Do what gives you energy" — Cole identified his best days involved creating, sharing, and growing, and built an "energy list" around those three buckets .
- Scaling structure: split creative and operations like Walt and Roy Disney — Cole focuses on creative; his president Jared handles operations with a "we'll figure it out" mindset; new needs (ticketing platform, trucking logistics across 75 stadiums/45 states) are built in-house .
- Brand extension risk: with six teams, Cole fears dilution and invests millions per show to keep every team distinct; the danger is fans thinking "it's just another one of the banana teams" .
- Product advice to other platforms: LinkedIn should lean into what makes it different rather than copy TikTok/Instagram ; the PGA should break rules, let fans and golfers have fun, and test one tournament with music, entrances, and celebrities — purists will hate it, but it may draw a new audience .
AI agents as a knowledge-work multiplier. A YC partner reports ~400x coding output versus 2013 (from ~14 lines/day) with AI agents; even after a "pathological verbosity penalty" the floor is ~8x. He explicitly says the multiplier applies to design, product management, and growth . YC's Winter 25 batch: a quarter of startups had 95% AI-generated codebases and use AI agents for everything, and the batch is on track to be among the fastest-growing and most profitable; he cautions it's correlation, not proof, but the fastest-growing founders treat AI as a workforce rather than autocomplete — leverage comes from context, not model weights . Agents are how one founder now does "unscalable" things at scale .
Skill files as an executable methodology. A skill file is a page of English instructions an agent can run; the test is whether a smart intern could follow it. "Markdown is actually code — the compiler is a language model." Non-engineers at YC (finance, media, event staff) build skill files and scheduled jobs; one finance person compiled ~100 Excel workbooks into a single app she built with an agent . Key architectural principle: separate latent space (taste, judgment, vague requests) from deterministic space (arithmetic, SQL) — markdown files calling databases and scripts (e.g., custom schedules for 6,000 attendees required deterministic code) .
Five-step adoption plan for personal AI. (1) Pick a harness (OpenClaw/Hermes with GBrain, or Claude Code, Codex) and run on your own machine. (2) Start a library: one folder of markdown files, export notes/email, one page per project/person. (3) Write your first skill file for the weekly task you hate most, iterating on errors. (4) Wire it as a recurring job (e.g., every morning). (5) Never do one-off work — ask the agent to "skillify" each task into a reusable skill file. Trajectory: week 1 toy, week 4 flywheel catches, week 12 library answers before you finish asking .
Career ownership and hygiene. "Own your skills because if you don't, your job becomes a skill file." Example of a support engineer who taught agents 40 skills over two years; if files live in her repo she compounds, but if under company IT policy she leaves with nothing while the company keeps running her judgment . An uncurated brain is "a garbage dump with great search" — retrieval surfaces stale facts with confidence. The primitive is memory plus hygiene: provenance, contradiction checks, and pruning; treat the brain like production infrastructure .
Product philosophy. "You can build exactly the tool you need for the audience of one in a weekend... scratching itches is nearly free," and some personal tools become companies — you'll know when other people beg for them .
Shreyas Doshi (@shreyas) posted that interviewers can learn a lot about a candidate from the questions the candidate asks during the interview process for any senior role, noting that CEOs, founders, and hiring managers often miss these subtle cues; the post shares a linked video deep-diving into the topic (https://youtu.be/FkWl1TsObcE) .
AI product teams choosing between open-weight and proprietary models are driven by control (over model behavior, latency/SLA, and the ability to extend or guardrail) and, increasingly over the last few months, cost pressure from expensive coding plans and skyrocketing token spend . Open-weight serving offers finer performance/cost trade-offs than closed APIs: providers can offer up to ~10 speed levels versus regular/fast modes, Kimi K3 in fast mode reaches ~400–500 tokens/sec (2–3x faster than current proprietary fast modes), and open models are often cheaper, with a near-10x gap cited; users also gain control over performance, data retention, security, and compliance . Open-weight licensing is evolving from Apache-2-style permissiveness toward commercial funding mechanisms — Meta's DAU/ARR thresholds for Llama, MiniMax's usage-based terms, and Kimi's derivative-works terms exemplified by Fireworks/Cursor — with sustainability compared to pharma R&D funding . At the frontier, the capability gap vs closed models is no longer seen as decisive; distribution/go-to-market strategy and training environments, including recursive self-improvement loops, are the next differentiators .
The "9 out of 10 startups fail" axiom is unsourced: the most-linked citation chain runs 2015 Forbes → 2014 Fortune → nothing; Startup Genome's 2011 report asserts "more than 90% of startups fail" with no citation; and the trail dead-ends at a 1975 Dun and Bradstreet report that never contained the number . Actual data: roughly half of new businesses survive five years and about a third survive ten (SBA); Shikhar Ghosh's study of 2,000 VC-backed companies found ~75% never return cash to investors — a claim about investor returns, not survival — while only 30–40% actually liquidate . The one frame where 90% holds is VC portfolio math: a company can be alive, profitable, employing fifty people and still count among the nine because it didn't return the fund; funds price every deal expecting one or two winners and "budget for" the failure rate they then observe . A commenter adds the portfolio view works because the winners can cover losses — e.g., a16z returned ~22% on average to investors .
Founders and investors define "success" differently: TechStars described "zombie" companies as those with expenses exceeding income and no obvious remaining scale path, kept alive by founders doing side consulting; investors must count that as a failure state, but founders need not — a lifestyle business is very much alive, it simply isn't what the VCs wanted .
The thread author argues Steve Blank's customer development cycle — four phases (have the idea, validate it, grow, then build a stable company) with a startup as a temporary entity searching for a business model — is obsolete because it assumes search is expensive, that search has an end goal, and that executing the validated model is the right move . In markets that "get spun up and die in months not decades," success measured by movement along that curve stops making sense ; the durable company stays formless and keeps searching, and AI has made running continuous experiments much cheaper .
- Oji Udezue, CPO at Typeform, Calendly, and Parsable and currently running ProductMind, observes that PMs are speeding up their orchestration skills to match engineers' new AI speed but not speeding up their product judgment .
- He frames every company as three layers — business, product, code — and says having skills only at the bottom (code) layer is a huge gap; he open-sourced his ProductMind skills library (17 skill files) covering the product-development stages that require PM judgment: finding the problem, deciding what to build, getting people to value, making money, setting direction, and running the work .
- Two distinctive design principles in his skill system: (1) a project scaffolding skill that runs an 11-step workflow whose first 4 steps never touch code, ending with a market research doc, product brief, project-specific CLAUDE.md, folder structure, tests folder, CI wired up, and secrets in .gitignore; and (2) "gates" — built on the fact that LLMs rarely say no, skills include hard stops that tell you no and replicate real PM judgment .
- Example gate: the "vet-a-feature" sharp problem test — three questions, fail one and the idea is dead: what do people do today instead (an easy workaround means no problem); how many people have it and how often (daily beats monthly at a tenth of the market size); will anyone pay (check what they already spend on the workaround). The bar: you need to be 3x better than what they do now, or nobody switches .
- Udezue's bottom line: with AI, the scarce skill is no longer building something but the judgment to choose — what he calls "Taste at Speed"; you cannot prompt your way to it or hire an agent to hold it, PMs must own it, always apply judgment on top, and not ship AI slop .
Lenny Rachitsky's Head of Education Colin Matthews is running a series of free AI workshops over the next few weeks, in collaboration with Cursor, Replit, PostHog, and Supabase, teaching PMs how to use popular AI tools in day-to-day work; sign-up at https://maven.com/lls/36baf5.
Deb Liu (who worked on Facebook Marketplace) maps community-trust dynamics onto team culture: high-trust teams give each other the benefit of the doubt, share credit openly, and treat mistakes as information, while low-trust teams transact — protecting scope, hedging commitments, and secretly negotiating with other teams . She warns that "in-group trust" — tight, defensive loyalty within a pod — masquerades as strength but merely moves the low-trust problem down a level and stalls cross-team collaboration, since depending on outsiders feels risky . Her mechanisms for building high trust on teams: repeated small interactions where people do what they said they'd do, over big declarations or mission statements; proximity that keeps people specific rather than abstract (trust breaks down when teammates become job titles or Slack handles); transparency as a default — one team she led had a rule to "say the thing, in the room, out loud," banning side conversations and quiet lobbying; and leaders going first by taking the first risk and admitting the first mistake . The real question for a team isn't its current trust level but whether the circle of trust is expanding or contracting day by day .
PMs on r/ProductManagement disagree on paths into product: one says 'there isn't a main pathway anymore'; another lists BI/data analyst, data scientist, management consultant, marketing, operations, and customer success as viable routes; a third argues software engineering or Technical GTM (4–5 years) are better bets than BI or design, which are 'probably least likely' to get there; and one PM started as a product specialist .
A 10-year PM shared job-hunt benchmarks: ~450 applications since May → 12 screening calls → 7 initial interviews → 4 final interviews → 4 offers; each application took 10–15 min, ~100 hours total, and he estimates a PM without experience should budget ~300 hours (30–40 days of full-time effort) .
Career tactics from the thread: take a job over no job/gigs; get resume help and interview practice from someone with real product experience; keep resumes clear, succinct, and non-AI-generated — using AI only for canned interview answers — because being 'decidedly not AI' stands out in this market .
Another commenter advises optimizing for major hubs (SF, NYC) and choosing a team where you can prove yourself and transition to product — small enough for flexibility or large enough for internal mobility; relocation makes this significantly easier .
OpenAI shipped updated 5.6 sol and 5.6 luna models to ChatGPT's plus/pro and free/go tiers, unifying the instant experience and maximum intelligence into one model with a slider for the speed-vs-comprehensiveness tradeoff; the merge had been a goal since its reasoning models first shipped two years ago . Kevin Weil (VP Science, OpenAI) called the ship "a big deal" .
- AI evals for MVP are best treated as an extension of acceptance criteria: instead of binary pass/fail, define a range of what good looks like, often via request-response pairings that show good output .
- Community analogy: evals are "almost like unit tests for AI features" , refined as using ranges of success rather than pass/fail goals .
- Practical guidance: always start with eval data; you generally need hundreds of rows (human-annotated eval) to tens/hundreds of thousands (LLM as a judge), evaluated as the team creates new model checkpoints .
- For quick MVP evals, use LLM-as-judge backed by a human-annotated golden set as the quality reference, but building the golden set takes time .
- Eval workflow: initially synthesize what good looks like; later, once the app or agents have observability, use traces to identify good and bad examples, and use both to train the model or improve the application .
When a product's core value comes from elsewhere (e.g., a streaming app whose catalog/player drive value, not discovery), PMs may question whether to freeze development; the honest answer is sometimes yes . In such cases, "keeping the lights on" (bug fixes only) can be valid for critical infrastructure or simple flows, but it should be part of a portfolio that also includes higher-value initiatives .
Before declaring a product "done," lean on analytics to see what customers actually value, then get Finance involved: if the next dollar invested is unlikely to yield a dollar back, the product may be a cash cow that deserves maintenance, not expansion; remember every new feature postpones break-even. Sometimes the smartest strategic roadmap is no roadmap — redirect top performers to the next opportunity (BCG Matrix thinking) .
Cut underused features ("vampire hunting"): they consume engineering time, QA cycles, support costs, documentation, training, security, cognitive load, and block opportunity cost. If a feature isn't "paying rent," evict it .
Software never fully coasts: security, technology, user expectations, regulation, and browser standards change, so maintenance is ongoing care. But framing it as "maintenance mode" can be "hospice" — ambitious PMs/devs/designers may leave, hastening decline; consider rebranding it as "Renaissance Mode" to keep the team looking for ways to rebirth the product .
Case study: on a large GovTech product, the team kept the existing version running with periodic bug fixes while completely overhauling the product, then cut over; in another engagement with heavy-weight customers, they maintain the legacy product as-is as long as paying customers remain while working on a ground-up rebuild strategy .
Career guidance: PM'ing a "feature complete" product is fine for an entry-level PM; experienced PMs should be transparent with management and look for another role . If nothing exciting remains, it may be time to move on — but first test your assumption: would a different person in your role also conclude there's no opportunity? Also, avoid over-improving products merely to keep teams busy; after growth, many teams could shrink, but managers resist losing influence .
An alternative to freezing: pivot to growth work — finding new users, rethinking pricing — especially in startups/smaller companies .
Product lifecycle framing: after maturity comes saturation and decline (the "long tail"); keep costs and overhead below revenue, and when that's no longer possible, it's time to "turn out the lights" .
- Pre-MVP founder building dining-room floor-visibility software for restaurants; discovery interviews found floor operations run on owner memory with no data, yet owners keep objecting "we're not busy enough" .
- Before building, determine whether a pain is worth solving by quantifying its cost/risk: how much money is lost, what getting caught for a legal risk costs, etc. .
- A genuine pain is one the customer already experiences and is aware of; invented "improvements" are not pains, and customers won't pay for something they don't perceive as costing them money .
- If the product tells owners what they already know, it's not solving a problem; data must become actionable intelligence that increases profit margin .
- Having to convince prospects they have a problem before any customer is a strong signal of no market demand; such persuasion only makes sense when extending from proven traction .
- With independent restaurants, "we're not busy enough" usually means "no money this month" — the same answer they'd give for anything that isn't an oven; also, floor data that staff have to manually enter stops being entered within two weeks .
- Discovery exercise: have owners score a list of pain points (hiring, training, accounting, scheduling, ordering, staffing) on pain/frustration and business impact (1-7 scale) to build a heat map; low pain/impact scores mean no opportunity .
- To get owners to feel pain: either run a free pilot and ask what it's worth afterward , or build around a problem they're already unsuccessfully trying to fix; a case study from a believing restaurant can educate prospects .
- Better targets are restaurants with demand (long waiting lists/lines), not the average local spot; mom-and-pop pain concentrates on staff behavior, while chains run by numbers-aware operators fit optimization products better .
- The "babysit the pilot" wedge can burn ~12 hrs/week per local client and stall everything else after the first yes .
- Offline desktop software still has a path in 2026 for niche professional markets where latency, privacy, offline access, and reliability matter more than browser delivery ; it remains valuable for applications like word processing and spreadsheets, and for specialized domain software such as medical device control, though the industry is moving cloud-first .
- The SaaS vs. offline decision is primarily a monetization and product-evolution trade-off: SaaS delivers recurring revenue (MRR), ensures paying customers always get new features, and smooths upgrades, while one-time offline purchases create uncompensated feature work and jarring version jumps . B2B purchasing norms (support renewals, bundled IT, operating cost) make subscriptions the default for business buyers; B2C can still support one-time sales .
- The main obstacles for offline desktop are distribution, updates, compatibility, and piracy: solo developers struggle to distribute, bug fixes require shipping new installables, and "works on my machine" issues plague support . Requiring a server connection for core features can reduce cracking but must be validated against the target persona .
- SaaS fatigue creates openings for offline alternatives: users tired of subscriptions will switch, and small teams can profitably serve them (e.g., Sublime Text with >$6M/yr revenue on a 2-person team) .
- Bottom line from the thread: solve a real problem users will pay for rather than chase the trendy model , and validate the idea before committing . For business tools that save companies significant time, a recurring or subscription price (rather than a one-time $20) better captures value, while consumer tools can remain simple buy-and-use offline products .
PMs advise being honest with a data-backed "No" in case study interviews: the verdict isn't graded, the reasoning is — a sharp, well-defended "No" beats a shaky "Yes" . Structure the answer so the "No" is the middle, not the end: present the data, recommend what you'd do instead, and state what would need to change to make it a "Yes" — that last part separates independent analysis from bias . The alternative path can be a modification of the original plan that course-corrects on the data rather than a full pivot . If the solution worked for some customers, dig into segmentation and LTV — a targeted build may still make sense . For delivering "No" to a stakeholder, listen first to understand their goals and stance, then pick a category of "No" (timing, value, technical risk, etc.); if they're neutral or against, shift to exploration/negotiation or deliver a soft no backed by a request for data that would revalidate the work . Avoid listing reasons without connecting to the stakeholder . Note: companies rarely use interviews as free consulting, so don't over-index on that concern ; a "No" may actually be the test — companies can be looking for a PM strong enough to push back on a bad exec idea .
OpenAI and partners (AWS, Cursor, GitHub, Visual Studio Code, Vercel) introduced Agent Plugins, an open standard that packages Agent Skills and supports MCP server configurations in a shared format, so a plugin built once works across compatible agent clients . Hiten Shah called this long-awaited, noting that Skills already had a shared standard and now plugins do too, making one plugin work across compatible AI platforms and increasing the number of plugins worth building .
How Open Source Became AI's Backbone | Inferact with a16z
AI product teams choosing between open-weight and proprietary models are driven by control (over model behavior, latency/SLA, and the ability to extend or guardrail) and, increasingly over the last few months, cost pressure from expensive coding plans and skyrocketing token spend . Open-weight serving offers finer performance/cost trade-offs than closed APIs: providers can offer up to ~10 speed levels versus regular/fast modes, Kimi K3 in fast mode reaches ~400–500 tokens/sec (2–3x faster than current proprietary fast modes), and open models are often cheaper, with a near-10x gap cited; users also gain control over performance, data retention, security, and compliance . Open-weight licensing is evolving from Apache-2-style permissiveness toward commercial funding mechanisms — Meta's DAU/ARR thresholds for Llama, MiniMax's usage-based terms, and Kimi's derivative-works terms exemplified by Fireworks/Cursor — with sustainability compared to pharma R&D funding . At the frontier, the capability gap vs closed models is no longer seen as decisive; distribution/go-to-market strategy and training environments, including recursive self-improvement loops, are the next differentiators .