A while back I worked with a large manufacturer that had an ambitious goal: modernize an aging, monolithic system that managed a massive part of their business operations. The opportunity was enormous. If they could pull it off, the company projected savings of more than $100 million a year.
The plan was to go big. A three-year roadmap, teams of engineers, “sophisticated” project management, and a highly detailed plan that would have made Gantt himself proud.
I didn’t think they were wrong about the opportunity. But I thought they were wrong about the approach. They assumed that because the problem was large, the solution had to be large too. And if they were to get a large solution done, they needed to tackle it in big steps.
When we suggested starting small, the immediate concern was that we’d delay the return. “If we take small steps, it’ll take longer to see results,” they said. But that’s not what actually happens. When you start small, you learn faster. And learning is what accelerates value.
They wanted to take big steps to finish faster.
We wanted to take small steps to learn faster.
Know the Problem You Are Solving
When I first arrived, the team’s definition of success was “deliver the plan.” Everyone was laser-focused on the schedule, the deliverables, the milestones. The assumption was that value would follow once everything was complete.
But that meant three years of development before they could learn whether their solution even worked. Three years before they’d know if their assumptions were correct.
The problem wasn’t time to ROI. The real problem was uncertainty. They didn’t yet know if the new architecture would hold up. They didn’t know which features would resonate and which would miss the mark. They didn’t know what hidden complexity was waiting for them.
So we reframed the problem: how can we learn quickly and deliver real value while we’re learning?
Create Simple Things in Small Steps
We picked one product, the simplest one. It wasn’t the most important, and it didn’t represent the largest potential savings. But it was the easiest way to validate the architecture, test deployment practices, and work through the integration challenges without betting the farm.
In less than three months, that first product was in production. It wasn’t a prototype or a proof of concept. It was real, working software. It delivered about $2 million a year in savings, which was enough to pay for the entire team.
Three months in, the initiative had already paid for itself.
And buyers were engaged. They appreciated the new system. They appreciated the turn-around on orders, and they loved that when they gave us feedback about the software, we incorporated it right away. Did they want more? Of course. Did they ask about other products? Of course. But they could see progress. We weren’t telling them it would get better in three years - we were making it better NOW.
A month later, the second product went live, saving another $2.5 million a year. Each time, the team got faster, not because they were cutting corners, but because they were learning. We learned how customers actually interacted with the software - and we were surprised more than once. We learned about the complexity of the products one small step at a time - making each new challenge something we could focus on exclusively, incorporating the solution into an evolving system. We learned which integrations were brittle, which external services were slow, and which processes were slowing us down. We learned where our assumptions were wrong and we fixed them.
By focusing on small steps, we actually moved faster. The original plan assumed all the learning would happen up front, in design documents and architecture reviews. But learning doesn’t happen in theory. It happens through delivery.
Validate Before, During, and After
As we moved forward, we made validation a constant habit. Each new product started with a clear hypothesis: what impact did we expect, and how would we know? We validated our assumptions early (before writing code), while building (through instrumentation and observation), and after launch (through measurable outcomes).
Every product taught us something new. Each one refined the infrastructure, informed the design of the next, and reduced risk for everything still to come.
Two years into the initiative, the company had already realized over $60 million in savings, long before the original plan would have produced its first dollar of benefit.
By the time the full system was complete, it finished six months ahead of schedule, with infrastructure costs around 60% of what had been budgeted, and with less than half the projected team size. On the day the last product went live, the company had already banked over $100 million in savings.
Then COVID hit.
If they had followed the original plan, three years of work before any value, they would have spent millions without realizing a dime of return. The timing couldn’t have been worse. But because they had been learning and delivering value all along the way, they were in a strong position when everything changed.
The Real Lesson
Starting small isn’t about thinking small. It’s about creating the conditions for learning and value to move together.
When you know the problem you’re solving, you can start with focus.
When you create simple things in small steps, you can move quickly and safely.
When you validate before, during, and after, you can see what’s working and what’s not and change course before it’s too late.
That’s how you learn faster, deliver sooner, and sometimes save a hundred million dollars along the way.
Further Reading
Related Behaviors