Context engineering: why the AI-written PRD beats the human under time pressure

Markus Andrezak has been in product management for around 30 years, among others at Fireball and eBay, today with Überprodukt. He was sceptical about generative AI for a long time and reveals in this episode what changed his assessment.

The trigger was not a new model. It was a way of working.

What separates context engineering from prompting

The difference sounds like a nuance and is none. Prompting means formulating a task as well as possible. Context engineering means breaking the task down far enough that every sub-step gets exactly the material it needs.

The result, Andrezak says, is no longer merely usable output but absurdly good output. The reason is unspectacular: a model rarely fails on capability and frequently on the fact that half the prerequisites are missing.

In practice that means the work shifts forward. Instead of correcting an answer, you make sure the right documents are present at the right step. That is more laborious than it sounds, and more effective than any art of phrasing.

The uncomfortable finding

The sentence the episode hangs on runs roughly like this: an AI-generated product requirements document from 20 customer interviews frequently beats in practice what a product manager delivers under genuine organisational time pressure.

The decisive half-sentence is “under time pressure”. The statement is not aimed at people's abilities but at the conditions under which they work. Anyone asked to write a PRD between two steering meetings cannot evaluate 20 interviews thoroughly. A system that does exactly that has the advantage not through intelligence but through time.

Explicitly, it does not follow from this to take the human out of the process. It follows to have the best rough drafts prepared and then to curate.

Synthetic personas and simulated workshops

The part that provokes the most objection and is best evidenced: Andrezak has strategy workshops played through by AI agents before he meets real customers. For 30 to 40 dollars in interface fees, discussions emerge that he compares in quality to real workshops, plus a head start in insight he would otherwise have to work up over weeks.

The obvious objection is that synthetic personas are not real people. The objection is correct and does not hit the benchmark. The alternative is rarely careful user research. The alternative is frequently a persona a 25-year-old product team put on the wall, while the actual target group is over 50.

Measured against that, the synthetic variant is the more realistic one. Measured against good research it is not. Every organisation knows for itself which comparison applies.

Leadership has to create clarity

The second major strand concerns organisations. Kent Beck's observation that 90 per cent of previous skills are devalued and 10 per cent massively upgraded describes a shift that ends in chaos without leadership.

As a counter-example serves Amazon under Andy Jassy: unmistakable communication of goals and limits. Not because everything is done right there, but because the message is unambiguous. Employees who know what is expected and what is not permitted try out more than those who do not.

The historical parallel runs through the whole episode: with continuous deployment, more than ten years ago, the line was likewise that it could not be done, at best for toys. Then the bottleneck in delivery disappeared. Exactly that is happening now with programming.

What follows for the way of working

Two concrete pieces of advice from the episode are immediately applicable.

The first concerns dealing with agents: do not reach into the markdown file and correct details yourself, but talk to the agent and name the desired outcome. Whoever repairs the output repairs a single case. Whoever formulates the intent changes all the following ones.

The second concerns the assessment. It moves to the end of the value chain. Building gets cheap, curating becomes the actual core competence. That shifts where experience pays off: less on producing, more on selecting and discarding.

How that feels in daily work is illustrated by the example of Boris Cherny with ten open terminals, in a way of working the episode half-admiringly calls ADHD development style.

Conclusion

The episode answers the question of whether AI replaces product management with a clear no and an uncomfortable qualification: it replaces the part of product management that is done badly under time pressure anyway.

Two test questions follow for your own work. How much of your preparatory work is diligence nobody does thoroughly because there is no time? That is the part where it pays off.

And how do you recognise a good result? If you have no answer to that, no model will help, because then curating does not work either.

Whether roles will merge into interchangeable generalists Andrezak sees soberly, incidentally. Generalists have historically always been rare; neither management by objectives nor the unified process changed that. Roles blur at the edges and remain in place at their core.