Cheap building moves the hard part

A former PM working in e-commerce ops says he built an analytics system "in a couple of days." It replaced a Fabric-to-Power BI setup that cost a lot in freelancer fees and kept breaking. He chose to build add-ons for the order-management system instead of replacing it r/ProductManagement. His case for PMs is that AI gets "80-90%" of system requirements, "and sometimes that remaining 10% is huge." He adds that nobody is posting jobs for this work yet, so you have to create the market yourself r/ProductManagement. Replies pushed back on the cost. Building is cheaper, but "the cost of alignment. Stakeholder management. Making product and technical decisions" is not r/ProductManagement. Teams also bought SaaS to hand off maintenance and to get deep domain knowledge that is hard to find r/ProductManagement. Hiten Shah takes the macro view. He's "increasingly convinced" that most consumer and enterprise software "will be completely rewritten" @hnshah.

Domain depth and finances as PM leverage

Productify argues that every industry keeps its own scoreboard: margins, unit economics, regulation, market share. A product can launch beautifully and still be "a success only on paper" Productify by Bandan. Knowing which problems are already solved commodities and which are still open "is itself domain knowledge," and that knowledge saves months Productify by Bandan. The author's advice on AI: it makes "breadth cheap," so use the time it saves to go deeper on fewer problems Productify by Bandan.

On One Knight in Product, Simonetta Batteiger makes the financial version of this argument. Token-heavy AI features add "a new margin risk." Costs should be tracked by user, workflow and interaction pattern, and doing that "starts in the code" One Knight in Product. Her rule of thumb is that a team should return at least five to seven times what it costs. She also notes that most PMs "don't know what their team costs" One Knight in Product. Her fix is to ask finance which revenue levers matter. She says no one in her course has been refused those numbers One Knight in Product. She also says AI's non-determinism means PMs need rollback options, kill switches and evals in case a new model drifts One Knight in Product.

A r/ProductManagement thread on "PM career as pursuit of power" debated where authority comes from. One reply: "There has to be one person with final decision power, and that is typically the PM" r/ProductManagement. Another said a good PM shares many decisions, guided by the team's expertise and the problems customers will pay to solve r/ProductManagement.

Evals: the demo isn't the evidence

Aakash Gupta shows why a clean demo proves little. An agent that fails 3% of the time still passes all 50 tickets in about 22% of runs Aakash Gupta. His "real" rollout sequence: an LLM judge says "95% good and catches zero failures." Then comes a 5% ship where "evals go up, usage stays flat." After that, a power user eats the margin, and a new model "calls tools differently" Aakash Gupta. His conclusion is that what decides success sits around the model: context, tools, permissions and checks Aakash Gupta.

AI PM listings: a few years of AI proof on top of normal tenure

Gupta also hand-classified 113 AI PM listings from LinkedIn. 69% explicitly wanted AI or ML experience, or 55% on a softer reading. Only 14 required that experience in production or at scale Aakash Gupta. Plain "Product Manager" listings asked for AI experience almost as often as AI PM listings (66% vs. 70%). The median listing asked for 5 years of PM experience Aakash Gupta. He suggests building real AI products people actually use, as opposed to fabricated credentials Aakash Gupta. This adds to his earlier 651-role analysis.

Briefly

• Row, then steer. Lenny Rachitsky summarized a playbook for PMs at big companies, from Atlassian CPO Tamar Yehoshua. The PM and designer vibe-code an alpha. Once it shows pull, they bring in engineers. Then the PM steps back to align, prioritize and unblock @lennysan. It's a practical answer to the "no one steering" problem Atlassian described earlier.
• Rekhi's six-month workflow update. Sachin Rekhi now treats Codex as being as powerful as Claude Code @sachinrekhi. He calls local markdown context files "an anti-pattern" now that MCP-backed shared document repositories exist @sachinrekhi. He also recommends rebuilding design systems in code, documented in Storybook, so engineers can turn prototypes into production code faster @sachinrekhi.
• Companies agents can read. Building on Patrick Collison's argument, Hiten Shah says an agent should understand a business well enough to decide when it's relevant and complete the purchase. He thinks founders will have to design for this from the start @hnshah.