The Art of the Beginning. Don’t Trip at the Starting Line.

Image. At the top, short learning cycles, test to failure with cheap, sub-system prototypes. Learn efficiently what doesn't At the bottom, traditional long system iterations. Learn what doesn't work late. Worst case through customer complaints.

Ah, the “Art of Beginning” in product development ​​sounds artistic, doesn’t it? As a seasoned veteran with over 20 years of Lean, Knowledge-based, and DevOps virtue, I’ve seen plenty of false starts. But let me be clear. It’s not about grand beginnings or piling on resources like an overloaded plate at a buffet. No, it’s the craft of igniting innovation without falling into pitfalls. Think of it like starting a fire. Too much pre-ignition, and you smother it. The right spark, and it roars.

Let’s start with Pre-development

First, what it’s not. Pre-development, the seductive idea of ​​“mitigate risks early” by building a handful of full-system prototypes. Picture this, you create a shiny “supersystem” beast, carefully test it to specifications, and—bam!—what you didn’t know you didn’t know hits you in the face. Time is up! It’s taking as long to solve the failure as the whole pre-development time allotted in the first place. Both the time and budget are blown, and you have only learned about one major error, but nothing about other edge cases. As Nassim Taleb points out in Antifragile, stressors equal knowledge. Without stressors, you’re kind-off just polishing a pile of poop (yuk). Or worse, you work linearly. Design first, wait for builds (yawn), perfect, but lack feedback. Tests reveal flaws! Too bad, you’ve wasted weeks or months. Not so funny example: I once saw a large team prototype a complete internal combustion engine that had great power … but at idling speed it vibrated so that it was literally falling to pieces. No sub-system stress tests? Rookie move, but this team had no Rookies.

Or apply Front-loading

Front-loading doesn’t work any better. The idea is to “swarm” the beginning with experts to mitigate risks from day one. But the reality? These gurus are commonly chained to the last project’s firefighting and contribute to the new one too late. Key decisions have already had to be made without them. If you furthermore apply front-loading in a “design first, then test” process (Michael Kennedy et al Ready, Set, Dominate), means that learnings are delayed. More developers don’t accelerate insights, tests with small failures to learn edge cases do. Without that, there is a risk that irreversible disasters emerge mid-race and trap everyone in a negative loopback. Taleb again, “Bad news doesn’t show easily” without early testing. Dave Snowden’s CYNEFIN framework hits the nail on the head, “unknown unknowns can only be understood in retrospect of tests.”

What is the true Art of the Beginning

So, what is the true Art of the Beginning? Design for rapid feedback from day one. Aim for 20+ short learning cycles in the first quarter, and test to failure with cheap, sub-system prototypes. Henrik Kniberg’s “Earliest Testable Product” from Making Sense of MVP is gold. Customers actually buy a function, the purpose or ability provided by products or services. My mantra is “what kills your subsystem, makes your supersystem stronger.” Tinkering trumps theory. Nassim Taleb gives entrepreneurs and hobbyists, not scientists, the credit for technological progress. It’s preferable to “test first, then design.” According to Uri Levine it’s far better to “love problems, not solutions.” Small teams thrive on autonomy (John Boyd’s philosophy), running tests with early detected reversible mistakes – Antifragile magic!

Ditch process compliance jails

Ready to take a leap of faith? Ditch process compliance jails. Organizations stuck in “check-the-box” mode fear non-conformance like cat’s fear baths—bureaucracy breeds caution, not curiosity. The challenge, leaders must empower tinkering, measuring knowledge and insights gained, not gates passed. Allen Ward’s Lean Product and Process Development urges testing beyond specifications to find true outer limits.

Create benefits by learning from day 1 what doesn’t work

In DevOps spirit, focus on value streams, survive first. Fall in love with problems. Build and test small, fail fast through short iterations, focus on daily progress and weekly updates. This limits downsides, creates benefits by learning what doesn’t work, and is best when it is also based on customer feedback. It’s quick warfare – outsmart risks, don’t waste them. Master this art, and your start won’t be a stepping stone in an unfavorable direction… it will create legends.

Group Discussion Page