We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Reviewing AI-drafted PRDs
An r/ProductManagement post asked a practical question. When Claude or ChatGPT drafts a spec, how do engineering, design and leadership review it, and how do their changes get back into the source? The replies agreed on one point: the reviewed document lives in a tool people can read and comment in, not in the chat.
- Write first, then use AI as a critic. One PM writes the PRD by hand in Confluence so they don't "outsource my thinking." Then a dedicated Rovo agent checks it for structure, missing scenarios, weak assumptions, risks and edge cases .
- Human gate plus a ticket trail. Another PM reviews and usually rewrites the AI output, which they rate as about 97% accurate. They then assign a functional lead to review it second. Comments go on the ticket, a new version follows, and the result is broken down in sprint planning .
- Don't sync every comment back automatically. One commenter has the AI draft against a single human-readable document. Comments stay open until the owner accepts them, and only then does the agent update the doc and show a diff. Otherwise feedback "turns into scope before anyone has made the call" .
- Agent summaries. One team gives each opportunity brief its own Slack channel. An agent fleet summarizes the disagreements and changes at the end of each day .
- Counterpoint: reviewers often aren't reading PRDs anyway. They paste them into AI. So tell the story with a prototype and keep a shorter document explaining why and what .
Agents in production create new work
Hiten Shah asked who will be "the IT person for everyone's AI agents" when a paid-for agent "quietly stops doing its job" a month later. His bet: agent builders may create more demand for support than they remove . In an r/startups thread about agent infrastructure, commenters made a similar point. Observability and orchestration are crowded, and the gaps are in permissions, audit trails and cost control. Those needs show up only in production and are best found by talking to teams that already deploy agents . Two specific discovery prompts came up. First, how do teams reconcile a CRM write when the tool call times out and a retry might create a duplicate ? Second, why did teams that evaluated tools decide not to buy: security review, data residency, integration, or no budget owner ?
At a Masters of Scale debate, Signal's Meredith Whittaker said a consumer agent that books a party needs contacts, payment, browser, calendar and messages, and that following instructions found in text makes prompt injection serious. She cited cases involving Copilot, Perplexity's agentic browser and Google Calendar . Her conclusion was that trust has to come from verification . Her opponent answered that risk depends on the agent, the use and the access requested. He mostly lets agents read online rather than write , and he advises small steps, tiered access and verification . For PMs building agents, the design takeaway is to scope permissions narrowly and disclose clearly what data the agent touches.
Product Hunt opens to agents
Product Hunt released a version where builders can launch via MCP and find competing products. Operators can search more than 500,000 apps, and investors can filter startups with a proprietary model that predicts Series A likelihood . Shah noted that nearly 25,000 makers launched on Product Hunt in October. That fits what he told Ryan Hoover in 2019: shipping is getting easier and making a product work is getting harder .
Discovery hygiene
- Idea repos go stale because nobody revisits them, whatever the tool. Give each idea a revisit date and review it in an existing planning cycle. Archive any idea that comes up twice with no new evidence . One team organizes the repo by problem, with quotes and tickets as evidence underneath. Duplicates merge on their own, and planning becomes ranking problems by evidence . Another adds a one-line success criterion to each idea, which later becomes the acceptance criteria .
- Your ICP is a guess until customers prove it. One founder built for B2B SaaS, but only 1–2 of the first 10 paying accounts were SaaS companies. Small agencies made up the largest group . Rank segments by how deep the replies go , or by who agreed to a paid next step .
Careers
- One commenter cited their employer's study of 150 PMs at Meta, Google and Amazon. 42% switched company and role at the same time, 28% moved into PM internally, 23% came after postgraduate study and 7% came straight from undergrad. 64% had technical degrees and only 13% had a certification .
- Formal 30-60-90 onboarding seems to be fading. One commenter describes a week of meeting people, with contributions expected by week two or three .
- Lenny launched The Next 50, a quarterly list of early-stage startups ranked on headcount growth, funding and investor interest . To qualify, a startup must have been founded in 2023 or later, be at Seed or Series A, have raised at least $5M, have a top VC investor, and have 10–250 employees with headcount growing .
Also
One team that deploys continuously publishes changelog pages for version ranges, such as /changelog/v1.50.0..v1.54.2. Support can send a customer everything since the version where they reported a bug .
- Meredith argues that even a consumer agent booking a birthday party may need contacts, payment details, browser, calendar, and messages; broad permissions and following instructions embedded in text create prompt-injection risks. She cites reported incidents involving Microsoft Copilot, Perplexity, and Google Calendar, and says trust should be verifiable rather than assumed.
- Neil argues against treating agent use as all-or-nothing: risk depends on the agent, task, and access requested. He recommends taking small steps, limiting access, and testing and verifying agents.
- Neil reports using Muse to opt out of five major US data brokers with a six-word prompt, illustrating a potential privacy-workflow benefit. Meredith warns that agents accessing contacts and communications can expose information about people who did not choose to use them, and that opaque disclosures and click-wrap can leave users unaware of data practices.
- As AI makes it possible to build more things, strong PMs create value by choosing what is worth building and aligning teams around a coherent direction. The job now requires producing something substantive—such as a prototype, data analysis, or ready-to-ship MVP—not stopping at a requirements document.
- AI PMs should use models regularly, stress-test them on their own use cases, work with data, and build evaluations. They also need to adapt roadmaps frequently as model capabilities change.
- To evaluate models, test tasks that matter to you where models show promise but are not yet good enough. Start small: five prompts and yourself as a rater can begin an eval; around 20 examples can reveal differences between models. Define what “good” looks like before scaling.
- A flexible AI roadmap can allocate roughly 60% to capabilities that work today, 20% to near-term possibilities, and 20% to emerging capabilities that are not yet ready; the mix helps teams act when a capability becomes practical.
- Model development can produce unexpected strengths; product teams need to recognize where a model shines and turn those capabilities into useful products.
- Google’s AI strategy spans custom hardware, large-scale products, and models across the cost-quality spectrum, from frontier systems to models for different user needs; Tulsee Doshi says Google intends to compete to win the frontier-model race.
Lenny launched The Next 50, a quarterly-updated list of early-stage startups to watch or join, ranked using headcount growth, recent funding, and investor interest. The qualifying profile is startups founded in 2023 or later, at Seed or Series A and valued under $1B; funded in the past six months with at least $5M raised in total; backed by a leading venture firm; and employing 10–250 people with headcount growth over the previous 90 days. The list can help product managers scout potential early-stage employers.
- With about 80 users and no paid upgrades, define the paid-tier ideal customer and the distinct pain-solving value of the paid offer relative to alternatives. One commenter described free-to-paid conversion as market-dependent and often single-digit in products they had worked with; treat this as rough context, not a universal target.
- Distinguish downloads from recurring active users and track monthly active use appropriate to the deployment; a 9% site-to-download rate is difficult to interpret without traffic volume and source. Interview frequent returners about what they use the app for and what they would miss to guide paid-tier value before changing the pricing page.
- A commenter suggested visually impaired users as a potential niche for the screen-guidance app, citing a family member’s expensive, buggy reading aids and lack of AI-driven task guidance, and said they would pay a few hundred dollars per year. Treat this as a discovery lead, not validated market demand.
- Keep the PRD in a human-readable collaboration tool rather than treating AI chat as the source of truth. One PM drafts in Confluence, then uses a custom Rovo agent to improve structure and identify missing scenarios, assumptions, risks, and edge cases; another workflow brainstorms with AI, reviews the final draft in Google Drive, then links the approved document in a product graph and breaks it into stories.
- Keep human approval in the loop: one PM says AI-generated documents are not syndicated until reviewed and often rewritten, then routed for a relevant functional lead’s second review; comments and changes stay on the ticket in a new version before sprint planning. A separate commenter recommends applying only owner-accepted comments and showing the resulting diff, rather than automatically turning all feedback into scope.
- A counterpoint to long PRDs: one commenter argues that when stakeholders use AI to digest documents, teams may get more buy-in by telling the story through a prototype and keeping any supporting “why and what” document shorter, while still framing the problem and how it will be tested.
- Neurodivergent PM fit appears environment-dependent: practitioners describe context management, systems thinking and problem-solving as strengths, alongside challenges with ambiguity, planning, feedback and overload. One former PM linked repeated burnout to unpredictability and lack of clarity, and concluded that the work environment—not a universal PM-versus-autism fit—was decisive.
- Practical tactics shared include shaping team structures around strengths, using a mentor or accountability partner, writing things down and reviewing them three times daily, and asking a manager to clarify stakeholder approaches. Preparing for meetings and following up when you do not know an answer can also reduce ambiguity.
- AI can support low-interest research, searches across internal process documents, closing loops and identifying next steps; however, one PM noted that AI-supported tracking in a public wiki did not ensure information reached colleagues who did not read it.
- Tulsee Doshi, Google’s Head of Product for frontier AI models, says she wants PM candidates “who have an opinion.”
- The associated conversation is framed around the rising value of great PMs and a shift from writing requirements to creating something with “heft”; it also covers how to write a first eval.
- A commenter reporting on a study of 150 PMs at Meta, Google, and Amazon said their first PM roles came through switching company and role (42%, usually from a related job), moving internally (28%), postgraduate study (23%), or starting directly after undergrad (7%, almost always through an internship or APM program); these figures describe that sample, not the broader market. The commenter recommends joining a tech company in an adjacent role and pursuing an internal PM move, which they describe as easier than applying externally without a track record.
- In that sample, 64% had a technical degree, though the reported shares differed between Google (74%) and Meta (50%); the commenter says a technical degree is not required, but comfort working with engineers and asking technical questions matters. They describe PM work as aligning people who do not report to you around what to build and why, while owning outcomes without authority—a fit that favors people comfortable with ambiguity and variety.
- One reply advises testing interest before investing in courses or certifications: learn what PMs do, examine apps you use for possible improvements, and assess whether that work appeals to you. In the reported 150-PM sample, 13% had a certification.
- Organize the repo around customer problems, with quotes, tickets, and call notes as evidence and ideas as possible solutions; this can help merge duplicate requests and prioritize problems by evidence rather than debating solutions.
- Link each idea to the product decision it could change and its supporting evidence, and record the decision and what was learned in the same entry. Add a success criterion up front so it can become acceptance criteria and guide follow-up if the idea is promoted.
- Give ideas revisit dates and review them in an existing planning or discovery cadence; archive an idea if it resurfaces twice without new evidence. Let contributors submit ideas from tools they already use, such as Slack or a short form.
- Keep ideas connected to a coherent product direction: one recommendation is to model the repo as a graph of customer transformations aligned with the product value proposition, with the PM reviewing additions; another emphasizes tying requirements to a longer-term product vision rather than leaving them as scattered notes.
Lenny's interview with Tulsee Doshi, Google's Head of Product for frontier AI models including Gemini, Nano Banana, Genie, and Veo, covers why great PMs are becoming more valuable, how the PM role is shifting from writing requirements toward creating something with “heft,” how to write a first eval, and Google's full-stack frontier-AI strategy.
Hiten Shah said he told Ryan Hoover in 2019 that putting a product out was getting easier while making it work was getting harder; nearly 25,000 makers launched on Product Hunt in October, illustrating the scale of launches behind that observation. Hoover’s linked retrospective says Product Hunt itself almost died in 2016.
Hiten Shah flags a product/service opportunity in post-deployment AI-agent support: agents may quietly stop working, leaving users to diagnose failures, and their adoption could increase rather than eliminate IT-support demand. A related discussion raises paid help for building and using agents as a possible services business, but frames it as an open question.
Mentiohunt’s founder built for B2B SaaS founders, but among the first 10 paying accounts only 1–2 were SaaS; small agencies buying it for their own sites were the largest group—evidence that observed customers can overturn an assumed ICP. For product discovery, test multiple segments and shift outreach as evidence accumulates rather than treating the initial ICP as settled; evaluate replies by intent (such as questions or involving a team) and paid next-step commitment, not raw response count, and use launch, hiring, or funding signals to time outreach.
A commenter reports that AI-assisted feedback analysis and competitor research have reduced manual effort; topic alerts and real-time insights help with prioritization. They are exploring ParseStream to monitor discussions across platforms and prompt timely participation, and say it has helped them spot leads and trends faster than traditional monitoring tools.
- Commenters described horizontal AI-agent infrastructure as crowded and suggested looking for production-stage needs—such as permissions, audit trails, and cost control—by speaking with teams already running agents rather than relying on market maps; another suggested vertical applications built around proprietary data embedded in companies or industries.
- A concrete reliability hypothesis to validate is recovery after a tool-call timeout: retrying an uncertain CRM operation may create a duplicate record. Ask teams how they reconcile such outcomes, but do not treat this example alone as evidence of an underserved market.
- To identify adoption friction, ask teams that evaluated but rejected tools what stopped them—security review, data residency, integration, or no clear budget owner; those barriers may offer a stronger wedge than another generic orchestration layer.
- One commenter argued that simply reselling labs’ tokens is not viable without proprietary models.
One continuously deploying product makes changelog updates shareable as filtered pages using Git-style version ranges or comma-separated releases; each page combines the selected releases into a summary and link preview, canonicalizes alternate spellings, and is noindex so individual releases remain the search results . The author uses the links to help Support send customers changes since a reported bug version, newsletters share a month's updates, or customers see fixes from scattered releases without intervening releases . This is presented as one team's approach, and the author is unsure whether others use it or find it useful .
A discussion of 30/60/90-day plans for PMs joining amid AI-related churn surfaces a reported lack of structured onboarding: commenters describe a week of introductions followed by jumping into work, with contributions expected as early as week one and commonly by weeks two or three. The original poster says the challenge is to spend less time only talking to people and find ways to deliver impact sooner, while still treating those conversations as necessary.
- For early product discovery, state a testable problem-and-payment hypothesis, speak with prospective customers, and test a crude prototype. One commenter illustrates this with a honey-pouring problem, five conversations, and one prospective prototype tester; this is an example, not a reported result.
- Treat product-specific criticism as possible input for learning and adjustment, while separating it from generic discouragement and recognizing that not all feedback is actionable. A fixed budget or a date to review customer evidence can keep the decision focused on a manageable risk.
- Product discovery should start with a target domain and its problems, not abstract idea generation: investigate frontline users and look for manual processes or poor buying experiences; listen in early customer conversations rather than pitching, and approach people with genuine interest rather than treating them as idea sources.
- Build domain knowledge by immersing in a market and examining unmet needs and where products fail to meet them; use that customer understanding to guide a technical team toward a product goal. The advice also cautions that a strong product does not sell itself, emphasizing listening to unmet needs and creating solutions.
- For cross-border SaaS, choose one country and buyer type, then identify roughly 50 named companies with the problem and contact them directly; treat directories and Product Hunt as places buyers may confirm a decision, not as dependable acquisition channels.
- Validate demand with 3–5 paying users before prioritizing the threat of AI-built competitors; the commenter argues that buyer knowledge, trust, and distribution become more important when products are easy to recreate.
- Before building for a foreign market, check that a merchant of record can pay out to your country; it can handle VAT/GST and US sales tax but costs more than plain Stripe. Set prices against competitors in the target market rather than converting your home-market price.
