We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Faster output, same outcomes
At ProductTank Berlin, Marty Cagan pointed to what McKinsey calls the "AI productivity paradox." Teams using AI tools move faster, "but no, they are not getting any real different results… the output gets a lot faster, but the outcome is still hard" . His main warning is about companies still using the "project model," where work is driven by feature roadmaps with dates. In that model, a PM's or designer's tasks can be handed to agents, and he expects those companies to end up with only engineers . In the "product model," faster delivery shifts the focus to strategy and to the craft of finding solutions that win in crowded markets: "the cheaper delivery becomes, the more important the craft and strategy becomes" .
Cagan also gave some practical guidance:
- Prototypes are for learning, not for shipping. Use them to test ideas with customers, stakeholders, and engineers. Faster delivery still costs tokens .
- PMs own business viability. That covers channels, costs, runtime and monetization, compliance, legal, and privacy .
- For AI products, evals are product discovery. They need to continue across discovery and delivery . Don't put a serious promise on the roadmap until you've done discovery on it, or switch to roadmaps built around outcomes .
Survey data from a sponsored post points the same way. Aakash Gupta summarizes Atlassian's State of Product 2027, a survey of 1,000 senior product professionals. 80% say AI helps them ship faster, yet customers don't get value any sooner, and 69% say decision-making is as slow as before . Only 24% say Product leads cross-functional work, down from 47% in 2025 . Prioritization "still runs on opinion" because the inputs are spread across many tools . In a separate note, Gupta says job postings at OpenAI, Anthropic, and Google DeepMind ask PMs to write evals and prototype with code. Meanwhile, the tickets-and-standups side of the job is being automated .
OpenAI's Dots: trust controls are the product
A Mind the Product breakdown describes OpenAI's Dots as an always-on agent. Each one runs on its own cloud computer and browser and looks for work without being asked . In a launch demo, a Dot noticed a product change, flagged that the launch slides were out of date, and offered two revised versions. A human picked between them . The presenter argues the controls are the real UX. Users decide whether each action runs automatically, needs approval, or is never allowed. There is also a status view, an automatic review of consequential actions, and a stop option . A test question for teams building agents: "what's the most consequential thing your agent can do without asking?"
Implications for PMs:
- Agents will use your product. Test whether they can get through login, onboarding, and modals. Learn to identify agent traffic, because it will distort session metrics .
- Per-seat pricing may not fit. Usage can grow while the number of human users shrinks .
- New buying route. Eligible US enterprises can apply existing OpenAI spending commitments to approved software from 32 marketplace partners .
- Vendor questions. OpenAI held back GPT 6.1 Astra for not staying within scope and authorization, and the launch included no error rates. Ask vendors how they test for this .
Charging agents for API access can backfire
On SaaStr's The Agents, the hosts say their agents make 35,000–40,000 API calls a day. One estimate put the cost of that access at up to $240,000 a year . Their agent's first suggestion was to call the API less and copy the system-of-record data into Postgres . The bigger risk, they argue, is new deals: "I doubt an agent would recommend picking any system of record that materially charges for API access" .
Owning the work, not just retrieving it
On a16z, procurement startup LEO's founder discussed a four-step ladder for agents: retrieval, process, policy (applying judgment), and principal (weighing broader trade-offs). Incumbents were described as offering mostly retrieval with "a little bit of process" . LEO found that invoice matching was only about 20% of the work. The other 80% was exceptions such as fraud and mismatches, so it moved to handling those .
Practitioner notes
- "Which customer?" An r/ProductManagement thread on sales-driven requests reached consensus: a request is "a data point," not a spec. Find out who asked and why, and talk to the customer directly . Another commenter suggests waiting a couple of weeks to see whether the request comes up again, as a check on recency bias .
- Synthesis. Teresa Torres notes that teams often skip deep synthesis after interviews and keep the two or three things they remember. "We're competing with making shallow synthesis better" .