Intro
For most of my career, the hard part of product was getting things built. Scoping, sequencing, negotiating for engineering capacity, waiting. A lot of a PM's value came from managing that scarcity well.
That constraint is mostly gone. I watched it go over three years leading the product org behind a $1.6B enterprise sales business at Intuit, on a platform where a decent portion of what we shipped was configuration (low-code/no-code) rather than code-heavy.
Two forces did it. Low-code platforms, where a routing rule, a page layout, or a scoring model is a config change instead of a release. And AI, which collapsed the cost of the artifacts PMs used to spend weeks producing: requirements, analysis, competitive scans, first drafts of everything.
What surprised me was what did not get easier.
The two things that stayed hard
Deciding what to build. Automating lead routing sounds like a technical problem. It is not. It is a set of contested business decisions. Who owns the account when marketing and sales both have a claim. What happens when a record lands in two campaigns at once. How you handle territory mappings that change every two weeks. What "fair distribution" means when reps carry different books. No platform resolves that. It gets resolved in a room with sales ops, marketing, analytics, and finance, all optimizing for different things.
Getting people to use it. We shipped things that worked and did not get adopted, because reps did not trust the data underneath. A routed lead a rep does not believe is worse than no lead, because now they have to go verify it. Adoption was almost always a data trust and enablement problem, not a product quality problem.
Cheap build does not make these easier. It just means you find out faster that they were always the real work.
AI as a productivity booster, not a judgment outsourcer
The rule I landed on: AI produces the option set. It does not pick.
Where it paid off:
First drafts of requirements, so the team argued about content instead of structure
Synthesizing unstructured input (call transcripts, win/loss notes, rep feedback) into testable hypotheses
Generating four ways to solve something quickly, so the debate started at the tradeoffs
Stress-testing my own reasoning by asking for the strongest case against a decision I had already made
Where it consistently failed:
Choosing between two defensible options with different risk profiles
Knowing which stakeholder's silence means no
Judging whether the org can absorb a change right now
The failure mode is worth naming precisely. AI output is fluent, and fluency reads as confidence. It produced answers faster than we could pressure-test them. The fix was boring: label what is a fact and what is a hypothesis, in writing, every time. If a number came from an assumption, say so in the same sentence as the number.
Prototyping moved from output to input
High-fidelity used to be the last step of design, produced after the decision was made. Now it is the cheapest way to make the decision.
On a configuration platform this goes further, because the prototype and the product are nearly the same object. You can stand up a working version in a sandbox and put it in front of ten users this week.
The value is not saved design hours. It is that arguments end. When two leaders describe a workflow differently, showing settles it in one meeting instead of three. And you learn early that a flow everyone approved on a slide is unusable in practice.
The pattern that worked: real surface, small blast radius, real signal. Pilot with ten sellers before scaling to three thousand.
What this does to the lifecycle
The old sequence was idea, requirements, build, launch, measure. Build was the long pole and everything else was scheduled around it.
What I ended up running looked closer to: idea, prototype, decision, configure, adopt, measure. Two changes mattered most.
Requirements documents became decision records. Less "here is the spec" and more "here is what we chose, what we rejected, and what we assumed." The spec was going to change in two weeks anyway. The reasoning is the part that has to survive.
Instrumentation and enablement moved earlier and stopped being skippable. When you can ship in days, what makes you slow is not knowing whether it worked, and not having prepared the people who have to use it.
How to set PMs up for success now
Judge them on adoption, not launch. Launch is a date. Adoption is a number. Making launch the finish line produces a lot of shipped software nobody uses.
Stop rewarding artifact volume. Documents are cheap now. Ten crisp pages reasoning through an ambiguous decision are worth more than sixty pages of specification.
Put them next to the operators. The PMs who sat with reps made better calls than the ones who read dashboards. That gap widened as tooling improved, it did not narrow.
Draw a clear line on AI. One version I have used: use it for anything you would have delegated to a contractor, never for anything you would have escalated to your VP.
Own configuration debt. Low-code makes rules easy to add and hard to remove. Nobody puts "delete forty routing rules" on a roadmap, and eventually somebody pays for that.
What to prepare for next
Agents change who the user is. When software executes the workflow instead of assisting it, the PM is writing policy and guardrails, not screens. The requirements become: what is the agent allowed to do, when does it hand off, and what does it do when it is unsure.
That makes evaluation a core PM skill. Not conversion tests, but eval sets on system behavior: accuracy, escalation rate, failure modes, and an explicit definition of unacceptable. Most PMs, myself included, are learning this late.
Which raises the value of the one thing that has not gotten cheaper: defining what correct means, and standing behind the call. That was always part of the job. It is now most of it.
