Interesting piece. I used to run into this with Excel. Sometimes it was faster to just do the math. Sometimes the cost of doing it repeatedly pushed me to build the formula right away. Over time you get a feel for that line. Feels like that decision sits underneath this. I think people with AI are acting more like explorers than operators, as your Jane story points out about output.
That’s a perfect parallel! And you highlight a very important point: at the beginning, it’s hard to tell when to stop. Then, after a while, you develop the right instincts and can decide easily which way to go.
Really interesting piece. How’d you land on the time allocations? I can imagine that depending on the intent of the role, they could be different for different role designs.
It’s experience based and qualitative, but mirrors widespread management frameworks where most of the time/effort must go on the most important thing (70%) and the rest is split 20/10 or 25/5 depending on what you are focusing on. I agree with your view that this will vary depending on exactly what you’re doing, so it’s more of a guiding principle than anything else!
As a guiding principle, it makes sense - I was interested to see if anyone was coming out with ‘rules’ about this yet (which I’m sure we’ll see!). Good principles are always a smarter idea.
Jean-Paul, Andrea — the 70/25/5 framework is the clearest articulation I’ve seen of a problem I observe constantly in the organisations I work with. The Jane story is almost painfully recognisable.
I want to add one layer upstream of the framework, because I think it explains why the drift happens in the first place.
Jane doesn’t end up in system configuration for forty minutes primarily because she’s bad at prioritising. She ends up there because she doesn’t have sufficient clarity about what the output actually needs to accomplish. The competitive analysis isn’t just an empty document — it’s an underspecified one. She knows the deliverable but not the decision it’s meant to inform, the audience it’s meant to move, or the standard by which it will be judged useful. So she fills the vacuum with setup.
Configuration feels like progress because it’s the only part of the task that has a clear completion condition.
This suggests the precondition for getting to 70% output time isn’t primarily a time management discipline — it’s a clarity discipline. The question before you open the tool is: do I know what this output is actually for, with enough precision that I’d recognise a good version if I produced one?
When that answer is genuinely yes, the tool layer shrinks naturally. You don’t spend five minutes choosing between platforms because you already know which one serves this specific purpose. You don’t spend twenty minutes on system configuration because the task is defined clearly enough that minimal scaffolding is needed. The 70% becomes almost automatic — not because you’ve become more disciplined, but because there’s nothing left to configure around.
When the answer is no — when the output is underspecified, when the purpose is fuzzy, when the ‘job to be done’ (to borrow Des Kennedy’s reference to Ulwick below) hasn’t been honestly named — then the outer layers expand to fill the space. Not from laziness. From the perfectly human instinct to do the thing that feels productive when the actually productive thing is unclear.
The framework tells you where your time should go. The prior question is whether you’ve done the thinking that makes the framework navigable.
Thanks for this thoughtful comment ! For sure lacking clarity on the output spec doesn’t help … but on my end I think that even with a clear goal there is this strong temptation to test a new tool or tweak a new parameter because may be output will be better … esp in open ended tasks like strat analysis or article writing. Instead of spending time on improving the output you may loose time in refining the system. Then lack of scope / goal makes things indeed even worse
Spot on - in professional service for example, scope is key. If you’re not sure what you’re doing and why, that 70% is not achievable. It’s especially important to coach junior colleagues to get that clarity or they’ll forever be stuck in a flurry of unsatisfactory doing.
This is a really enlightening take on AI in the workplace. As we rush to employ these tools, we can find ourselves continually tinkering, convinced we are progressing. The truth is, it's impossible to stay ahead of each new release or peer discovery, but easy to fall into the trap of thinking we can. When I need to reassess my priorities, I always come back to Tony Ulwick's assertion on Outcome-Driven Innovation (ODI) or, as he puts it, "What is the job to be done?"
Yes great frame as well ! The thing with AI is that the marketing is very vocal to convince you that yes this very new tool can solve all your problems and make worthwhile output in one click ;)
Interesting piece. I used to run into this with Excel. Sometimes it was faster to just do the math. Sometimes the cost of doing it repeatedly pushed me to build the formula right away. Over time you get a feel for that line. Feels like that decision sits underneath this. I think people with AI are acting more like explorers than operators, as your Jane story points out about output.
That’s a perfect parallel! And you highlight a very important point: at the beginning, it’s hard to tell when to stop. Then, after a while, you develop the right instincts and can decide easily which way to go.
Really interesting piece. How’d you land on the time allocations? I can imagine that depending on the intent of the role, they could be different for different role designs.
Yes of course m, as we wrote in the article that’s pretty indicative, the gist is that in the end the work matters not the setup :)
It’s experience based and qualitative, but mirrors widespread management frameworks where most of the time/effort must go on the most important thing (70%) and the rest is split 20/10 or 25/5 depending on what you are focusing on. I agree with your view that this will vary depending on exactly what you’re doing, so it’s more of a guiding principle than anything else!
As a guiding principle, it makes sense - I was interested to see if anyone was coming out with ‘rules’ about this yet (which I’m sure we’ll see!). Good principles are always a smarter idea.
Jean-Paul, Andrea — the 70/25/5 framework is the clearest articulation I’ve seen of a problem I observe constantly in the organisations I work with. The Jane story is almost painfully recognisable.
I want to add one layer upstream of the framework, because I think it explains why the drift happens in the first place.
Jane doesn’t end up in system configuration for forty minutes primarily because she’s bad at prioritising. She ends up there because she doesn’t have sufficient clarity about what the output actually needs to accomplish. The competitive analysis isn’t just an empty document — it’s an underspecified one. She knows the deliverable but not the decision it’s meant to inform, the audience it’s meant to move, or the standard by which it will be judged useful. So she fills the vacuum with setup.
Configuration feels like progress because it’s the only part of the task that has a clear completion condition.
This suggests the precondition for getting to 70% output time isn’t primarily a time management discipline — it’s a clarity discipline. The question before you open the tool is: do I know what this output is actually for, with enough precision that I’d recognise a good version if I produced one?
When that answer is genuinely yes, the tool layer shrinks naturally. You don’t spend five minutes choosing between platforms because you already know which one serves this specific purpose. You don’t spend twenty minutes on system configuration because the task is defined clearly enough that minimal scaffolding is needed. The 70% becomes almost automatic — not because you’ve become more disciplined, but because there’s nothing left to configure around.
When the answer is no — when the output is underspecified, when the purpose is fuzzy, when the ‘job to be done’ (to borrow Des Kennedy’s reference to Ulwick below) hasn’t been honestly named — then the outer layers expand to fill the space. Not from laziness. From the perfectly human instinct to do the thing that feels productive when the actually productive thing is unclear.
The framework tells you where your time should go. The prior question is whether you’ve done the thinking that makes the framework navigable.
Thanks for this thoughtful comment ! For sure lacking clarity on the output spec doesn’t help … but on my end I think that even with a clear goal there is this strong temptation to test a new tool or tweak a new parameter because may be output will be better … esp in open ended tasks like strat analysis or article writing. Instead of spending time on improving the output you may loose time in refining the system. Then lack of scope / goal makes things indeed even worse
Spot on - in professional service for example, scope is key. If you’re not sure what you’re doing and why, that 70% is not achievable. It’s especially important to coach junior colleagues to get that clarity or they’ll forever be stuck in a flurry of unsatisfactory doing.
This is a really enlightening take on AI in the workplace. As we rush to employ these tools, we can find ourselves continually tinkering, convinced we are progressing. The truth is, it's impossible to stay ahead of each new release or peer discovery, but easy to fall into the trap of thinking we can. When I need to reassess my priorities, I always come back to Tony Ulwick's assertion on Outcome-Driven Innovation (ODI) or, as he puts it, "What is the job to be done?"
Yes great frame as well ! The thing with AI is that the marketing is very vocal to convince you that yes this very new tool can solve all your problems and make worthwhile output in one click ;)
With Claude Design being the latest shiny thing - it’s good, but not *that* good!