A Message to CEOs: Not Developing the Technology Products You Want?
You or your organization is tasked with building an innovative hardware product. Maybe it’s a standalone hardware product, or maybe it’s to support a software-based or online experience.
It doesn’t matter—the point is that you need an innovative user experience unlocked by both hardware and software.
You’ve either tried and failed to develop great hardware, or you have a bad memory of it—team burn out, product late to market, resources blown on products that weren’t successful, innovation diluted.
Furthermore, these results were not in your control. You weren’t sure exactly what was going on with hardware and why it was taking so long, or why you wound up with the product you did.
If that experience was with a start-up, you know the repercussions of not getting a product right, developed late, or spending all your money on the wrong product.
Within a large organization, you know how painful it can be and how much political capital is burned when the organization rallies itself around a product that isn’t released on time, isn’t what you wanted, or just plain doesn’t wow your customers.
Why is hardware development so painful?
I’ll tell you why: most hardware development is done with a company’s own team, or at least directed by that team.
Those hardware development techniques are a product of being developed in corporate silos, and since they’re driven mostly by engineers, it’s done in a way that sounds rational to them (turns out it isn’t the best way).
Companies developing hardware are not motivated or positioned to advance the art of developing innovative hardware products. Until someone is, the cycle will continue to repeat.
Software development was in this same position a decade ago. A group of software development consultants and others, dubbing themselves the Agile Alliance, came together to compare notes on their frustrations with the predominant way of developing software at the time. What emerged was the Agile Manifesto—a set of basic values to advance the art of software development.
The problem with hardware is that this hasn’t happened yet. This is why hardware development effort after hardware development effort seems to go the same way.
Are you fed up with that? We are.
In fact we’re never doing traditional product development again for anything innovative. Not because we’re philosophically opposed—it’s simply so unreliable it effectively doesn’t work.
Product development for innovative technology products is broken.
Sound a little black and white? When’s the last time you shipped a product on time? With a team that wasn’t burned out? That delivered the innovative experience you wanted? And ultimately made your team and organization unequivocally successful?
Obviously there are exceptions, but they’re exceptions.
What can you do about it?
If this was intended as a sales pitch for Mindtribe, I’d say work with us.
Our goal is to help clients innovate without fear, and to take the available resources to make the most innovative, successful technology product possible.
Our goal is to teach our clients how to do this by working alongside them and implementing together, so you can’t not know how to use a process that creates innovative, successful technology products with your own team when we’re done.
However, that’s not my goal, so let’s consider a few other options.
A logical conclusion might be to hire the best, most experience talent to lead your hardware development efforts. This is not a slam dunk since most of the world is developing hardware products the same way, as this person is most likely to be doing, too. Most individuals aren’t in a position to be thought leaders with the way they’re developing products within an organization because there is no incentive to provide that opportunity.
You could hire a product development consultant, whether an individual or firm. Even if you can find this person or group, asking analytically-minded engineers (who came up with the process in the first place as something that’s rational and deterministic) to change their ways because you said so is difficult. From our experience you have to show-by-doing with this crowd, and achieve a desirable result together.
You could read a book about product development. Most books are the product of a single person’s experience, in a relatively few number of scenarios—industry type, product type, type of customer, etc. Even if you can find a book that fits, books on product development are like many self-help books. If applying some basic concepts to a real situation was easy there wouldn’t be as many books on losing 15 pounds or stopping smoking.
Our suggestion: address a development process that’s rational but intolerant of change.
What do you do when your competition makes an unexpected move? What if you have a new business need like a partnership or more aggressive pricing target? Or if you get an early whiff customers aren’t wowed by your product? How do these conversations go when you bring them up with the product development team? The rest of the executives or your investors?
Most technology product development today is done using a change-intolerant process that can’t handle any of the above without inducing major pain.
Once a development plan is drafted, the organization builds itself around a specific product and ship date. To be able to do that, assumptions are made. The tighter the schedule, the more (and the worse) the assumptions.
Inevitably when one or more of them is proven wrong, there isn’t much that can be done about it—there’s too much momentum around the engineering team meeting their milestones and the organization building itself around the launch date.
I can assure you that if you’re frustrated by your lack of ability to develop innovative hardware products and you don’t know what to do about it, you’re not alone.
Most product development teams attempt to build a tunnel through time while the rest of the world stands still, and require that you nail what your customers want before you even begin development.
This is simply not reality. There is a better way.
With that big picture in mind, I’ll dive into more detail in my next post.