Software can now be built in days. The product managers who thrive won’t be the fastest builders. They’ll be the ones who still make time to think.
Every night at 11 pm, an AI agent quietly did part of my job.
It read three spreadsheets full of feature requests from our customers, skipped the ones we already had, and added the genuinely new ones to our master list, each with a clear description. By morning, the list was current. Nobody had touched it.
That agent, along with the automations around it, gave me back 16 hours a week. Two full working days.
Here is the uncomfortable truth about those two days: the work the machines took over was never the important part of my job. It was simply the part that filled my calendar. What was left when the machines were done was much smaller, and much harder.
That is how AI is really transforming product management. It isn’t replacing the product manager. It is stripping the job down to the one thing it was always meant to be: deciding what is worth building. And it is making that one thing harder than it has ever been.
The gift we didn’t know we had
For most of software’s history, the slowest part of shipping a feature was building it.
The rhythm was familiar to anyone who has worked in tech. A product manager researched the market, studied competitors and wrote a requirements document. The work was broken into smaller pieces, debated, scheduled, built, tested, released and monitored. It took weeks, sometimes months.
That slowness was frustrating. It was also a gift. While engineers wrote code, product managers had time to sit with a problem, talk to customers, and change their minds before it was expensive to do so.
AI has taken the gift away. Developers using AI coding tools such as Cursor and Antigravity can now build in days what once took weeks. Everything downstream of the thinking has accelerated. The thinking itself has not, and the pressure to keep up is quietly squeezing it out.
A weak idea used to meet friction at every stage: in review, in planning, in the long weeks of building. Now it can be finished before anyone has stopped to ask whether it should exist.
The first-answer trap
The danger shows up in a small habit that almost everyone in my profession will recognise.
Short of time, a product manager asks an AI model to research a new feature. Within seconds it returns a long, confident, beautifully organised answer. We read the first few paragraphs. We skim the rest. And its suggested approach quietly becomes our approach before anyone has checked whether it solves the customer’s actual problem.
The trouble isn’t that the answer is long. It’s that it is fluent. A polished answer feels like a considered one. Its length doesn’t inform; it hides. The wrong assumption sits in paragraph six, where nobody reads.
Worse, the model only knows what it is told. Give it thin context, and the feature is pointed in the wrong direction from the moment it is conceived. Every line of code written afterwards, however quickly, inherits the mistake.
The result is a feature nobody uses: one more trophy on a shelf labelled “features delivered this quarter,” solving no one’s problem and impressive only in a slide deck.
AI doesn’t make people lazy. It makes laziness look like productivity.
What I handed to the machines
At Petpooja, a restaurant-software company, I tried the opposite. Instead of letting AI do my thinking, I let it do my chores.
Feature requests reached me through three shared spreadsheets: one kept by our sales team, and one each by our first- and second-line support teams. Every week I read all three, merged the duplicates into a master list, and kept our project-tracking tools in sync by hand. The upkeep alone ran to more than a dozen hours a week.
Then came the meetings. Up to 90 minutes every week with seven people, including my manager and our VP of Sales, so that everyone knew what had happened to their requests. Another half hour with the eight-person support team, for the same reason.
So I made a list of everything I did, day in and day out, and sorted it into two piles: work that needed my judgment, and work that didn’t.
The first pile was short. What to build. What not to build. In what order.
Everything else was plumbing. So I automated the plumbing.
The sales team cleaned up its own list at the source, removing duplicates before they ever reached the agent. Each night, the agent checked every new request against the master list and added only the ones we didn’t already have. If sales and support asked for the same thing, it became one item, not two.
The middle I kept for myself: deciding which requests mattered, and working out how each should be built into our product.
Once I had, another automated job took over. Every day, it turned those decisions into properly written tasks for our developers, placed them in the queue, and sent each one’s status back up the chain, first to the master list and then to the original spreadsheet. Whoever raised a request, in sales or support, could now see for themselves whether it had been picked up and where it stood.
The weekly status meetings were no longer needed.
Machines at both ends. Judgment in the middle. In all, the system saved more than 25 hours a week across sales, support and product. Sixteen of them were mine.
The rule that made it work
None of this would have been safe without one rule: nothing ran on its own until I had decided how I would check its output.
Every workflow started with three questions. What goes in? What should come out? What context does it need? Once the goal was clear, I could define how to verify the result. A workflow wasn’t finished when it ran. It was finished when I could confirm it ran correctly.
That rule is the antidote to the first-answer trap. If you cannot say how you would verify what an AI produces, you are not ready to rely on it.
It is also a test anyone can run this week. List what you do. Sort it into judgment and plumbing. For everything in the second pile, define the input, the goal and the context, and decide how you’ll check the result before you build anything. Then spend the time you win back on the first pile.
The job that’s left
So what did I do with two extra days a week?
I spent them on the work no automation could touch: deciding what our eleven developers should build next, and making sure they were never left waiting on me. When developers build faster than ever, the product manager cannot be the bottleneck.
This is the new shape of the job. A product manager now leads two kinds of teammates: people and AI agents. One brings judgment, context and empathy; the other brings speed and stamina. The product manager’s work is to orchestrate both into products that are not only beautiful but genuinely usable.
The obvious objection is that AI will soon make the decisions too. Perhaps it will draft them. But deciding what a product should not do means weighing customers who want different things, colleagues with competing priorities, and a business with limited time and money. Those are trade-offs with consequences, and someone has to own them. A model can list the options. It cannot be held accountable for the choice.
Your turn is coming
Product managers are simply first in line. The same sorting is coming for anyone whose work mixes producing and deciding: lawyers, analysts, marketers, editors.
It will not be comfortable. Real change rarely is. Some people will deny it is happening. Some will try to suppress it. A few will have the nerve to go through it, and come out the other side with a sharper, smaller, more valuable job.
Think of it this way. We used to drive an ordinary car. AI has handed us a supercar: new controls, a far more powerful engine, and a road that moves faster every month. But a faster car doesn’t make you a better driver. It makes your mistakes arrive sooner.
Those who never learn the new controls will either crawl along or crash. Those who do will set the pace for everyone else.
The engine is AI.
The steering is still ours.
Shubham Borde is a senior product manager who builds digital products that make everyday work simpler, and, increasingly, the AI workflows behind them.
