How can a product manager stay ahead as the job changes?

Build systems, not just skills. Turn your best calls into written criteria, create a learning loop that tests new ideas on real work, wire repeated tasks into workflows, and check your instincts against results. Each of these keeps paying back after the week you built it.

How do I scale my product judgement?

Take a decision you make well, write down the criteria you use, and add one good and one bad example. That turns a call only you could make into a rule someone else can follow, so your judgement works even when you're not in the room.

What is the difference between a reading list and a learning system?

A reading list collects things to learn. A learning system tracks what you need to learn, tests it on real work straight away, and turns each lesson into something reusable, like a template or a prompt. The reading list grows. The learning system changes how you work.

What questions matter most now that building is cheaper?

Should this exist, for whom, why now, and why us. When prototypes are fast and cheap to make, the scarce skill is deciding what deserves to be built. That has always been the core of the product job, and it is becoming more of it.

Managing Products Got Harder: 8 Ways to Build Systems That Keep Paying You Back

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Managing products just got a lot harder. Learning faster will only get you to survive.

Survival is the floor, not the finish line. The level above it isn't more effort. It's building the systems that keep paying you back.

Being good stopped being enough. Your judgement still wins, but now it only scales when it can work without you in the room. Your expertise has an expiry date, and nobody is coming to retrain you. Experience doesn't update itself. Building got easier, and product got harder.

None of that is a reason to work longer hours. It's a reason to work differently. Here are eight ways to start.

Turn your judgement into rules someone can follow

Your judgement still wins. It only scales when it scales without you.

Take one call you make well, like how you prioritise the backlog. Write down the criteria, plus one good and one bad example. Now the call no longer needs you in the room. Someone else can make it the way you would, and you can spend your attention on the calls that still need you.

Build one learning system, not a reading list

Your edge is no longer just what you know. It's a system that keeps learning for you.

A reading list grows and gets ignored. A learning system changes how you work. Track what you need to learn, test it on real work this week, and turn each lesson into a template or prompt you reuse. The next time the same problem comes up, you start from what you learnt instead of from zero.

Own your own retraining

Someone always taught you the next skill. Not this one. You're among the first to work this way, so the standard is yours to set.

Block time every week to rebuild one part of your role with AI before the market forces you to. Nobody else is designing your next skill. If you wait for a course or a company programme, you'll be learning someone else's version of the job.

Re-test your instincts against results, not seniority

Your instincts were built for a slower game. Left alone, experience turns into bias. Updated on purpose, it becomes judgement again.

Write your assumptions down before a big call. Check them against what actually happened. Update the ones that were wrong. Seniority tells you how long you've been making calls. Results tell you which of your instincts still hold.

Stop asking whether you can build it

Making software is close to free now. Knowing what should exist is the scarce part, and that's what you spent years earning.

So prototype the easy part fast. Then spend your real time on the hard questions. Should this exist? For whom? Why now? Why us? Those questions were always the product job. Now they're most of it.

Move past one-off prompting

Prompting feels advanced. It's the ground floor. The gains start on the floors above.

Take work you repeat and wire it into one workflow that carries your context, your standards and a check on the output. A one-off prompt saves you ten minutes once. A workflow saves you ten minutes every time, and holds your standard when you're not watching.

Write your own definition of the role

Every company is deciding what an AI-native PM looks like. You can shape that definition, or inherit someone else's.

Decide what you automate, what you speed up, and where a human keeps the call. Write it down and show your team. A clear definition of where your judgement stays in charge is worth more than any list of tools. For a closer look at how the job itself changes when you rebuild it rather than just speed it up, see /vault/rebuild-the-product-job.

Measure what builds on itself

Race the tools and you fall behind every week. Build systems that keep paying back and you pull ahead.

Each week, ask one question: what did I build that makes next week faster? If the answer is nothing, you spent the week producing, not building on what you have. Output is gone once it ships. A rule, a template or a workflow keeps working.

From keeping up to pulling ahead

Do all eight and the treadmill stops. Your work starts building on itself, each week making the next one easier, and you move from keeping up to pulling ahead.

Learning faster was only ever survival. Building a system that learns with you is how you stay ahead of the product and the tools, however fast they change.

Which of the eight are you starting this week? If you want to see how you measure up in AI and find your highest-value next moves, the free scorecard is at martongaspar.com/scorecard.

Questions people ask

How can a product manager stay ahead as the job changes?: Build systems, not just skills. Turn your best calls into written criteria, create a learning loop that tests new ideas on real work, wire repeated tasks into workflows, and check your instincts against results. Each of these keeps paying back after the week you built it.
How do I scale my product judgement?: Take a decision you make well, write down the criteria you use, and add one good and one bad example. That turns a call only you could make into a rule someone else can follow, so your judgement works even when you're not in the room.
What is the difference between a reading list and a learning system?: A reading list collects things to learn. A learning system tracks what you need to learn, tests it on real work straight away, and turns each lesson into something reusable, like a template or a prompt. The reading list grows. The learning system changes how you work.
Why isn't prompting enough for product managers?: One-off prompts save time once. The bigger gains come from turning repeated work into a workflow that carries your context, your standards and a check on the output, so it saves time every time and keeps the quality consistent.
What questions matter most now that building is cheaper?: Should this exist, for whom, why now, and why us. When prototypes are fast and cheap to make, the scarce skill is deciding what deserves to be built. That has always been the core of the product job, and it is becoming more of it.