top of page

#4 – WHY LEAN ISN'T ENOUGH WITHOUT SYSTEMS THINKING

  • Simone Pinto
  • Sep 25
  • 4 min read
the missing piece of Lean
the missing piece of Lean

This post is part of my series From Vision to Value, where I explore what Peter Checkland’s Soft Systems Methodology taught me — and how it compares to other dominant product approaches.

Each has strengths. Each has blindspots.

This series shows why systems-led discovery is the missing superpower that makes any approach more effective.


Today’s focus: Lean Startup (Eric Ries)

 

Lean has become the dominant language of product discovery.

Get out of the building. Talk to customers. Build an MVP. Pivot fast.

Eric Ries wrote The Lean Startup (2011), which introduced concepts like Build-Measure-Learn loops and the Minimum Viable Product. His book popularised Lean Startup methodology globally.

But Lean’s strength — its speed — is also its blindspot.

Because fast learning from the wrong thing isn’t learning. It’s waste.

 


The Power of Lean

I’m an advocate for Lean — it has saved countless founders from wasted years and millions.

As Ries framed it:

Don’t assume. Validate. Don’t build big. Build small. Don’t fear failure. Use it to learn.

But here’s the risk: Lean tends to focus narrowly on the product-customer relationship.

It validates features and proves usability, but not always survivability.


I’ve seen founders spend years without a single paying client, pivoting endlessly to accommodate every potential lead. Each pitch brings a new list of features.

Months later, they’re left with a catalogue of functionality but a fragmented user journey and no clear product direction.

And that’s where systems thinking brings a crucial correction.



Systems Thinking: The Missing Context

Lean asks:

“Does the customer want this?”

Systems thinking asks:

“What real-world system is this product entering — and what frictions, incentives, or blockers will shape adoption?”


Lean builds fast and learns fast.

But systems thinking assumes ambiguity is normal.

It considers multiple worldviews and surfaces conflicts.

It enables purposeful systems to be designed with clarity.

This not only de-risks building the wrong thing but also uncovers root causes and perspectives often missed.

It forces us to consider edge cases, not just happy paths.



A Case Example

I was working at Adserve in the era of 'MadMen' we developed a desktop timesheet application for a Media Agency that had just won a large new Client Account.

The Agency needed to onboard 250 new account managers and the stakeholders insisted that the very first thing those account managers did each morning was complete their timesheets from the previous day.


The requirement sounded simple: if yesterday’s timesheet wasn’t filled in, the application would lock the screen so the account manager couldn’t do anything on their PC until it was done.

I tried to explain why this was a terrible idea. Every Monday, no one would be able to work until they’d filled in two days of timesheets. The client insisted it wouldn’t matter “it will only take a second.”


So we built it.

But I was so uncomfortable with the user experience that I asked the devs to add a hidden fail-safe: a keystroke sequence that could bypass the lock.


About a month after launch, one of the senior managers came back from a two-week holiday — only to be greeted with an escalation from an unhappy client, on the phone demanding an update on an issue he had no visibility of.

He switched on his machine, to review his emails by he was blocked by the timesheet application demanding 15 days of timesheets.


That was the first and last time the fail-safe was used.

On that very day we amended the application to make timesheets non-mandatory (another hidden feature I’d built in anticipation of exactly this scenario).

That fail-safe wasn’t just a feature ... it was systems-led discovery in action, anticipating the real-world context users live in.



Why This Matters for Today’s Ideators

  • Entrepreneurs: You want to move fast and prove your idea works — but speed without clarity burns time and cash. Systems-led discovery helps you focus your energy where it counts.

  • Founders: You need confidence that your vision points in the right direction. Lean shows you if something works; systems-led discovery shows you if it’s the right thing to build.

  • Product teams: You’re under pressure to deliver features that work today. But what you really need is alignment — making sure those features serve customers and business goals.

  • Innovation leaders: You want momentum that sticks. Quick experiments get attention, but without systems thinking, they stall. Systems-led discovery ensures experiments turn into lasting change.



Final Word

Lean and systems aren’t rivals. They’re complements.


I believe in moving quickly to test whether an idea resonates with real users.

But if those early tests create pain points, they can kill a concept before it has a chance to grow.

Lean reminds us to move.

Systems remind us to see.

And when you bring them together, you don’t just move fast — you move fast in the right direction.

That’s why in the 101 Framework™, we bring Lean and systems together — giving innovators clarity, direction, and momentum from idea to impact.



If you’re using Lean methods but want to strengthen them with systems clarity and direction, book a Systems Discovery Call. Let’s make sure your next experiment tests the right thing — and builds momentum, not waste.


✒ Sign up to follow this series 'From Vision to Value: A Systems-Led Discovery Series' and see how we break down the traps, myths, and blindspots — from Zero-to-One to Lean to AI — and show how systems thinking ties it all together.

 

bottom of page