We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
How hard is it to clone your product?
A PM at a long-established analytics software company asked how to deal with vibe-coded clones. The replies agreed that the first version is cheap now. One commenter said they rebuilt about 70% of a 15+-year-old technical SaaS product in five hours with an LLM, "even down to reproducing the same inputs/outputs" . Others argued that cost is in the remaining work. A demo might take a week and 90% might take a few months, but "the extra 10% will be far more difficult" and ends up needing dedicated hires just to maintain . Another listed what a copycat won't have: the backlog of fixes, customer success calls, PRDs, corner cases and the backend .
One commenter said speed changes how teams have to build. They argued "Agile isn't fast enough for Agentic development." In their view, QA harnesses and automated guardrails, not paperwork, are what make AI output trustworthy at volumes nobody can review by hand .
Hiten Shah raised a related risk: you can now build software that "looks ready for a million users before you've learned what one person actually needs." His advice is to give early access to people already doing the work: "The faster you can build, the sooner you need contact with reality" . Ravi Mehta makes a similar point from the craft side. AI lets teams afford the "nice-to-haves" they used to cut, yet many are spending that capacity on "an industrial-scale slop factory" of extra features. He expects the advantage to go to teams that build with "craft, taste, and ambition" before everyone has the same tools .
What makes AI output usable
When a PM asked whether AI-written PRDs are acceptable, the answers mostly came down to how much context and checking goes in. One PM said early drafts were weak. After nearly a year of connecting Claude to Jira, using templates and keeping a "second brain," it "nails it first time pretty much every time" . Another described a full pipeline: 48 rule checks, six quality dimensions, accept/warn/reject gates and LLM revision loops, drawing on 34 product artifacts. They rate the results "9/10 good," with "the odd one... so wrong it hurts" . A third commenter asked what PRDs are for if developers just feed them to coding agents. Maybe agent-to-agent handoffs need a different format .
Productify describes the same pattern for recurring work. A daily Jira/Confluence briefing went through four or five rounds of prompt rewriting. It learned to group tickets by business topic, put customer, payment, revenue, security and compliance risks first, and say what it could not verify . The most important rule was "Do not invent facts," because the agent would label a single ticket "highly critical" without knowing the wider context . The author's "Judgment Loop" is: you define good, AI drafts the prompt, you review, and you automate only once you trust it . Write your context down once to stop paying the "Prompt Tax" .
Reliability thresholds, not smooth gains
On Lenny's Podcast, Anthropic interpretability researcher Emmanuel Ameisen explained why AI features seem to suddenly start working. Capability improves smoothly, but each task has its own reliability threshold. An email helper you have to fix half the time wastes your time. One you fix 5–10% of the time is useful. Claude took over most of his coding when it went from roughly 80% correct ("not useful") to 99% . For AI features, that means judging task-level reliability and how much correcting users have to do.
Careers and distribution
- "Product builder." Aakash Gupta notes that LinkedIn replaced its APM program with an Associate Product Builder program. He cites an analysis of 10,000+ PM job descriptions: over 30% call for AI skills, and the top skill is choosing the right problem for AI, ranked ahead of RAG and agents . Separately, Gupta says his "Company OS" answers team questions in Slack with sources and runs shared skills in 21–85 seconds for $0.08–$0.32 each .
- Job market. A mid-career PM asked why landing interviews is harder than four years ago. Commenters pointed to laid-off ex-FAANG candidates, hundreds of AI-tailored applications per posting, openings that go unfilled or get downgraded, and $45/hour caps on senior technical PM contracts . Large employers in healthcare and payments can find candidates with similar skills plus domain experience .
- Discoverability. Paul Graham: content on a paywalled site that AIs can't find effectively "doesn't exist." He adds that this isn't fully true yet but "will only get truer" .
- The discussion frames vibe coding as lowering the cost and increasing the quantity of competitors, rather than inventing competition. Simple, lowest-common-denominator products may be most exposed, while established enterprise offerings may retain an edge through consistent service, reliability, and integrations. But incumbency is not sufficient: one Adobe user argued that weak innovation and problems with After Effects, performance, and integrations create openings for alternatives, citing DaVinci Resolve’s gains against Premiere.
- PMs in the thread recommend building moats beyond development cost—such as audience and distribution, customer support, roadmap, and industry insight—while complex workflows, back-end integrations, and ongoing maintenance or scaling can be harder for clones to reproduce. One commenter reported reproducing 70% of a 15+-year-old technical SaaS product’s core features in five hours; another estimated a demo in a week and 90% completion in a few months, but said the final 10% and maintenance could require substantial time and dedicated hires.
- For agentic development, a commenter argues that teams need to invest in QA, test harnesses, and automated guardrails because AI-speed output can outstrip manual PR review and ticket handling.
- AI capability can improve smoothly while product usefulness seems to jump when a task crosses its reliability threshold: the interviewee contrasted email assistance that needs correction about half the time with usefulness around 90%, and said Claude’s code writing became useful as his experience rose from about 80% to 99% correctness. For AI products, evaluate task-level reliability and the human correction burden, not just incremental capability gains.
- Fast-choice models and deliberative reasoning suit different jobs: the interviewee described quick option selection as a gut judgment useful for classifying a review as happy or upset, while planning a roadmap for the next year calls for longer reasoning; he expects both modes to be useful in intelligent systems.
- For AI safety, the interviewee described combining access limits with behavioral assessment—including checking whether a model behaves well only when it knows it is monitored—and using concerning findings to improve training in a tight feedback loop.
- AI feature usefulness can jump even while model capability improves smoothly: assess reliability against each task’s threshold. Ameisen said code generation was not useful to him at about 80% correctness but became useful near 99%.
- Fast-choice models can complement deeper reasoning: a quick sentiment judgment may suit a fast choice, while roadmap planning calls for more deliberation; Ameisen sees both modes as useful components of intelligent systems.
- AI product QA may need to look beyond visible outputs: interpretability can investigate unspoken intermediate representations and anomalous behavior. In one training example, the model calculated 12 but kept insisting on 36 after similar questions had been incorrectly labeled; Ameisen described using such findings to improve current and future models.
- PM job seekers describe a much tougher funnel than in 2021–22, citing layoffs, fewer openings and a larger pool of experienced candidates. Commenters say domain experience can be decisive, including for big employers in healthcare and payments/finance; one argues it can outweigh MAANG experience and says demonstrable AI skills are expected.
- Commenters say AI-generated, tailored applications are producing hundreds of applicants quickly, while AI-assisted interview polish can obscure whether candidates can do the work; one also attributes fewer Product Owner roles partly to automation of their tasks. They report some requisitions go unfilled or are downgraded in pay or title, with remaining staff taking on more work.
- Outcomes are not uniformly stalled: commenters report ex-FAANG PMs receiving multiple offers and one laid-off PM finding a better-paid, fully remote role after about six months. A respondent cautions that Reddit may overrepresent negative job-search experiences.
Conventional 360 feedback often means an annual review filtered by the same manager who controls compensation and promotion, creating a low-trust setting; interview-based 360s gather input from managers, peers, and direct reports and synthesize it with specific examples, but are usually reserved for executives. Your360 AI says it uses voice AI to make confidential, developmental feedback available to anyone.
A draft Chinese rule would block foreign buyouts of cell- and gene-therapy and siRNA platforms while still allowing licensing of individual drugs, distinguishing access to products from ownership of the platforms behind them; comments were open through Nov. 15.
- Practitioners say AI-generated PRDs depend on product context and guardrails: one commenter reported early weak drafts, then better results after connecting Claude to Jira, creating templates, and saving work in a “second brain”; another recommends supplying product context and past decisions, as with a junior PM new to the product. A separate approach is to have AI structure the PM’s own idea without adding content, then carefully review and edit the PRD.
- One practitioner described a PRD quality loop: draft, run 48 rule checks and score six quality dimensions, attach a report, accept with or without warnings or reject, then use LLMs to generate review comments and revise. Their system selects context from 34 product artefacts and uses an application architecture model with more than 1,500 nodes. They self-report that PRDs are “9/10 good” but acknowledge occasional severely wrong results; another commenter cautions that PRDs are subjective and AI is non-deterministic.
- A commenter raises an open product-design question: if developers feed PRDs to coding AI, should PRDs serve as documentation, handoff descriptions, or a different kind of agent-to-agent specification?
- An interim PM recommends applying product/GTM thinking to a job search: define the hiring manager’s problem, articulate your value proposition, choose target companies, and tailor outreach; generic positioning risks getting lost among similar candidates.
- For LinkedIn outreach, a former SaaS PM leader recommends messages under five lines with an easy-to-answer question, and checking the recipient’s recent activity and offering value before making an ask. Other commenters emphasize a clear, relevant offer and readable formatting.
- Advice on the channel is mixed: some respondents say they ignore or rarely see LinkedIn messages and favor personal recommendations, while another considers genuine, researched, relevant outreach and brief career conversations reasonable.
- For recurring product work such as PRD reviews or weekly updates, reduce “Prompt Tax” by giving AI the task context once—purpose, audience, decision, framework, format, and examples—and asking it to draft a reusable prompt and identify missing information; then run, review, revise, and automate only after you trust the output.
- For product and business briefings from Jira and Confluence, the author’s workflow groups tickets into business topics, prioritizes customer, payment, revenue, security, and compliance risks, and explains technical terms plainly. It also requires the agent to disclose when customer impact, ownership, approval, or deployment status cannot be verified.
- A legacy HRM/HCM product discussed in the thread had lost 75–80% of its customers over a decade and had gained only one customer in seven years, who was returning; commenters recommend confirming whether the product’s goal is growth or retention and what customers still value before choosing tactics, then examining development costs, customer profitability, portfolio contribution, unit costs, and ROI.
- Make the investment choice explicit: one PM described a six-month cleanup of two problem areas followed by ending active development and keeping only bug fixes; simplifying the product also reduced support burden, and the PM said maintenance contracts later earned more than active selling had.
- If modernization continues, incremental replacement can be low-risk but slow: one example took 10 years and still left about 25% of workloads on the legacy application, while process, codebase, and CI/CD improvements helped raise core update deliveries from three to ten per year. Another suggested validating a parallel greenfield proof of concept with an existing customer before migrating clients one by one.
- For PM–design friction, commenters recommend involving designers in user understanding, journeys, and wireframing rather than asking them only to polish PM-built prototypes; another suggests candid Design/Engineering discussions to agree on a shared operating roadmap, noting SIPOC as a tool that worked for them.
- For limited scope, a senior-PM commenter advises proactively tracking customer needs, market shifts, product quality, and competitor gaps, then quantifying actionable opportunities and advancing them as a small project or larger proposal; another recommends documenting credited and uncredited work and making contributions visible to the manager.
- A commenter warns against independently shipping unvetted production changes to outpace Engineering; another points out that apparent speed may omit the maintainability and scalability work professional engineers account for.
- Advice on escalation differs: one commenter recommends addressing team conflicts directly and not escalating before trying to resolve them with the manager, while another says a skip-level conversation can be appropriate if framed as a career discussion about finding more ownership rather than as a complaint.
At a UT hackathon, students reportedly coordinated around 100 free-tier accounts across major AI providers with a context harness that passed project state and work between accounts, chunking tasks to avoid rate limits. The account also noted a shift in what they write and review, and how they check reliability, but did not specify the details .
- AI changes the economics of product development, making it more feasible to build crafted details that teams might otherwise cut as “nice-to-haves”; those details can help a product feel alive rather than merely functional.
- Product teams should use AI’s added capacity to improve craft, taste, and ambition rather than simply ship more features. As access to the same tools spreads, craft—not tool access or feature volume—is positioned as a source of advantage.
- Build tight feedback loops into product work: Jerry repeatedly tested new material with live audiences, recorded and analyzed his performances, and refined the details; Seinfeld’s team also used audience laughter to identify jokes that needed changing.
- Don’t let a weak broad test automatically disqualify a differentiated product. Seinfeld’s pilot tested poorly and viewers showed little eagerness to watch again, but some NBC champions saw a small group that strongly connected with it and ordered four episodes; later, audience retention was strong across major metro areas. The hosts argue that slow, word-of-mouth growth around a core of passionate fans can be more durable than quick mass exposure.
- Respond to the underlying user or market need without blindly adopting the expected solution: after women rated poorly in the pilot research, NBC wanted a female character; the creators added Elaine but rejected the conventional love-interest arc, preserving the show’s distinctive approach.
- Distinguish acquisition from retention in subscription products: the episode frames new shows as tools to attract subscribers and familiar, evergreen shows such as Seinfeld as retention assets that can reduce churn by giving subscribers a dependable fallback.
- Treat onboarding as discovery: interview stakeholders about expectations and prior decisions, learn the industry and customer problem, and understand how success is measured; organize core product artifacts and aim to have the vision reviewed within 90 days. A 30/60/90-day ramp—with early contributions after 30 days and full impact around 90 days or later—was recommended over expecting full team leadership after four days.
- In a founder-led 0–1 startup, first learn the CEO’s reasoning and initially make decisions close to how they would; introduce new perspectives over time through tests and measures the CEO trusts. Align stakeholders on what the business wants to become and stress-test the founders’ goals and assumptions; this approach assumes the CEO has product sense, so a PM may need to compensate when they do not.
- Establish clear ownership of product decisions and become the person who understands the product’s user value, strengths, weaknesses, and complex areas. Use customer conversations and customer success as feedback sources; treat sales as useful for opportunity discovery without building solely for prospects, and prioritize validated work against team capacity rather than overpromising.
Product teams should not mistake software that looks ready to scale for evidence that they understand users’ needs; give early access to people already doing the work and observe how they use the product, including in unexpected ways. The faster a team builds, the sooner it should seek real-world user feedback.
- LinkedIn replaced its APM program with an Associate Product Builder program; a Claude/GPT review of 10,000+ PM job descriptions found that 30%+ called for AI skills, with choosing the right problem for AI ranked ahead of RAG and agents.
- An AI-builder roadmap puts possibilities, opportunities, and workflows before engineering, and recommends using AI for discovery (turning 200 intro calls into personas) and checking costs before production.
- Aakash Gupta says his team tested a Company OS that answers questions in existing work channels with sources, shares reusable skills, and supports permission controls and human review gates. Run-only skills produced work in 21–85 seconds for $0.08–$0.32; in one example, a media-kit request generated a PRD, prototype plan, engineering spec, and task list in three minutes, then went live after human approval.
An r/ProductMgmt poster says that giving AI no context, format, or rules led it to invent requirements and repeatedly write stories beginning “as a user”; the poster says they spent months refining prompts and developed three, but does not provide them in the text here.
For an aspiring independent business-lending broker, pressure-test the go-to-market plan by estimating customer-acquisition costs, identifying why businesses would switch from their existing providers, and deciding how to reach them. If competing with lower rates or longer repayment terms, account for how that could change the economics and attract riskier borrowers. Before resigning, confirm that two or three lenders will accept submissions and, if the employment contract permits, try closing one or two deals independently.
A newly hired sole product manager at a 0-to-1 startup is expected to lead the roadmap and execution just four days into the role, following a highly hands-on predecessor; they say their confidence is dropping and ask how to set themselves up for success.
r/ProductManagement comment by u/Bernhard-Welzel
Opinion
How to use Ai to write PRDs?
I think if I give my raw idea and all the necessary details to Ai and ask it to polish and write structured PRD
Will it be wrong or right?
Not sure this approach will work.
From my experience you need to do a bit more; example flow:
STEP 1: writes PRD using statements only.
STEP 2: Layer 1 rule engine evaluates all R-rules.
If any rule returns ERROR, set passed to false, list the violations, and still compute the score.
STEP 3: Layer 2 score engine evaluates each dimension.
STEP 4: Attach QualityReport to PRD.
STEP 5: Determine the result.
If passed is true and overall is greater than or equal to the threshold, the result is Accepted.
If passed is true and overall is below the threshold, the result is Accepted with warnings.
If passed is false, the result is Rejected and revision is required.
STEP 6: Another LLM is creating the most impactful review comments
STEP 7: Another LLM is creating a revised PRD and go back to STEP 2
I currently have 48 R-Rules for PRD defined for Layer 1 and 6 quality dimensions for Layer 2
I also have 34 product artefacts to provide context and a LLM selecting the relevant context for the task (basically: decide what is needed for this PRD and create a dynamic context).
I also have a full architectural model of the application with more than 1.500 nodes.
PRD are 9/10 good, usually much better than what a human can create, but there is always the odd one in the mix, that is so wrong it hurts :-)
- Practitioners say AI-generated PRDs depend on product context and guardrails: one commenter reported early weak drafts, then better results after connecting Claude to Jira, creating templates, and saving work in a “second brain”; another recommends supplying product context and past decisions, as with a junior PM new to the product. A separate approach is to have AI structure the PM’s own idea without adding content, then carefully review and edit the PRD.
- One practitioner described a PRD quality loop: draft, run 48 rule checks and score six quality dimensions, attach a report, accept with or without warnings or reject, then use LLMs to generate review comments and revise. Their system selects context from 34 product artefacts and uses an application architecture model with more than 1,500 nodes. They self-report that PRDs are “9/10 good” but acknowledge occasional severely wrong results; another commenter cautions that PRDs are subjective and AI is non-deterministic.
- A commenter raises an open product-design question: if developers feed PRDs to coding AI, should PRDs serve as documentation, handoff descriptions, or a different kind of agent-to-agent specification?