We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Agent permissions are now a launch decision
Aakash Gupta retold Alexey Grigorev's incident. Claude Code ran terraform destroy and wiped out DataTalks.Club's production setup after it unpacked an old state file. Grigorev let it go ahead because "That looked logical" . AWS support found a snapshot, and everything was back after about 24 hours . Grigorev changed four things afterward: agents no longer run infrastructure commands, a person reviews every plan, he runs every destructive action himself, and he is looking at separate development and production accounts. None of them involved changing the model . Gupta tells PMs to settle three questions with their engineering lead before launch: which actions an agent can take on its own, which need a human, and which it should never be able to reach .
Others made the same point the same day. Runlayer launched secured, policy-governed connectors for the Muse agent. Its pitch: some companies block Muse, and others have seen it leak data and send unauthorized emails . Hiten Shah's takeaway: an agent having permission to do something doesn't mean it should. "The ability to stop one action is what lets companies say yes to thousands of others" . Shah also thinks some of the next big waves of AI adoption could come from better harnesses around existing models, even without major model improvements . In The Product Compass, Paweł Huryn shares the "ask first" rules for his seven-bot Grok product team. They cover outside messages, anything customers can see, contacting customers or competitors, payments, and decisions that are high-risk or hard to reverse . One of his bots checks competitors' pricing pages, changelogs and X posts every week. If nothing changed, it stops; if something did, it reports why it matters .
Skills are where team know-how lives
Sachin Rekhi says Fin is seeing a 3x increase in engineering velocity, while many teams remain stuck at about 30%. He credits Fin's AI platform: a single agentic platform for the whole team, a shared skills marketplace anyone can publish to, and systems that let designers ship code to production . Rekhi is promoting his course here, and Fin's Brian Scanlan is its first guest speaker .
Two posts show why skill design matters. Shah asked Claude why Linear was losing deals to Jira, with no interviews or deal records to go on, and got eight reasons. With his team's win/loss skill, Claude said it couldn't know yet and listed the evidence to collect . That skill is one of 16 product-marketing skills his team has open-sourced . Gupta found that Claude scans only each skill's name and description until it picks one. In his test of 25 skills, one with a 37-character description was never chosen: "the description is the skill" .
Hiring and go-to-market
- Product builders. Gupta and HelloPM's Ankit Shukla report that LinkedIn replaced its APM program with Associate Product Builders. They also say 30%+ of PM job descriptions ask for AI skills, most often picking the right use case . Their suggested path: build in stages from a PRD Gem to shipping in Claude Code, then post the work on GitHub with a Loom demo .
- Selling to agents. Paul Graham suggested a nerdy founder might want an outgoing sales cofounder. The founder said no, because most of his sales would be to agents, and Graham admitted he "could be right" .
Practitioner advice from Reddit
- Developer-tool trials. Keep the first trial to one existing task, run it alongside the current approach, and make it clear how to stop and remove the tool. Watch where hesitation comes from: setup, permissions, trust in the output, or making the internal case to buy . Another commenter suggests a read-only "shadow mode" that shows the difference without writing anything to production .
- Beta scope. A founder with one of six modules ready was advised to show only that module, because "five future tabs make a working product feel unfinished" .
- Small B2B markets. A founder selling into a conservative niche said the first PO came from offering a new capability priced low enough that it didn't take much of the buyer's budget . That fits a commenter's view that the real trigger is the buyer making room in the budget for a second tool .
- Build vs. buy. A vibe-coding platform is weighing Merge.dev's model routing against its own stable control plane. The poster also says two exec buyers they spoke to described very different pricing .
- Stale demos. DemoForge is a free, MIT-licensed tool. You write the demo once as a script of clicks and narration, then re-record it with one command after each release .
Pushback on Lenny's podcast
A popular r/ProductManagement thread argued that Lenny's podcast has drifted toward AI and an executive audience paid for by sponsors . One commenter called it "not a front-line PM's podcast" . Another said it now covers practice "through the lens of administrators" . In the same period, Lenny kept promoting Josh Woodward's case that companies need people "plugged into the hive mind" at the frontier .
Josh Woodward (Head of Google Labs, Gemini App, and Google AI Studio) says teams almost always know a project is dead before its leader does—a signal for product leaders to consider when making continue-or-stop decisions. Lenny’s accompanying advice is for companies to operate like labs: because what’s possible changes every few months, staying ahead requires experimenting at the frontier.
- Strong product ideas often come from small groups obsessed with an insight, rather than design sprints or brainstorms; create room to build and keep a live list of ideas that are “almost possible,” moving quickly when they become feasible.
- Stay attached to the user problem, not a favored solution: ideas may need three to five significant pivots. Assess early product-market fit using data and retention alongside users’ visible engagement with prototypes.
- As technology changes rapidly, companies should experiment with new models and what they enable. An internal lab needs structural independence, an explicit mission (such as graduating ideas into existing products versus inventing categories), and room to challenge how the company works; Google Labs runs roughly 20–30 experiments in parallel, with teams cycling through sprints, recovery, and open exploration.
- Teams may recognize that a project is failing before leaders do, so leaders should make it safe to raise concerns. Value the ability to test and let go of prior beliefs, and encourage PMs to develop adjacent skills such as prototyping without replacing their PM specialty.
Speedrun announced cohort 008, inviting side-project builders and aspiring founders to apply for a chance to build faster, learn, and test in the real world; the post includes an application link.
-
For PMs launching agents, permissions and review are part of the product harness: after a Terraform state-file mix-up, Claude Code ran
terraform destroyon production infrastructure following human approval; AWS support found a snapshot and the environment was restored after about 24 hours. Alexey Grigorev’s subsequent controls were to block agents from infrastructure commands, require human review of every plan, run destructive actions himself, and consider separate development and production accounts—without changing the model. - Ankit Shukla’s product-builder roadmap says LinkedIn replaced its APM program with Associate Product Builders, and that 30%+ of PM job descriptions ask for AI skills, most often selecting the right use case. It recommends mapping skills against job descriptions and building practical proof—from a PRD tool through prototyping to a shipped project, published with a GitHub repo and Loom demo.
- Claude initially scans installed skills’ names and descriptions, then reads the rest only after selecting a skill; in a test of 25 skills, one with a 37-character description was never chosen. The note’s takeaway: the description is critical to automatic triggering.
- Subscribers in the thread perceive Lenny’s content as shifting from practitioner-focused PM craft—including product marketing, strategy, and JTBD—toward AI-heavy coverage and a product-leadership/C-suite perspective; one commenter says it is less useful for front-line PMs.
- The comparison is not uniformly negative: one commenter values Lenny’s community, while praising Stratechery for independent analysis that helps develop strategic thinking.
- One commenter urges PMs to read beyond mainstream sources, questions RICE’s usefulness, and points readers to two longform.asmartbear articles.
Product leaders should create organizational room for a frontier-exploration team: Josh Woodward argues companies need people plugged into emerging tools and ideas, with the organization structured to support that work; Lenny frames the case as capabilities changing every few months, making frontier experimentation important to staying ahead. Lenny’s post also identifies rules for establishing an internal labs team as a topic of the discussion.
- The author built a seven-bot product swarm covering research, strategy, marketing, design, specs, engineering, and a product lead. He recommends specialized roles to keep each bot’s context lean, with one default lead coordinating specialists; a shared collaboration skill, product context, and decision log help them work together reliably.
- A practical PM use case is scheduled competitor intelligence: the researcher checks competitors’ pricing pages, changelogs, and X posts weekly, stops when nothing has changed, and otherwise reports why the change matters.
- Set permission rules before giving agents tools: the author’s “ask first” examples include external messages, customer-visible changes, contacting customers or competitors, purchases, and high-risk or hard-to-reverse decisions.
- The author frames Grok Bot as a convenience-versus-control trade-off and says it costs more than Claude Code; he suggests reserving it for high-impact or unattended work, while using Claude Code for coding and engineering.
a16z Speedrun opened applications for its SR008 San Francisco residency, running February 1–April 16, 2027, with applications due November 1, 2026. Product-relevant support includes Launch Lab to put products in front of people, introductions to executives and customers, and feedback and customer introductions from a community of 1,000+ founders.
- For a thought-capture app that lets users record ideas from notifications or widgets and uses AI to organize them, requiring users to supply an API key may add friction and skew early feedback toward technical users. A commenter recommends checking whether users return after a week; the founder said the key was initially for personal use and planned a premium version without that requirement.
- For early discovery, look for people already using workarounds for the problem and ask them to pay before building more; agreement that a problem is annoying is weaker evidence of demand.
- One proposed test is to give 20 users a week with the product, then charge $5/month for the feature they used most and measure conversion instead of surveying willingness to pay. Treat that alongside retention, which the thread recommends checking before focusing on pricing.
Hiten Shah says useful AI results depend on identifying relevant information, choosing how to approach the work, and recognizing when an answer is wrong; judging errors takes experience. His team open-sourced 16 product-marketing skills built around these principles: https://github.com/LMTYdotcom/skills
Runlayer’s enterprise-agent security pitch combines secured connectors, deterministic policies and runtime security with detection of agent use without governance. Hiten Shah’s product takeaway is that having permission does not mean an agent should take every action: stopping a risky action, such as an email in the demo, can make companies comfortable enabling many others.
After a newly launched software startup won some of a competitor’s customers, the competitor proposed a referral partnership that would restrict the founder from serving its customers except through referrals, while discouraging the founder from entering its niche or building features it offered. A commenter warned that the arrangement could buy the competitor time to copy differentiating features, citing an anecdotal example, and advised declining and focusing on marketing; the commenter’s estimate that copying could happen within six months is speculative.
- For developer tools that could be built internally, commenters suggest making evaluation low-risk: test on one existing task alongside the current approach, agree on what success looks like, and make stopping and removal clear; a read-only shadow mode can show results on real inputs without writing to production.
- During onboarding, distinguish whether hesitation comes from setup, permissions, trust in the output, or the internal purchase case; for the build-it-yourself objection, compare who would maintain the alternative and what other work would be delayed.
- One commenter argues that adoption depends not only on reducing setup friction but also on solving an urgent problem and fitting an existing daily workflow; integrations that require a Slack channel or security review may make an internal substitute more attractive. The commenter also warns that open-source code can be copied and free tiers may remain in production for years without converting to paid use.
In a win/loss analysis of Linear losing deals to Jira, Claude gave eight reasons despite having no buyer interviews, call notes, or deal records; a win/loss skill instead said it could not know yet and identified evidence to collect. This is a useful product-research pattern: surface evidence gaps rather than present unsupported explanations as findings.
- For the proposed website/RFQ service to small manufacturers, validate the customer problem before selling or building: learn how they currently find clients and listen for existing pain rather than trying to persuade them they need a website; established client networks may mean the need is not felt. A commenter also cautions that some manufacturers may intentionally use direct contact to begin sales discussions, so more form submissions are not automatically valuable.
- Test with a small, defined offer rather than relying on a steep discount: suggestions include a paid diagnostic with three interviews and a search/RFQ teardown, or a fixed-fee RFQ-page task measured by enquiries; another commenter recommends a narrowly scoped pilot with one clear success metric.
A PM workflow question contrasts writing a spec for developers to prompt from independently with PMs and developers prompting together in one session; it asks what fails and what drives teams to switch, but provides no answers or outcomes.
Future AI adoption waves could come from improving the harnesses around existing models, even without major model advances.
- The startup says it chose inference efficiency because serving models efficiently is economically important; it began with harness optimization, expanded to weight updates, and aims to co-optimize stack components that affect one another.
- For measuring AI improvements, the founders count human hours and experimentation alongside compute and money, and track experiment costs on an internal “bleederboard.” They also describe trying to replicate results, detect noise or reward hacking, and assign an engineer to challenge findings.
- Evaluation speed can constrain product progress: the discussion contrasts fast, cheap evaluation in coding and math with drug discovery, where wet-lab experiments and clinical trials can take months.
For technical software aimed at a small, conservative B2B market, use the first customer and account-by-account research to find the specific purchase trigger and unmet job that justifies a new tool or budget, rather than assuming buyers will replace an existing product. One founder’s first PO came from offering a new capability at a price that did not take up much of the buyer’s budget.
After the first PO, verify that the product delivers on its promise before relying on the customer as a reference.
A commenter shares mentoring-tested challenges for PMs and entrepreneurs: organize one basic product artifact each week; speak with at least one user weekly for 12 weeks, and every four weeks hold a discovery meeting with at least three stakeholders to discuss three customer insights relevant to the roadmap. Also create a stakeholder list and schedule 25-minute meetings with each stakeholder to ask about their personal objective and how you can contribute.
