When it comes to developing a new product, the most critical task is the one that is hopefully started at the very beginning. As it informs and validates all the other work. That task is, of course, make sure you’re creating a market offering that some market actually wants. And make sure that market is big enough to support your business plans.
It seems so obvious. And of course, nobody in their right mind would ever spend weeks, months, or years of their life to create a product nobody wants – but still it happens.
I worked for a company many years ago, where we developed (if I do say so myself) a pretty amazing suite of products. Something really ahead of its time. Something I saw aspects of showing up in other offerings years later. But the market we were expecting to lap up our product… it just wasn’t keen to pay for what we were offering, and the products we worked so hard to create worked great, but they weren’t selling nearly enough. You know how this ends.
These days we have a whole class of technical products built entirely in server hosted software. Where the product itself can change sometimes completely in a single update. There’s a large and thriving movement growing up around these kinds of tech businesses and their manifesto is pretty much a book called Lean Startup by Eric Ries. The whole proposition here is that with a process like this, followed intelligently, it becomes really hard to make something that isn’t needed or valuable to customers.
In this movement, you have your Minimum Viable Product. You have Customer Development, customer interviews, you have live metrics from actual product usage causing modification of the products over time, you have Product Managers (which are sort of like project managers whose project changes constantly, because the needs of the product features are always adjusted. So rather than be tasked with delivering a known and defined set of tasks on time, their job is to be responsible for the product in whichever form it takes, meeting business targets) You have a focus on the idea of “Lean” – which funnily enough comes from car manufacturing – an operations business area – where the focus is on workflow rather than throughput, and tends to play out in this movement as an ideal that you do as little work as possible to an idea until you can prove it’s needed and viable.
But hardware development has real inertia.
Traditionally, a physical product needs fair bit of design work in multiple areas before you can hold it in your hand. Traditionally an embedded code base needs a lot of lines of code written before you can attempt even your first feature that a user or customer might recognise.
Manufacturing requires a (possibly very long and complex) supply chain where the failure of any step will result in the failure or stalling of the whole manufacturing process.
And a product already in 10,000 customers hands can’t just magically grow a new sensor it never had before, to support a different user experience someone just dreamed up. So right out of the gate you can’t ever ship a true Minimum Viable Product, without it also being Maximum Possibly Conceivable Product. At least in hardware cost and design complexity and design time and battery usage and weight and supply chain sensitivity, and…..
The key thing hardware products can take from Lean Startup, is the focus on filling a need, and doing so efficiently, and at a price the people with the need will happily pay.
You do this by prototyping whatever you can, as fast as you can (ie, you prototype the MVP) you get this solution into relevant people’s hands, and see what they love about it, and what they don’t love, and you learn what needs to change or be added.
And speaking of learning what needs to change: You need to understand what exactly it is that you are doing for a customer. Often the thing a person directly asks for isn’t what they actually need. What they ask for is usually their personal understanding of what would make some problem they are seeing better. (That classic quote mis-attributed to Henry Ford: If I’d asked what people had wanted, they’d have said a faster horse.) But rather than ignore customer input as unusable the trick is to realise that if they want something enough to ask for it, then even if what they ask for seems irrelevant or nonsensical, there’s always going to be a real reason under there. And you have to find the real reason for whatever they are requesting. Only when that is done can you can come up with a solution that meets their real problem as best as possible, or ignore it in favour of something more important to your product…. at least safe in the knowledge of exactly what it is you are leaving undone. Your most powerful tool here is the word “why?” (yes this article is all about process defects, but you can apply the core of it to understanding design defects)
And while you obviously can’t iterate infinitely with hardware (though reliability and cost/efficiency based changes to an existing product design during manufacturing are very valid, and very common, and highly recommended as long as you can maintain build revision control. And so is anything that can safely and easily be done via user firmware update) you also have a need to build and maintain real relationships with your users and customers, and make sure that all the time you spend in the market with your product is not wasted. make sure that time and experience is able to inform you of what to do with the next physical version of the product that you will eventually need to make. Or a competitor will.
Later, I started working with a company that had an established market. People needed what they sold, and most importantly people could afford what they sold. The existing products weren’t that interesting, or special, and had their fair share of issues. But they met a need at a price point, and they sold and sold and sold. But were losing a bit of ground to a new competitor who hit a similar price point with a similar product (copycat much?) I was brought in to develop the next version of their main product to compete.
We were lucky to be the kind of business that directly dealt with many of their customers, and so had open conversations with users about the things they loved, and the things that were killing them with the old product. I tried out different things on the old product platform, experiments to see how features could be adjusted to be more like how people expected to use them.
I looked at the failures returned units had, and focused on making sure the new design was conceived from the beginning to eliminate the most common reasons units were being returned for warranty repair, as much as to add new components to support new and expanded features.
The end result was a new released product that did exactly what was needed and stemmed the flow of sales to the competitor, and it made our customers more productive. So we actually generated new sales on top of clawing back lost sales. At the same time, it reduced the amount of warranty returns that had been costing the company a lot of internal effort, saving a lot of time wasting repetitive repair work