Getting to "yes" in a world of "no"…

Posts tagged ‘Lean Startups’

Hardware, Software, and Lean Startups…

Speaking as a long-term software zealot (25 years making computer games) turned hardware zealot (5 years in the security camera industry), I’ve long suspected that the two industries may currently be inching towards a whole new shared development model, possibly even some kind of convergence – [a word so uncool that it’s actually become cool again].

With this idea in mind, I eagerly went along to TechHub near Old Street in London a few days ago for a surprisingly candid & very entertaining talk by Eric Ries about “Lean Startups”, a software development movement he has been building (if you strip out all the diagrams and models) atop two sensible-sounding observations and one inference:

  1. Companies learn a lot from showing stuff to customers & listening to what they say
  2. The more a company learns, the better it becomes at doing whatever it is that it does
  3. [Ergo…] companies should structure their development so as to show stuff to customers as early and as often as possible.

While my software engineer side likes the way this manages to make virtues of product / market fit and tight development iterations, my hardware engineer alter-ego finds it all a bit strange, frankly: for while Ries’s Lean Startup claims its philosophical roots in the post-WW2 Lean Manufacturing movement, modern manufacturing itself has actually moved on quite some way since then.

So… the right question to be asking now is surely how different contemporary hardware development is from Ries’s conception of contemporary software development.

Clearly, what both sides wants to avoid is obvious: the “waterfall” model (the 20th century’s dominant product development paradigm) wherein each functional specialist in a company in turn hands off a piece of work to the next functional specialist along in a long, long chain. I’m sure you’ll recognize something along the snakey lines of…

The claim here is that by assembling a sequential pipeline of engineering teams each specialized in its own narrow field, you can get from market need to paying customers quickly and reliably. This is essentially Henry Ford’s factory line adapted for product design (though admittedly running much, much more slowly): and for decades engineers have been taught that, just like philosopher Montell Jordan said, this is how we do it.

However, you don’t have to dig very deep to see that this kind of functional optimization relies on a couple of key assumptions being true:

a) You’ve totally nailed down who your customers are and what they want;
b) Your target market won’t change (much) while your teams of functional specialists goes away for 18 months building your killer product / service.

The problem: around twenty years ago it started to become abundantly clear that with the complexities of modern customers’ behaviours and the intricacies of modern product design, neither assumption really held true any more. In Eric Ries’s terminology, both the problem space (in particular the speed at which customer needs changed) and the solution space (the best product or service to meet those fast-moving customer needs) were busy crossing some invisible line from certainty to uncertainty. So, product companies needed a new conceptual model to use when building things: but what?

Well, they looked around and stumbled upon an answer from 1969: mechatronics, a ‘so-ugly-it’s-beautiful’ neologism formed from mecha(nics) + (elec)tronics. Its core idea is to execute all the product design strands simultaneously by building a team with multi-functional expertise and then getting team members to collaborate closely with each other, thus dissolving the rigidly-patrolled Gantt chart dependencies into a rich active blur. Its second main principle is to work hard to keep your base hardware design as simple as possible so that you can adapt it whenever customers’ needs vary (which in hardware is normally ‘always’).

Yet even the triple tag team of mechatronic parallelism, collaboration, and KISS wasn’t enough to escape The Curse Of The Waterfall: and so the last decade of manufacturing has also seen the rise of rapid prototyping, thanks to such technologies as 3d printing and soft tooling. The new mantra there is “Prototype Early, Prototype Often”: and this has now merged with something like Steve Blank’s Customer Development approach so that prototypes are now regularly (co-)developed with (/ for) early customers to bring feedback (and learning) right into the design / development loop.

Hence, the state-of-the-art in hardware manufacturing is essentially a fast-looping combination of mechatronics, rapid prototyping, and customer learning. But this isn’t just some academic or theoretical model, real hardware companies do it all the time.

As an example: to bring its own novel PTZ (“pan/tilt/zoom”) security camera to life as cheaply and effectively as possible, my own hardware startup Nanodome followed these three guiding principles as far as practical, with the mechanical development strand going through three major iterations, roughly 3-4 months apart:-

  1. Trying to keep the hardware brutally simple, our first iteration ended up with worm-gears and a pair of optical blind spots. However, when we demoed our workshop prototype to a large UK distributor, they told us that (a) even tiny optical blind spots would be considered unacceptable, and (b) worm gears had been tried in domes many years before but installers had proved prone to wrecking them. And yes, our customer was Just Plain Right.
  2. Unsurprisingly, our next iteration had no blind spots and no worm gears: we fabricated it as a lo-res model 3d-printed in ABS. However, a second potential customer (an integrator this time) pointed out a number of new issues, most of them to do with installation and maintenance. Once again, they were absolutely right.
  3. Our third iteration was a hand-finished medium-res 3d-printed model, and worked fine until a few weeks ago (when a business angel accidentally dropped and smashed up the inner assembly, oops!). Since this iteration, customers have told us what they’d like us to change (mainly to do with tuning it for particular markets), but no big show-stoppers: so it basically seems ‘good to go’.

In addition to all the above, we went through similar learning-based ‘pivots’ around the electronics, the feature list, the component sourcing, the component choices, the firmware, the software, etc. (Perhaps the most taxing issue of all was what I call “the politics of electronics”, but that’s a topic for another day entirely.)

Here, the biggest difference from the waterfall model is that the whole point of each prototype cycle was to get customer validation (or, more often, customer invalidation). Whereas the MBA worldview treats business issues as an abstract resource optimization problem, this kind of approach treats business as a perpetual learning optimization cycle built around (and for) customers.

Could we have pivoted any faster? Probably not: we had incomplete market data, we began with only a limited network of industry contacts, the industry was changing month by month (as was the technology), we faced significant technical mountains to climb, we had to be continually inventive even to move forward slowly, etc. And (if you hadn’t already guessed) there were only two of us, each wearing 20+ hats. Sure, we made plenty of mistakes, but we made them fast enough that it didn’t kill the company. That’s probably best case for a startup, wouldn’t you say?

Hence it seems to me that whatever differences between Eric’s Lean Startup methodology and the approach taken by up-to-the-minute hardware startups such as mine are ultimately no more than fairly minor terminological ones. For a long time, I’ve been telling people that “Hardware is the new software”: but perhaps hardware and software are now close enough together in an uncertain, fast-paced world that all that really matters is getting to product-market fit at high speed – perhaps in the great big USB dev world we operate in, we’re all ‘(dev)-ware’, whether we like it or not.

In fact, could it be that we’re now coming to the end of the time when there’s any conceptual split between mass market hardware and mass market software? I suspect so: and if I was hiring a software engineer now (which I’m not! No resumés, please!), I’d probably look for mechatronic problem-solving first (perhaps with a bit of XP / SCRUM experience) and C++ smarts second.

From my own perspective (sat astride this rapidly narrowing hardware-software divide), I suspect that the “Lean” in “Lean Startups” might well turn out to be a misnomer: combining (mechatronics), (rapid prototyping), and (learning about customers through purposeful experiments) probably isn’t that much to do with Lean Manufacturing (which focuses on continuous improvement of factory practice). Really, it’s more about learning than ‘lean’-ing per se.

But all the same, for me the #1 lesson for both hardware and software startups seems to be that you simply can’t divorce the business side of a startup from its execution side. Full-on VC stealth mode sucks, as does any engineer who doesn’t want to talk in depth with customers. A loop without a customer bears fake fruit, when what you really want are fruity loops (and no, I didn’t get paid to say that).