
Startups know what they want to do for their customers. What they don’t know is how to turn a pitch deck into an actual usable product.
I’d like to tell you about the solution I’ve been successfully applying to those I worked with: “Divide & Conquer”.
“How long will it take to build?” the CEO asks after an hour-long pitch-deck-abstraction-level finger-snapping rant.
How could you know? How could anyone know for a fact? Should you take your most pessimistic projection and multiply it by three?
Maybe…
Almost anything of a substance will lead to the valley of despair at one point or another. A business-building enterprise inevitably turns into a series of seemingly unachievable tasks of magnitude you’ve never dealt with before—a project manager's nightmare. The initial roadmap resembles dream logging: foggy, nonsensical, chaotic, and hard to put into words. It appears to get you further from the goal rather than closer. It scares most of us away from taking action.
Yet, one pragmatic approach always got me from a fatalist “Forget about it!” to a hesitant “So, where do I start?”.
Embrace Uncertainty
When there’s no handbook for something, you risk sticking to assumptions until the bitter end, where you discover that you were moving in the wrong direction the entire time. Nine times out of ten, it’s too late to pivot.
Many founders have been recommended the entrepreneur’s bible: “The Lean Startup”, as the ultimate hedge. Its idea is simple: build a Minimum Viable Product (MVP), test, fail, rinse, and repeat until you’ve figured it out. MVPs can be anything from a friendly chat with a potential customer to a half-way-functioning web facade imitating the real thing but not doing anything under the hood other than collecting the number of unsuccessful attempts. Smoke and mirrors. The purpose is to test a hypothesis and save resources if the idea is a dead-end.
Note: It’s often recommended to make this process as user-unfriendly as possible since enraged users still trying to get your product to work despite frustration are strong indicators of a product-market fit. Most flight ticket booking websites and digital banks fall into that category.

But that’s a theory. Most folks who recommend this book don’t follow its core advice either because it’s easier said than done, embarrassing to showcase, or because they’re not the ones building.
Here’s a complaint from a fellow Chief Product Officer:
"I'm struggling to test hypotheses with users without building the feature, shipping it, and seeing the engagement. We could be moving faster if we didn't need to go through a full development cycle and another one to collect feedback."So, what’s the solution if you can’t always live by the Ten Commandments of Eric Ries?
Divide & Conquer
There’s only one way to eat an elephant — one bite at a time.In science and other disciplines, unsolvable problems are often divided into smaller, solvable ones. Resulting fractional solutions are then combined to crack the whole case. This methodology is called “divide and conquer” and is inspired by the “divide and rule” strategy practised in economics, politics, and sociology. Split one power into smaller, more manageable pieces to control them separately.
This top-down approach applies particularly when the goal has been coarsely crystallised, but the roadmap remains unclear. For instance, I want to build a fin-tech company helping X achieve Y. I want to write a book about Z. I want to run a marathon next year. You need to know approximately where you want to be, even if the destination is far enough to entail an overarching effort to get there. The more laborious the endeavour, the less you can chew through at once, and the more the “Divide & conquer” method makes sense.
With that in mind, my response to this Chief Product Officer’s complaint went like this:
“If you can't avoid building before testing a hypothesis, try structuring it so that you can reuse some or all of its parts if the whole proves to be a bad idea. Our numerous tests resulted in a collection of black boxes, such as design tokens, lambda functions, or scripts we can repurpose. The more experiments we conduct, the quicker we can create new ones with existing Lego blocks.”Chicken vs Cucumber
There are numerous ways one can divide a whole into parts, but I segregate them into two groups:
- What you’re dichotomising is dictating where to fraction it.
- You decide on the portion size.

Imagine butchering a chicken. You’ll most likely cut it at the joints. The chicken “dictated” the most optimal way to be cut post-mortem. It’d be inconvenient to slice through its meat and bones like you'd tranche a cucumber.
Note: In Asia, chicken and duck are commonly sliced all the way through, shifting the responsibility of spitting out fractured carcasses to the chewer and turning it into one of the most agonising user experiences.
Speaking of cucumbers, it’s a perfect example of the second division class, where you decide upon the shape and size of the chunk you want this vegetable to be chopped up into. So, unless you’re trying to carve a sculpture from a cucumber, you’ll probably go for uniform round slices or, equally consistent, square dice for your salad.
Focus on Staples
Startups are like restaurants: extremely risky, and the menus are prone to change. Like you, they operate in conditions of utmost uncertainty, where, per the game theory, decisions have to be based not only on you and your users but also on what your competitors could be brewing. That said, even if you didn't know what dishes your restaurant would offer tomorrow, you'd still need knives, an oven, and spices. Focus on those.
I agree with Donella H. Meadow, who argues that the best systems are resilient—those remaining operational despite failures and course corrections. Their sub-systems are immune to change.
One of the ways to achieve this characteristic for your products is to follow the Unix Philosophy, which holds that the whole is a collection of interconnected parts. Each part is responsible for only one thing but executes it exceptionally well. Reorganising them unlocks different potentials and allows you to pivot painlessly.
Build isolated, self-sufficient, resilient and reusable blocks. Rearrange and reconnect them until you've reached your overarching business goal. In other words, Divide & Conquer.
In writing about this topic, I realised that one article would not suffice. In its sequels, we shall look at real-life scenarios of the two ways to split a whole into appropriate portions. Part 2 will be dedicated to self-sufficient Lego blocks of variable size. Part 3 will be about homogenous chunks of equivalent size.
How did you solve that puzzle? I'm genuinely curious.
Special Thanks
The following brilliant people helped slice and dice this article, preventing amateurish butchery: Lilian T., Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, and Jason Collins.