A careers list went round recently — ten jobs that will dominate the next ten years. I am going to take all ten seriously, one post each, because lists like this get shared far more than they get examined.
I should say up front which ones I actually hold: AI automation, fractional executive, infrastructure, and trades business owner. Four of ten. For the rest I will be explicit about where I am reasoning from adjacent experience and where I am guessing.
This one I hold by function and not by title.
What the title suggests
Someone who decides which AI features get built. Prioritises a roadmap, writes specs, talks to users, ships models into products.
What it actually is
Deciding what not to build, repeatedly, against enormous pressure to build it.
I am the product manager of my own systems, and the decisions I am proudest of are almost all deletions. There is a line in my own project notes that reads "do not build a fourth importer." I wrote it after noticing that the CRM had three working importers, a pipeline holding thousands of leads, and almost none of them ever contacted.
The fourth importer would have been satisfying to build. It would have taken a day, worked perfectly, and moved the business precisely nowhere, because the constraint was never getting leads in. It was that nobody was working them.
That is the actual job. Not choosing between features — choosing between the feature you want to build and the unglamorous thing that is genuinely blocking you. They almost never feel the same at the moment of decision.
Why AI makes this harder, not easier
The old constraint on building the wrong thing was cost. Building took weeks, so somebody asked whether it was worth weeks. That question was doing enormous quiet work, and it was doing it for free.
When building takes an afternoon, nobody asks. The idea arrives, the tool makes it real before the doubt catches up, and you end up with a system full of things that work and do not matter.
I have shipped that system. The way out was not better prioritisation frameworks. It was writing down, in the repository, the thing the system is actually short of — and making the next person read it before they build.
What I would look for in someone doing this job
Not a roadmap. Ask them what they killed this quarter and why, and listen for whether the reason is about the user or about the team's capacity. Ask what their product is currently short of, and see whether the answer is a feature.
If someone tells you their product is short of a feature, they have usually not looked hard enough. Most products are short of users who know they exist.
Where I come into this
If you want evidence rather than an opinion before you decide what not to build, the free website check is a start: it reports what is actually broken on your own front door, which is often not the thing at the top of the backlog.
I spend most of my time on this decision for other people's businesses — what belongs in software, what belongs in a rule, and what should not be built at all. If you have a backlog and a suspicion that the top of it is wrong, tell me what you are building. If the honest answer is that your roadmap is fine and the problem is distribution, I will say that instead.
This is post 1 of 10 on that careers list. The series runs through all ten, including the ones I have no business commenting on — I will say so when I get there.
