Going faster in the wrong direction

Marty Cagan says AI has mostly sped up the "project model." In that model, stakeholders put features on a roadmap and feature teams ship output. Now those teams are "going faster than ever but not seeing improved results" Thoughtworks. He thinks even "the most stubborn CEOs" now see that the real problem was always figuring out what to build, and slow development hid it Thoughtworks. In the product model, leaders assign problems with outcomes attached. Empowered teams then find solutions that are valuable, usable, feasible and viable. There, AI helps with discovery as well as building Thoughtworks. He says efforts usually fail on value and viability, not usability or feasibility. A solution has to beat competitors, and it has to work for legal, compliance and sales, not just one stakeholder Thoughtworks.

On the "SaaS apocalypse," Cagan points out that serious SaaS products hold thousands of business rules that often live only in the code. In three years, he hasn't seen anyone replace an ERP system by building their own Thoughtworks. Instead, vendors are turning their internal platforms into external ones that agents can use. He thinks that makes them more valuable, not less Thoughtworks.

Model PM jobs are hiding under other titles

Aakash Gupta read 46 open model PM postings. Few are called "model PM." The titles include PM, Research; PM, Core Models; Post Training; and Safeguards Aakash Gupta. He says the work underneath is six tasks: pick what the model gets better at, turn "better" into an eval, read transcripts of failed runs, specify how the model should behave, make the ship call, and launch Aakash Gupta. The median posted base salary is $345K, and OpenAI's Core Models PM role goes up to $490K. Only 1 posting mentions a PhD and 8 ask for Python or SQL, while 76% ask for eval experience Aakash Gupta. His advice to candidates is to show one eval set and one behavior spec built on a model you already use Aakash Gupta.

Beam: what early access actually showed

Hiten Shah published how Beam's early access worked. It started with a question on X about multi-Mac setups, which got more than 100 replies. The replies also showed where Beam was a poor fit, for example when SSH already did the job @hnshah. Of 42 people who filled out a baseline form, 28 had the other Mac nearby. That changed the problem from "remote access" to reaching something on another Mac while working on the one in front of you @hnshah. Shah treated repeat choice as the signal: what people opened the next time they needed an app on another Mac. Some chose Beam over Screen Sharing, and others still went back to Screen Sharing @hnshah. One caution from the launch: Beam 1.0's new accounts and plans caused sign-in loops for some early users @hnshah. The product hit #1 on Product Hunt on October 19 @hnshah.

Pricing: one base unit, no seat fees

Databricks CRO Ron Gabrisko's advice is to find the base unit that scales with customer value and price add-ons as multipliers on top of it SaaStr AI. Early on, Databricks charged per user plus a platform fee. Customers said each user cost them $1,000. When users became free, "consumption went out the roof" SaaStr AI. His takeaways: start usage-based pricing early, don't mix seats with usage, and don't require big upfront commitments SaaStr AI.

Agent oversight as a design problem

Replit's Amjad Masad says frontier models now do better with simple prompts, and micromanaging them makes results worse Product School. Replit's answer is to make oversight visible:

• a separate thread for each parallel agent
• mobile alerts when an agent is about to go over budget or add a package
• adjusting to how hands-on each user wants to be Product School

The risks were also on display. Andrew Chen has 10 agents with full access to his email and isn't sure "who is running what" @andrewchen. Scott Belsky argues that persistent agents "are liable to backfire without clear boundaries that respect basic rights and procedures" @scottbelsky.

From the PM trenches

• AI on product data. In an r/ProductManagement thread, the practical consensus was:

  • Make the AI show the query behind every number.
  • Test it on something you already know, like last month's active users.
  • Treat its "why" answers as hypotheses to check with users r/ProductManagement.

  Another commenter said the answer to why a feature goes unused "is usually NOT in the data." Use the data to find the segment, then interview them r/ProductManagement.

• What the job looks like now. One PM's org now plans only two quarters ahead. Faster AI-assisted shipping freed room for projects that came out of customer interviews r/ProductManagement. Another PM says AI shifts bottlenecks rather than removing them, and understaffing has forced them to work in code without a software background r/ProductManagement.