Andrew Ng said something on stage this year that has been rattling around in my head ever since, because it quietly inverts how almost every organization sets goals. Ask a team to improve something by 2%, he observed, and people will work 2% harder. Ask them for 50%, and they can't get there by working harder - the only way through is to invent a new approach entirely.
The small ask permits the old method. The big ask forbids it. And that single asymmetry - that a huge goal is often easier to pursue well than a modest one - is the most useful idea I've picked up all year, precisely because it feels wrong.
The 2% Trap
Everything in a normal company nudges you toward the small number. It's defensible. It fits in a quarter. It survives the planning meeting. Ask for 2% and nobody argues, because 2% is achievable inside the process that already exists - you just squeeze the existing machine a little harder. It is, in every visible way, the safe goal.
Here's the trap. When you ask for 2%, you have implicitly promised not to change anything structural. You've told the team the current workflow is fine and just needs more effort poured into it. So they pour. And they get their 2%, and the machine that produced the 2% is exactly as rigid as it was before - a little more strained, a little closer to its ceiling, and no more capable of a step change than it was last year. You bought a small gain by ratifying the thing that limits you.
The 50% ask does the opposite. It's un-hittable by effort, which is exactly its virtue: it disqualifies the old method on day one. Nobody wastes a week trying to grind out 50% by hand, because everyone can see instantly that grinding won't do it. The size of the number does the hard work of forcing creativity - it drags the team, immediately, to the only question that matters: what would have to be completely different?
"The small ask permits the old method. The big ask forbids it. That's the entire difference."
The Ten-Minute Loan
Ng has a concrete example that makes this land. Picture a loan process with five steps, and one of them - the approval - takes an hour. The obvious AI move is to automate that hour. Point a model at the approval step, get it down to minutes, ship the efficiency. You've made one step of an unchanged five-step process faster. It's a real improvement. It's also small, and it leaves the shape of the thing exactly as it was.
The transformative move refuses to touch the step at all. Instead it asks: what if the entire product were "get approved in ten minutes"? That single reframing detonates the old workflow. Now marketing has to change, because ten-minute approval is a thing you'd actually advertise. The data infrastructure has to change, because a ten-minute answer needs data that's already in place. The routing changes. The diligence changes. You didn't speed up a step; you redesigned the workflow into a categorically different product - and every function around it was forced to move with you.
That's the tell. Automating a step produces an efficiency gain and stops there. Redesigning the workflow produces a new thing that pulls the whole organization forward, because the goal is too big to be reached by any single team optimizing its own corner. The ten-minute loan isn't a faster loan. It's a different business wearing the same word.
Why Big Is Easier Than Small
The reason this works now, in a way it didn't five years ago, is that the cost of building has collapsed. When execution was expensive, the 50% goal was genuinely reckless - you might spend a year and a fortune chasing a redesign that didn't pan out, so the incremental path really was the prudent one. That calculus has flipped. When an AI-assisted team can prototype a reimagined workflow in days instead of quarters, the big swing stops being the expensive bet and becomes the cheap experiment.
So the old wisdom - small, safe, continuous improvement - was correct for a world where trying big things was costly. In a world where trying is nearly free, that same wisdom becomes a liability. The incremental path now carries a hidden risk that nobody prices: while you're carefully earning your 2%, a competitor with the same cheap tools is asking for 50%, being forced to invent, and occasionally landing a step change that makes your entire optimized process obsolete. The "safe" path is safe against small failures and defenseless against the big one.
There's a wonderful data point Ng mentioned almost in passing. One bank, once it understood what was now possible, didn't send his team a careful shortlist. It sent a spreadsheet of 300 ideas and asked for help triaging them down to a handful of fundable bets. That's what an organization looks like the moment it internalizes that building is cheap - it stops rationing ambition and starts rationing attention instead. The scarce resource moved from "can we build it" to "which of the three hundred things we could obviously build is actually worth it." Which, not coincidentally, is a judgment problem - the one thing that stays hard.
"When building was expensive, incremental was prudent. When building is free, incremental is the risky bet you didn't know you were making."
Growth Has No Ceiling
There's a second Ng line that pairs with the first and sharpens it: we can only save so much money, but growth has almost no practical ceiling.
Most AI initiatives inside big companies are sold as cost savings - automate the task, trim the headcount hour, book the efficiency. And savings are real, but they have a floor. You cannot save more than 100% of a cost; usually you top out far short of that, and then the well is dry. Every cost-savings project is a countdown to its own ceiling. Growth has no such wall. There's no natural limit to how many more loans you write, accounts you reach, customers you serve. The upside is unbounded in a way the downside-avoidance never is.
This reframes the 50% ask one more time. The reason to chase transformation over efficiency isn't just that the big goal forces better thinking. It's that the big goal is almost always pointed at growth, and the small goal is almost always pointed at savings. Automating the approval step saves an hour. Building the ten-minute loan grows the book. Same underlying technology, aimed at a bounded outcome or an unbounded one - and the choice of which way to aim is made entirely by the size of the goal you were brave enough to write down.
How To Ask For Fifty
I've started running my own systems through a single question, and it's changed what I build. For anything I'm about to make faster, I stop and ask: am I automating a step, or redesigning the flow? My trading loops, my vault pipeline, my outreach - the reflex is always to speed up the slow part. The Ng move is to ignore the slow part and ask what the whole thing would look like if the outcome were 50% better, or ten times faster, or a category no one offers yet.
Most of the time the honest answer is "I'm just automating a step," and that's fine - not everything deserves a redesign. But every so often the question cracks something open, and I realize the thing I was about to optimize shouldn't exist in its current form at all. That's the ten-minute-loan moment, and you only ever reach it by refusing the small ask long enough to sit in the discomfort of the big one.
So the practice is almost embarrassingly simple. When you set a goal, notice the number you instinctively reach for, and suspect it. If it's the safe, defensible, fits-in-a-quarter number, you've probably just ratified the machine that's limiting you. Cross it out. Ask for fifty. Not because you'll always hit it - you won't - but because only the big number forces you to invent, and only invention compounds. The 2% will always be there as a consolation prize. The step change is only available to the people willing to ask for something the old method can't deliver.
