We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Consumer AI may compete less on model identity than on usefulness and access. Tony Fadell argues that models are already good enough for most consumer needs, and that users will want AI to be useful, easy to reach, and free or bundled with something they already pay for. Paul Graham offers a complementary choice for builders: work close to the technology by making LLMs, or close to customers by using AI to give them what they want. For PMs, the implication is to build a real edge in capability or in solving a customer job—not rely on model novelty alone.
Shipping may be cheaper; maintenance and user attention are not. A former startup employee says CEO-led weekend AI coding hackathons produced features with near-zero adoption; another PM reported roughly 30 unused features that remained in the product and added maintenance and testing burden. Commenters also point to ownership and support tickets, and warn that features outside the product’s job-to-be-done tax users’ attention and obscure valuable functionality.
Tactical Playbook
Turn “launch and see” into a bounded experiment. One commenter recommends agreeing before an AI coding sprint on a single 30-day adoption threshold and removing the feature if it misses; ship off by default behind a flag to a subset of accounts so removal is a toggle, not a fight. Track repeat tickets per feature alongside adoption: usage alone can hide the maintenance cost.
Design agent permissions around the task and its consequences. A Muse user had to approve sending a message after already instructing the agent to send it; the article also says Claude Code users approve about 93% of prompts, a pattern Anthropic calls approval fatigue. Start with read-only access and expand only when needed; distinguish drafting from sending and viewing production from changing it. For hard limits, make them architectural: Replit separated development and production databases so its Agent cannot change production during development.
Case Studies & Lessons
A product-operations leader described roadmap planning that consumed two months of every quarter making slides, while inconsistent Jira definitions and the lack of a shared account of what teams planned to do—and why—made the roadmap hard to use. Standardizing the work hierarchy proved easier than getting thousands of people to adopt it. The organization now links initiatives to expected value and spend, and the leader said a Jira-backed app was intended to replace the planning slides. The lesson: fix the underlying work data and adoption problem before polishing the roadmap presentation.
The same leader’s PM capability framework used 12 skills across four themes, with employee self-assessment and manager feedback to prompt development conversations. After six months spent aligning the language, 150 people completed the assessment; engineering, data, and UX later adapted discipline-specific versions. He says the shared framework also made promotion decisions more consistent and transparent. Keep the skill intent consistent, but let teams define how it applies to their work.
Career Corner
For a Founding PM role that drew hundreds of applications, Deb Liu advises making fit unmistakable: connect your experience to the company’s actual needs, show one finished product or prototype, and seek a reference from someone who knows your work. She also reports that direct outreach from an unconnected candidate led to a meeting.
A PM offer-negotiation guide reports that five coached candidates won increases without an offer being pulled, including two who were unemployed after layoffs. Its method is to calculate effective annual compensation over expected tenure, including cash, equity likely to vest, and sign-on; discount private equity for payout risk and time to liquidity. For a two-to-three-year stay, it recommends prioritizing sign-on and front-loaded vesting; for four or more years, base and equity.
