why PMs are more important than ever

why PMs are more important than ever

Making a feature easier to build makes it harder to turn down.

Someone has a reasonable idea. An engineer produces a working demo. Suddenly, a suggestion feels like a decision, and asking whether customers need it sounds like holding the team back.

That is why I think product management becomes more important as AI improves. Teams need people who will protect customer value and keep good work from being buried under everything else they could ship.

A LinkedIn post by Aman Suri, whose visible profile describes him as a Product Leader in Casino & Hospitality Tech, prompted this piece. He contrasts the friction of physical changes with the ease of adding software features. His point about resisting unnecessary additions is worth taking further: AI can also make PMs much better at deciding what deserves to exist.

Cheap code still creates expensive commitments

Moving a wall forces a conversation about whether the change is necessary. Adding another software option can feel harmless, especially when a prototype appears before anyone has properly discussed the problem.

The bill arrives elsewhere.

A new setting needs an understandable label. Support needs to explain it. Someone must test how it interacts with existing behaviour, review its permissions and maintain it when the surrounding system changes. Customers have to work out whether it matters to them.

Even a useful feature can make the whole product harder to use. A booking tool gradually becomes a marketing platform, an analytics suite and a half-finished CRM. Each request had a sponsor. Nobody protected the original job.

AI can reduce some implementation costs. It does not make maintenance, security, adoption or opportunity cost disappear. The team working on an optional dashboard is still spending attention that could have gone into fixing unreliable bookings.

Nor should we assume every team is already faster. DORA's 2024 research reported individual benefits from AI alongside delivery-stability and throughput tradeoffs. Those findings do not establish what today's tools will do for a particular team. They are a useful warning against treating faster individual work as proof of better delivery.

Gatekeepers should protect the work

I like the idea of PMs as gatekeepers, provided we are clear about what they are guarding.

They should protect a customer's ability to finish a task without learning five new things. They should protect engineers and designers from a roadmap that changes whenever someone brings a persuasive demo. They should protect a coherent product from becoming a collection of unrelated requests.

They should also be willing to approve a good idea they did not originate.

A PM who insists on attending every discussion or approving every experiment becomes another constraint. Product judgement belongs in the team. Engineers understand technical consequences. Designers notice interaction costs. Support hears where customers struggle. Customers can expose assumptions that an internal meeting will happily preserve.

The PM's responsibility is to bring that evidence together, make tradeoffs explicit and ensure someone owns the decision. A founder or another team member may do this in a small company. The work matters more than the title, and having the title does not make someone's opinion evidence.

AI gives PMs more ways to learn

The optimistic part gets lost when this discussion becomes an argument about saying no.

A PM can use AI to organise interview notes, surface possible themes in support tickets, explore competing explanations and produce prototypes that customers can react to. With appropriate data permissions, it can help draft analysis queries and examine different cuts of a problem.

That can leave more time for customer conversations and difficult decisions. It can also let a team test an idea that previously seemed too expensive to investigate.

The outputs still need checking. A neat summary can hide disagreement between customers. A plausible query can use the wrong denominator. A convincing prototype can conceal a workflow nobody would tolerate in daily use.

Use the summary to return to the source material. Check the query against known cases. Put the prototype in front of someone with the problem. Keep a named person accountable for the conclusion and the decision it informs.

A prototype is permission to investigate

Imagine a team building scheduling software for independent salons. This is a hypothetical example, not a customer story.

The team hears that empty appointment slots are costing owners money. AI-assisted development makes several ideas look affordable: a forecasting dashboard, promotional messages, dynamic pricing and an automated waitlist.

Shipping the whole bundle would create several businesses' worth of decisions. Who receives an offer? Can a price change after someone books? What happens when two customers accept the same slot?

The PM first helps the team narrow the problem. Suppose interviews suggest owners already know when a cancellation happens; their difficulty is contacting willing customers quickly enough. That would give the team a reason to investigate a waitlist before building forecasting.

Start with a clickable prototype using invented appointment data. If that makes sense to owners, try a limited, consent-based pilot in which staff review suggested recipients and send the messages themselves. Agree beforehand what improvement would justify continuing, how much staff effort is acceptable and which errors would stop the pilot.

Measure whether slots get filled, alongside unwanted messages, booking conflicts and staff workload. An attractive demo earns a test. The evidence from that test informs whether automation deserves a wider rollout.

Put the scrutiny where commitment begins

A disposable prototype using synthetic data should be easy to try. Sending real customer messages or changing production prices deserves more care. Apply scrutiny according to exposure, reversibility and potential harm, rather than making every idea pass through the same ceremony.

Before committing a feature to the product, ask:

• Whose problem are we solving, and what evidence says it is worth solving now?
• What should improve for that customer, and how will we notice?
• Could we test the assumption or improve the existing workflow without adding a permanent feature?
• What will this cost to explain, support, secure and eventually remove?
• What are we delaying, and who owns the decision to continue, change course or stop?

Keep the answers short enough that the team will use them. Revisit them after the test, particularly when the result disappoints.

PMs should welcome cheaper experimentation and be demanding about lasting commitments. At the next roadmap review, ask which AI-enabled work helped the team learn something, which improved a customer outcome, and which merely added another thing to maintain. Give the team permission to remove that last category.