We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Agent products need an architecture audit, not just a compelling demo. Aakash Gupta’s checklist spans eight layers— infrastructure, agent networks, protocols, tooling, cognition, memory, application, and governance—and names three failures: building everything instead of buying selectively, jumping straight to the app, or forgetting a layer. For PMs, his test is to identify the neglected layer and focus the team there; at the application layer, perfect one workflow rather than a feature monster. Apply it as a launch review: assign an owner and evidence to each layer, especially tool execution, memory, monitoring, and compliance. Surface-level usefulness can conceal a system that cannot reliably act or ship.
Consumer AI has an authenticity problem. Andrew Chen contrasts work—patterned drudgery that AI compresses—with consumer experiences, where people seek novelty and parasocial connection and reject “slop”; he says the same adversarial-creativity challenge appears in sales and marketing. Treat novelty, distinctiveness, and human judgment as product requirements where sameness destroys value; do not measure a consumer AI experience only by automation or output volume.
Tactical Playbook
Make discovery a three-way pressure test. A PM/design thread proposed lightweight designer-led research for A/B hypotheses and pre-build discovery. The useful operating model was to bring a designer and lead engineer in as early as possible, jointly validate business goals, and welcome pushback—while keeping scope and time constraints explicit. For each candidate problem, have the trio state the hypothesis, run a small customer check, define what evidence would change direction, and agree the time-to-market boundary before requirements. This preserves collaboration without recreating a waterfall or feature factory.
Case Studies & Lessons
OpenAI uses two design tempos—and treats failure as input. Ian Silber, OpenAI’s head of product design, says some ChatGPT features try 100 ideas, discard 99, and use research and experiments, while Codex and the “super app” build in public, take big swings, and learn quickly; some ideas go from idea to ship in four hours. At Instagram, he says IGTV was a huge flop because the team baked in wrong assumptions and constraints; changing those and iterating produced Reels. Use deep validation for durable, core surfaces and fast experiments for reversible ones; the important output of a launch is what to fix next.
A vertical AI service makes trust part of the product. A Canadian lawyer reports an AI-native firm using its own playbooks, AI first-pass drafting and redlining, versioned audit trails, commercial data terms, and lawyer review and signoff. It offers flat fees and 48-hour turnaround, and says its first month, not yet closed, is tracking to low-to-mid five figures. The firm sells legal work directly to startup and SMB clients rather than software to law firms. The founder’s warning is broader than legal: a polished agreement can still be wrong for the company or jurisdiction. In high-trust workflows, provenance, human verification, and domain checks are features—not post-launch cleanup.
Career Corner
Build the “shaping the build” muscle. Andrew Ng’s map, based on more than 10,000 job postings, expert interviews, and surveys, names four AI-engineering skills, including “shaping the build.” He says that means product sense, business context, customer goals, and judgment about when to ship an MVP versus build carefully. Shreyas Doshi highlighted that product-sense line. For PMs, make this visible in your work and portfolio: show the customer problem, the scope and tempo choice, and how you steered the build. Silber’s hiring rubric points in the same direction—curiosity, prototyping, a point of view, strategic thinking, and systems thinking.
Distribution, not code, is the differentiator. r/startups commenters largely agree that a nearly finished product is no longer the asset in an AI-coding world: "90% and 85% done is really ~50% done on the product side and 5% done on the selling side," and an almost-working app is "worth very little in a world where I can vibe-code my own in a week or two"; "if neither of you knows how to sell then this is a moot point anyway" . A dev running a fully agent-built webapp (~$7k MRR for ~2.5 years) concludes "distribution, not code, is the last remaining moat ... Code is 'mostly' solved," except for deep tech, B2B, and security, which shouldn't "just go on vibes" . In a niche, "the asset is who gets to the customers first and who sticks around after the first churn wave" , and only "a fraction of a fraction of a percent" turn a build into a business - "AI hasn't changed that" . B2B caveat: direct sales is "one of the most humbling experiences," needing thick skin and phone calls, versus B2C where platforms drive most sales ; one founder says they pay a specialist B2B-sales co-founder more than themselves .
Completion claims are "founder math." "95% done and 85% done is founder math for not done. The last 15% is the part that actually hurts - onboarding, billing, support, sales. Neither of you has a product yet, you have two demos" ; a vibe-coded working demo is "2% there in terms of success" .
Vibe-coding quality is contested. Skeptics: anyone vibe-coding "with no clue how anything works ... will not be a success," with makers correcting daily mistakes from Claude and Codex - "pure vibes aren't a sustainable business model" ; models still produce "ridiculous architectural designs" and rate "pretty decent as an MVP" only . Counter-cases: two companies "built completely on Claude code with zero issues" ; a $7k-MRR consumer app run end-to-end by agents on ~$300/mo infra plus ~$400/mo AI subscriptions ; a vibe-coded tool reportedly at 250K ARR . Recurring pattern: domain expertise, not the tool, decides. One founder's vibe-coded MVP "was just breaking everywhere" and AI fixes "degraded over time," forcing a tech co-founder when the tool approached ~10 clients; success required knowing the intended behavior and required data, not just the idea . Evidence caveat: a claimed ~$100k profit from a 3-month-old vibe-coded site was contradicted by its author's own post 25 days earlier stating "$0 in revenue so far" .
Technical debt gets paid post-cash-flow. Startups "run on duct tape and thread until it bites them" - one sold vibe-coded marketplace even passed diligence, but "payment processing is the last thing I want a pure vibecoding anywhere near"; companies typically "ironed out ... spaghetti and improved infra post series A" once they have cash flow .
AI cost curves re-open shelved products. The OP shelved a 95%-built project two years ago because its AI tech was "too expensive at the time in order for it to be profitable"; with AI progress, the same product became viable again .
Silber sees PM, design, and engineering roles blurring but remaining distinct: at large companies, dedicated PMs still add value by rallying teams, sharpening the problem space, and handling resourcing; if starting a company today, he would hire generalists who can fluidly span roles .
OpenAI's product strategy for ChatGPT uses the concept of "capability overhang": most users get only a sliver of the product's potential value, so they keep a simple, streamlined experience for the many while making cutting-edge features accessible to power users, experimenting early via desktop app and Codex before distilling into the main experience .
Silber: AI is already an incredible product designer, but humans retain unique value in understanding user needs, inventing new interaction paradigms (e.g., iPhone, Instagram, Snapchat), and having a point of view about who they're building for and why .
When hiring, OpenAI doesn't require an AI background; it looks for high curiosity about AI, prototyping ability, a point of view, strategic thinking, and increasingly systems thinking (relevant as models compose primitives) .
Career advice: Silber felt like he was failing daily after stepping into his role; he advises finding peers in similar transitions to counter impostor syndrome, recognizing everyone is early in the AI shift, and focusing on outcomes rather than process .
Failure lesson: Instagram's IGTV was a huge flop due to baked-in wrong assumptions; the team learned quickly, changed approach, and shipped Reels successfully — reinforcing that reacting, fixing forward, and iterating on user feedback matter more than any single release .
OpenAI's design process varies by feature: for some ChatGPT features they try 100 ideas and ship one with obsessive iteration; for others (e.g., Codex, the super app) they ship fast and build in public for rapid feedback .
- A product designer asked PMs whether designers should run lightweight customer research to frame better A/B test hypotheses (fewer experiments, saved resources) and run lightweight discovery research before building .
- Top-voted PM response: bring designers and a lead engineer into discovery as early as possible; this nearly always produces better results than product/design/eng working in sequence with rigid boundaries, but PMs should calibrate sophistication to scope/time and Product often shields teams from internal pressure .
- A 10-year designer's playbook: the PM-designer relationship changes product velocity more than almost anything; good PMs bring designers into discovery, validate business goals jointly, and welcome pushback; bad PMs act as project managers, run feature factories, and keep waterfall role splits; best partnerships are role-interchangeable with high idea volume, and cross-craft learning builds empathy and product instinct .
- Recurring PM friction: designers blocking on 'page too busy' or 'doesn't fit our design system' or taking a quarter for three basic pages; PMs want design trade-offs framed in money/business terms, and the OP designer agreed .
- Counterpoints: constraints are a personal trait, and vague scope makes design exponentially slower; designers should optimize user goals while respecting business/engineering constraints, with PM owning business objectives; PM-design tension often comes from PMs forced into project-management roles .
- In a sentiment survey of tech workers, designers and user researchers are the most unhappy on every dimension - most overwhelmed, anxious, least optimistic, most worried and tired, and least likely to recommend their role to newcomers .
- OpenAI head of product design Ian Silber says design hasn't seen engineers' 10-100x productivity gains because the process remains messy and feedback-loop dependent, leaving designers uncertain about what's expected of them - a key source of the unease .
- People thriving in the AI shift feel amplified by AI, are curious, make time to explore, and are adaptable; OpenAI doesn't require an AI background in new designers but hires for curiosity and aptitude to learn how to use the tools, plus prototyping, point of view, strategic thinking, and systems thinking .
- PM, design, and engineering roles are blurring, but Silber still sees a valuable role for dedicated PMs at scale - rallying multiple teams, sharpening the problem space, and handling resourcing - while a startup should hire generalists who can fluidly move between the disciplines .
- On AI as a product designer, 'it already is an incredible product designer' and accessible to everyone, though not yet the best at visual design, hierarchy, typography, or UX; the durable human edge is understanding user needs, running human feedback loops, inventing new things, and having a point of view .
- OpenAI's design process is split: for some ChatGPT features the team obsesses and tries many options before shipping one; for other surface areas (e.g., Codex, the super app) they build in public, take big swings, and learn quickly - spending design effort where the technology is durable, with some ideas shipping in hours .
- To keep up with speed, Silber's guidance is 'do less': don't design if you don't have to - reuse existing systems/components, extend existing features, and think beyond your immediate scope .
- Product strategy for ChatGPT spans casual users (recipes) to professionals (automating farms): the team operates on 'capability overhang' (most users get a sliver of the product's potential), keeping a simple, streamlined experience for the majority while making cutting-edge capabilities accessible to power users; they experiment early with engaged users (desktop, Codex, ChatGPT Work) before distilling into the main experience, and the long-term goal is one universal input with no mode/model decisions, plus more proactivity and voice .
- Career advice: it's still very early - nobody has it figured out, what didn't work before can work now, and every new model is better than the last; find peers/community to counter imposter syndrome, and focus on outcomes/output rather than process .
- Failure case: Silber's IGTV at Instagram was a huge flop, while Reels later succeeded after the team recognized wrong assumptions, dropped constraints, and iterated quickly - 'fix forward' and listening to users matters more than any single launch .
- Practical AI use for creative leaders: Silber uses ChatGPT/Codex to instantly visualize and prototype early ideas before team conversations, and uses AI operationally to summarize Slack messages and prep context for meetings and recruiting .
An AI-native law firm for Canadian founders/SMBs, launched by a Canadian lawyer with 25 years of contracting experience (former GC and CEO) , runs on a model — loosely based on what Crosby and General Legal are building in the US — where AI does the first pass on every matter, drafting and redlining from in-house playbooks; every draft is versioned with an audit trail, and the lawyer reads, corrects, and signs everything before it goes out; flat fees, 48-hour turnaround, and commercial terms so client data isn't used to train models . The founder chose to build the firm AI-native from the start, convinced AI would fundamentally change how businesses work with legal . It is live serving SaaS agreements, contract negotiations, and employment work, with first-month revenue (month not yet closed) tracking to low-to-mid five figures and constant demand . Positioning: unlike Spellbook, which sells legal AI software to lawyers, the firm uses software to deliver legal work directly to clients, with no plan to sell its platform .
Reviewing a high volume of startup contracts exposed consistent problems in template- or AI-generated agreements — with the framing that AI isn't bad at legal work, but an agreement can look polished and coherent while still being wrong for the company using it . Three recurring risks relevant to product teams: (1) agreements built for the wrong jurisdiction — e.g., Canadian contracts containing US at-will employment, CCPA, or GDPR-heavy language; practical fix: tell the AI your jurisdiction and specifically ask it to flag provisions assuming a different one ; (2) IP ownership — in Canada, independent contractors own the copyright to code/design unless there's a written assignment, so a freelancer who built an MVP years ago may still own part of the IP, typically discovered only in diligence; verify the company can prove ownership of everything contractors built ; (3) liability caps often carve out indemnities, IP, confidentiality, and data obligations — the useful question is 'what isn't covered by the cap?' rather than just the cap amount .
- Multiple commenting PMs see paid AI PRD tools like ChatPRD as unnecessary: general LLMs with custom prompts/skills cover the use case, some report poor tool quality, and one bluntly calls the category a bad idea .
- A counterargument: ChatPRD filled a real gap before agent skills and gave guardrails/integrations that offer time-to-value for teams not equipped to build their own LLM stack — though the same commenter tried it for two months and stopped .
- The tool's value splits by org size: individual artifacts can be handled with markdown files and custom skills, small/mid product/tech/design teams gain from out-of-box workflow integration, and enterprises will likely build internally; the integration moat is fragile since GPT/Claude can connect to any tool .
- One commenter speculated Atlassian avoided a native equivalent to protect Confluence/Jira and floated token-based estimation replacing story points .
Andrew Ng published The AI Engineering Skills Map, built from 10,000+ job postings, dozens of structured expert interviews, and survey data, naming four most important AI engineering skills: building and deploying AI applications, software engineering fundamentals, using coding agents, and shaping the build . The 'shaping the build' skill is the most product-relevant: as coding agents improve at delivering to a spec, engineers' work shifts to deciding what goes in the spec, and effective AI engineering requires product sense, understanding business context and customer goals, and knowing when to ship a quick MVP versus slow down to build more carefully . PM leader Shreyas Doshi (ex-Stripe, Twitter) endorsed exactly this line, signaling that product sense is becoming a core skill for AI engineers .
PMs seeking faster career growth: switching jobs is cited as the easiest route to promotion, though riskier; internal advancement typically comes from a sudden opening or deliberate job hunting, so discussing career path expectations with your manager early reveals whether internal growth is realistic .
Don't measure your value by LinkedIn promotion posts — focus on enjoying the role, gaining exposure, and continuing to ship ("You stop shipping and you’re dead") .
One PM's rapid rise (PM → Senior → Principal → VP in 3 years) came from luck, showing up when it mattered, aligning with leadership, and playing politics ; however, another PM warns such fast trajectories read as "startup BS" on a resume without substantial pre-PM experience .
Title and scope vary widely: a FAANG staff PM reports $650k total comp while peer "directors"/Sr PMs earn ~$350k, and some "directors" managing 0–2 people earn ~$250k .
If internal advancement stalls, plan the next step with your manager; if they can't help or the company isn't growing, start looking externally — without a big win or fast-growing company, the next internal jump takes a long time .
Andrew Chen observes that AI has taken off at work but not in consumer apps because work follows patterns and removes drudgery, while consumer attention demands novelty and authenticity that AI "slop" undermines .
- At work, much activity is drudgery (forms, processes, updates, boilerplate review) that needs many steps and data-stitching; AI compresses these so humans focus on high-leverage steps .
- In consumer domains (social, video, dating), people crave novelty and parasocial relationships and are wary of AI slop; a distorted AI artifact can ruin authenticity, and novelty is hard because AI pattern-matches the past in training data .
- The same "adversarial creativity" problem applies to sales/marketing: novel messaging and competitive move/countermove require going outside the model—no one wants same-sounding AI cold emails or AI slop software .
- This may be an inherent human-in-the-loop problem; future AI that observes and reacts in real time (e.g., ingesting the last 24h of X activity) might finally generate novelty .
Instead of free first projects to get testimonials, offer a small paid pilot: fixed scope at a discount, with a case study and reference commitment agreed upfront; free clients give slower feedback and fewer referrals . A more structured approach is to sell a paid diagnosis before the platform build: identify one recurring business decision that is delayed or error-prone because data lives in spreadsheets/legacy systems, have the buyer show the report or handoff they struggle with, deliver a map of the broken path plus a scoped first fix with the cost of inaction, and credit the diagnosis fee toward implementation if they proceed; prospect with observable triggers such as a new operations leader or system migration . Positioning matters: business users don't see a data-pipeline problem and may not connect their pain to broken pipelines, so the actual buyer may be developers who understand pipelines — e.g., a company parsing contract data currently using Claude API would care about a better solution . Validate demand before building: if no one in your circle would want the product, that's a bad sign ; for a small team, enterprises are slower/harder to sell into than SMEs .
- Hiten Shah argues that as AI agents take over more software implementation, engineering scarcity no longer forces prioritization; "can we build this?" is becoming a boring question and the key product question becomes "should we build it?"
- Rather than cloning competitor features, decompose the mechanic underneath the feature — e.g., a pull request is a visible work proposal with attached feedback, async inspection, approval-based state change, and persistent history, a mechanic that transfers beyond dev to AI-generated work, marketing, finance, design, legal, ops, and research. Stories worked because the mechanic lowered creation pressure, made consumption easy, showed who watched, enabled replies, and drove re-sharing
- Implementation approach: first define the behavior that matters for your product (attention for Meta; trust in agents for AI products; marketplace trust; evidence-to-decision in analytics; context handoff for team software), then hunt for proven mechanics that create more of it. Run the learning loop: see something, understand what's underneath, hypothesize why it matters, build the smallest test, measure, and keep the learning regardless of outcome
- AI can scale this by watching product launches, changelogs, demos, reviews, complaints, open source, and App Store updates, decomposing mechanics and suggesting how they translate to your product, with another agent building the prototype
- As building gets cheap, judgment, taste, knowing which behavior matters, understanding why something worked elsewhere, and knowing when to leave the product alone become more valuable; ruthless prioritization matters more because teams risk becoming "extremely good at building bad ideas quickly," creating bloated products
- Meta's Little Red Book already encoded an early version of this: ruthless prioritization, keep shipping, "the quick inherit the earth," code wins arguments, everything up for debate; Hiten is re-reading it for 2026 lessons
Lenny Rachitsky's podcast episode features Ian Silber, OpenAI's Head of Design, discussing why designers are the unhappiest people in tech and why he still thinks this is the best time in history to be one . Topics include his theory for designer unhappiness, why it's the best time to be a product designer, his hot take that AI is already an incredible product designer, how OpenAI designs at two speeds, and his views on craft, taste, and what will be left for humans . Episode: https://youtu.be/BV0hy6NET-U.
- A r/startups post on YC's declining value-add argues that when almost everyone can ship quickly, domain judgment becomes substantially more valuable — industries like insurance, defense, healthcare, institutional finance, and manufacturing still require years of accumulated context . It predicts accelerator pattern-recognition from the SaaS era transfers poorly into a world where any competent founder can produce an impressive AI product within weeks .
- A commenter in enterprise healthcare describes a common PMF failure pattern: startups design without understanding real clinical workflows, fail on edge cases and EHR integration, and sales teams sell an idealized state that customers tear apart; they fail to get referenceable sites and eventually run out of money. The advice is to connect with skilled end users and admins who know the current systems' pain points, and to integrate with existing systems of record rather than adding another standalone app .
- On building products with AI, a commenter argues an LLM can develop a product concept, but the industrial experience needed to market, position, distribute, and grow a scaled SaaS product is irreplaceable; enduring businesses solve deep engineering and product design problems, citing Atlassian's flywheel growth model and Figma's real-time collaborative canvas as examples .
Hiten Shah (@hnshah) says he has lost count of the problems he has solved by walking away from the computer, framing the walk as part of the work, not a break . He shares this in support of a quoted post from @NTFabiano: "You are one walk away from a better day" .
Shreyas Doshi (@shreyas) cautions that while AI should be used wherever possible, it won't save you from building the wrong thing — i.e., AI doesn't prevent product-market fit mistakes .
r/ProductManagement commenters affirm that membership strategy work — developing tiers and value propositions, analyzing member needs/pain points, improving the membership journey and experience, retention, NPS, engagement, pricing, and segmentation — qualifies as product management even outside typical tech products . One commenter defines a product as anything made, grown, or provided to satisfy a need or want — physical, digital, service, or algorithmic result — and states that whoever oversees the strategy, development, and continuous improvement of a service is a PM for a service-based product . The thread also notes that product management is a loosely defined area, with transferability from non-traditional domains such as telco membership roles .
Framework from Aakash Gupta for building AI agent products, structured as 8 architectural layers:
- Infrastructure: APIs, cloud infra, data storage, vector databases — buy the best instead of building from scratch, and focus on orchestration
- Agent Internet: multi-agent systems and communication protocols; build ecosystems where agents discover and coordinate with each other, not isolated agents
- Protocols: communication standards (A2A, MCP, ACP, ANP, TAP, AGORA); pick proven protocols or agents burn credits talking past each other
- Tooling: RAG, function calling, code execution, external APIs — determines whether the agent can actually do things; most agents fail here
- Cognition: planning engines, decision making, error handling; build explicit reasoning chains to avoid hallucination
- Memory: working memory, long-term storage, user preferences; without persistence every interaction starts from zero
- Application: what users see; start simple and nail one workflow instead of building feature monsters
- Governance: deployment pipelines, monitoring, compliance; plan from day one — 'your demo becomes a $100K liability if you can't ship to enterprise'
Three failure modes: building all 8 layers instead of strategically buying, jumping straight to the application layer, and forgetting a layer entirely . For PMs, the prompt is to identify which layer the team isn't thinking about and guide them to focus there . Full technical diagram and implementation guides at https://www.news.aakashg.com/p/ai-agents-pms.
Founders in r/startups describe how AI is changing early-stage product building. The thread's premise: nontechnical founders can now build prototype SaaS without engineering experience, build faster, apply RAG to Claude for automation, create marketing collateral easily, and feed lossless call transcripts into automated systems . Reported uses include contracts (saving legal costs), Excel problems, understanding Twitter's algorithm, and program content — though AI content still needs a human pass to clean up "AI speak" ; contracts and Excel are called the underrated time-savers . A recurring view: AI moves the bottleneck from execution to deciding what is worth doing. One person can now span research, prototyping, analyzing customer conversations, writing collateral, building internal tools, and structuring data; but cheap building makes judgment more important — you can build the wrong product quickly, automate a bad process, or generate convincing strategy around a bad assumption. The guardrail: deliberately don't build things that wouldn't answer the underlying business question; validate assumptions and know when to stop . Similarly, AI gets you to judgment faster, not past it — useful for first drafts of copy, cleaning messy notes, and checking your own thinking before committing; using AI as a co-founder for actual decisions is a red flag . A practical workflow: start with a source and a pass condition; use AI to compare a draft against its research or check repetitive work, personally review customer-facing claims and external actions, and keep the source beside the output because a new customer call, metric, or product state can make a polished artifact stale . Build speed is real but coordination is the hidden job: shipping a prototype in a weekend is easy, while keeping five parallel AI-written workstreams from contradicting each other is "the actual job" and isn't automated . One CTO reports coding is no longer the bottleneck — they code faster than ideas come, so extra time goes to user response and marketing support .
AI/vibe-coding tools (Lovable, v0, Replit, Cursor) let non-technical founders ship MVPs without coding; AI agents ask questions that force explicit product and business-logic decisions. A cheap stack is Claude + GitHub + Cloudflare Workers, and the recommended path is to "create an mvp" and "level up when you have traction" .
Professional app development realistically costs "tens of thousands USD just to get started": senior devs earn $10k-$25k per month, and a first version may need 4-5 developers for a couple of months. Anything cheaper is a compromise with risks—unusable output, delays with demands for more money, or code being reused by the developer .
Even with vibe coding, an app with a large user base or complex business logic still needs senior engineers for system architecture, scalability, security, and observability .
Founder guidance: don't worry about idea theft—"99% of them are unremarkable"; execution is what matters, so keep market research, interested customers, and funding sources secret instead .
An early-stage founder is seeking validation for an "Event Collector": a small smart tag that tracks movement and, optionally, temperature and humidity, with an AI platform classifying events—door/fridge/mailbox use, object movement, unusual activity—rather than requiring specialized sensors per use case . The founder asks whether it solves a real problem and which use case is strongest (consumers, businesses, warehouses, maintenance, elderly care, rentals), explicitly wanting to avoid building technology before finding a problem . No validation data or outcomes are provided.