AI changes your week one task at a time

Every task in your week is left alone, helped, taken over, or created by the model. Sort a real one that way and almost nothing is left alone.

Each square is one task in your week. Every task ends in one of these four.

Unchangedstill yours alone: the no to your biggest account
Augmentedyours, with help: framing the problem
Automatedthe model does it: release notes
Created by AInew work it made: reviewing what it drafted
Customer interview
40 interview summaries
Survey tallies by hand
Session replay
Accounts behind a request
Product context upkeep
Problem framing
Backlog prioritisation
Roadmaps merged by hand
The no to your biggest account
The PRD
Review of AI drafts
A/B test
Evals for good enough
Status chasing in Slack
Tickets retyped by hand
What an agent may do alone
Bug triage
Release notes
Owning the wrong call

Your week, task by task

Your calendar, and the work that never reaches it. A week runs in one order: listen, decide, define, build, then learn from what shipped.

AI changes work at this level, one task at a time. It helps, it takes over, or it leaves the task alone, and the answer is different for every one.

Your list has always moved

You no longer tally survey results by hand, chase a status a tool already shows, or retype tickets between two systems. Software took those over 15 years, and nobody called it a crisis.

Session replay and A/B tests arrived in the same period. They are routine now.

Most tasks now have help

Reading got cheap. Everything said in your calls and tickets can be read, grouped, and traced to the account that said it. You frame a problem from all of it, not the 3 examples someone remembered.

You still frame it and you still write the PRD. The document looks the same, so the change shows in your hours, never in your delivery metrics.

Some tasks leave your hands

Interview summaries, first-pass bug triage, release notes, the list of accounts behind a request. Each ends in a document nobody argues with.

None of them needed your opinion. That is what made them the first to go.

AI adds tasks of its own

  • Reviewing what the model drafted, before a customer sees it.
  • Writing the check that lets an agent call a draft done.
  • Deciding what an agent may do without asking.
  • Keeping your product context current.

None of it is in your capacity plan yet, so it falls to whoever notices.

What stays yours

Almost nothing came through untouched. What did is where someone has to be accountable: the no to your biggest account, and owning the call that turned out wrong.

Neither gets cheaper as models improve. Staff for them.

A better model does more

More drafts an hour, and more to review at the end of each. The gain only lands where four things are true.

  • Permission to try.
  • The habit of trying.
  • A review step people trust.
  • Context the model can read.

Model quality is the vendor’s problem. These four are yours. The last one is the one you have never written down.

Sort your own week

  • Unchanged. Protect it, and staff it.
  • Augmented. Pays for itself once the model knows what you know.
  • Automated. Needs a test and an undo first.
  • Created by AI. The checking work the rest of the week made.

Then sort your customers’ week the same way. What is worth taking off their hands is a roadmap, in order.

A model can write your PRD. It cannot know why you killed the last one.

The constraint is context

Ask a frontier model for a specification and you get a competent specification. Ask for yours, and it cannot write it. The migration you are half way through, the account that churns if permissions change, the approach engineering rejected in April. All of it existed. It lived in a Slack thread, a call recording, and one person’s memory.

What the model gets

A ticket title and a label

What it needs

The evidence underneath it

The calls, tickets and research that made this worth solving, and which accounts they came from.

The decision and what lost

What the team chose, what it rejected, and the reason. The part that never survives the trip into a backlog.

The constraints that still bind

Product rules, prior commitments, and the parts of the system that are not up for negotiation this quarter.

What already failed here

The approach engineering tried in April, and why a model proposing it again costs the team a week.

Drafting got cheap. Reasoning did not.

Nobody needs to file a specification a model rewrites in 9 seconds. The reasoning it was supposed to carry does not come back that way: why this, why now, on whose evidence, and what the team said no to. Product teams have always produced that reasoning and mostly never stored it.

Signal40
Insight0
Opportunity0
Idea0
Initiative0

Evidence arrives unsorted

A quarter of your customer contact: tickets, sales calls, a research session, 3 Slack complaints, a churn note, one long email from your largest account.

None of it is a decision yet. Some of it is not a problem yet.

Most of it goes nowhere

It stays in a recording nobody reopens and a document nobody links to.

It never shows up as a miss, because nobody knew there was a decision to make.

The rest gathers into insights

11 customers saying the same thing is a different fact from one customer saying it 11 times.

An insight is the evidence that gathered, not a summary of it. Which accounts said it matters as much as how often.

Insights point at problems

Bigger than a ticket, smaller than a roadmap theme, and still carrying every piece of evidence that reached it.

This is the level where you can say no and mean it.

Problems split into ideas

Each problem attracts several ways to solve it, and the evidence divides between them.

Teams that start here, instead of with the evidence, ship things nobody needed.

The winners become work

Scoped, sequenced, agreed. The ideas that lost keep the evidence that reached them, so next quarter nobody works them out again.

The path back

Pull an initiative and the trail is still there: which ideas competed, which problem it solves, which insights support it, which evidence started it.

An engineer needs that on day one. An executive asks for it in the QBR. An AI builder has to be handed it before it writes anything.

We keep the part that cannot be regenerated

Zentrik reads demand from the source, so calls, tickets, research and your Jira history become opportunities your team can inspect. You make the call once, with the evidence already attached. The decision then travels into specifications, into Jira, and into the AI builders your team already uses, carrying the customer story and the product rules rather than a ticket title.

SignalInsightOpportunityIdeaInitiative

AI helps structure the evidence and prepare the work. People own the judgment. That line is the whole product.

Questions teams ask

Will AI replace product managers?

The role is the wrong unit to argue about. AI takes on tasks, and a product manager runs about 20 of them in a week. Sort a real week into unchanged, augmented, automated and newly created work and very little lands in the first column. What does is where a person has to be accountable rather than capable: telling a large account no, owning a call that turned out wrong. Everything else now has help, including framing the problem.

Why has AI not made our product team faster yet?

Usually because the constraint is context. A frontier model writes a competent specification and cannot write yours, because the migration you are half way through, the account that churns if permissions change, and the approach engineering rejected in April are not written anywhere it can reach.

What replaces the PRD once drafting is cheap?

A decision with its evidence still attached. A document a model regenerates in 9 seconds is worth less than the reasoning it was supposed to carry: why this, why now, on whose evidence, and what the team said no to.

The four states used here (unchanged, augmented, automated, created by AI) follow the task-level framing in Anthropic’s Economic Index work. Which tasks land in which column is our own read, and the argument for it is the page.