How to Ruin a New Product Development Process

It’s much easier to screw up a new product development process than mastermind a successful one.  Here’s how.

According to Gartner in 2019, 45% of new products are launched late while 90% of products introduced to the market fail to meet their internal launch targets. Meanwhile, the estimate for the number of new products that flop remains anywhere between 70% and 95%.

What’s the problem?

Most of the time, it’s processes that fail new products; whether it’s business owners kicking off projects with poor specifications, developers allowed to go rogue, or teams without a structured approach to collaboration breaking down into warring silos. Losing governance over process and procedures can lead to deadlines being missed and development dead ends from which we can’t escape. It can result in costs and specifications spinning out of control. Ultimately, it can lead to customer needs remaining unmet in a final product that fails in the marketplace - or never sees the light of day at all.

And don’t forget, lapses in governance and spiralling timelines can afflict organisations large and small. So, if you’re determined to ruin the chances of success for your new product here are four classic mistakes that any business can make:

1. Ignore customer needs - like Google Glass

You might think charging $1500 for a pair of weird specs is a bit steep. But when they’re made by Google and can analyse your progress as you go to the bathroom… it’s still a bad idea.

Lack of agreement around compelling use cases and proper product/market fit analysis doomed Google Glass to failure from the outset.

“There was no consensus among the creators about the core use cases of Google Glass. One group argued that it could be worn all day as a fashionable device while another thought it should be worn for specific utilitarian functions. Either way, both believed that Glass’ hype would compel users to believe in the product and use it accordingly. However, both groups assumed that Google Glass would be worn in public and be acceptable or even cool without validating whether its “hype” could overpower users’ needs and concerns in the real world.”

It turns out Google could make people look creepy in a really high-tech way, but customers just didn’t want them to. And the product died on its feet.

But while Google could afford to take this financial loss on the chin and absorb the valuable tech they developed into other projects, most businesses couldn’t survive a hit from a major project failure like this.

High tech companies, often working at the edge of what’s possible, should incorporate the definition and validation of user requirements into their product development process.

This should happen before a company embarks on a long and costly development journey, with regular opportunities for re-evaluation to ensure those needs are being met (or still exist) as the project continues.

2. Build some silos

If there’s something that’s bound to slow things up and sow the seeds of failure when it comes to New Product Development - it’s organisational silos. Losing your grip on collective oversight is a prime cause for processes going awry.

This article in the MIT review notes that the kind of ‘walled gardens’ often set up to protect tech teams from interruption and interference can be ‘remarkably soundproof’ and damage the effective operation of a NPD.

Teams might play lip service to Agile and DevOps with daily standups and ‘backlog grooming’, but detailed collaboration and information sharing about the state of a product dev timeline and choices ahead can often remain elusive.

Silos can encourage conversations to become one-sided - with developers obfuscating with complex technical explanations and business leads’ fixating on unrealistic solutions.

The consequences of this can be far-reaching, with both sides retreating into silence and conflicting agendas:

“technologists in [their] comfortable silo can wreak havoc on strategic priorities and trigger a cascade of effects throughout different parts of the organization:”

Meanwhile, business managers can fill the resulting vacuum with promises to investors and clients they can’t keep, while making increasingly unreasonable demands on their technical team to deliver.

Business and tech teams need the tools to enable structured communication between functions - tools that can provide shared visibility of project progress, decision making and approval requirements. These can help a company as a whole agree on priorities and focus on meeting shared project objectives in an accountable way.

3. Fragment your process across platforms

The dream of frictionless communication tools powering ever more agile NPD is often just that - a dream. But the reality is - a bit of ‘friction’ is sometimes necessary to create a trackable and accountable product development process that can be replicated in the future.

This article about one company’s doomed adoption of ‘Slack’, demonstrates some of the pitfalls of spreading formal business communications across platforms that aren’t really meant to record or manage structured processes.

“With multiple, simultaneous conversations happening inside a single Slack channel, we began losing track of things. Ideas were proposed, discussed for a bit, and lost. As a result, the same questions and issues were often brought up multiple times”

Where data and documents need to be managed, stored and subject to approval before ‘next steps’ can be triggered - a process which cobbles together tools like Slack and Google Drive can simply create a hot mess of feedback and ad hoc decision making that’s impossible to untangle.

“The lack of organization inside Slack had real consequences for our team’s access to information. We quickly discovered that real-time messaging wasn’t meant to preserve history or promote transparency.”

With an NPD using tools like this, there is a real danger of mistakes in documents being missed, required approval processes being overridden, and errors being amplified over time. And, course, your ability to reconstruct required documentation to meet the demands of ISO will be practically nil.

4. Struggle to release anything - like Magic Leap

But if you really want your new product development process to fail then make sure it’s as open-ended as possible.

Embarking on an NPD without a clear idea of what will constitute the completed product is a surefire recipe for disaster. Being ‘agile’ is one thing, but not knowing when - or even how - to stop is another.

A development team who keep tinkering and tweaking, or are in a constant state of ongoing development without a clear set of final deliverables, will sooner or later run out of money or enthusiasm.

Think about Magic Leap “the $4.5 billion dollar AR company” that kept promising the release of a world beating product - which after 7 years of development work barely materialised.

It’s an extraordinary story of hype and constant prototyping - of a technology that remained stubbornly out of reach. A story about the inability of a company to deliver effectively against its promises or even decide what those promises might be.

Here’s one review of the resulting AR consumer product that the company’s founder Rony Abovitz said would ‘bend the digital world to your physical life’:

“In reality, the dinosaur I see through the Magic Leap One looks genuinely three-dimensional, but pieces start getting cut off when I approach it. When a man walks behind it, I can see him slightly. My headset doesn’t account for relative distance, so it’s impossible for someone to walk in front of the dinosaur, no matter how close they are.”

In 2020, having pivoted the company in various ways, Abovitz stood down and the company began laying off workers.

If you’re slightly less wealthy and more risk-averse than Rony Abovitz, you may favour a different approach to product development and delivery.  One that prioritises return on investment in a structured and realistic way.

The contribution Magic Leap has made to the evolution of AR may, in the future, be incalculable. But the cost of the team not producing a saleable, profitable product that the market actually wanted - can be counted all too easily.

It’s your choice

So there you have it, if you want to ruin your chances of creating a smooth running product development process - focus on siloing your team, fragment your documentation and your communication across various platforms, loosen your grip on project governance, and don’t worry too much about defining deliverables.

Or you could choose a different, process driven, and more profitable approach...