3 Product Development Horror Stories

9 Lessons to Help YOU Avoid Disaster

3 product development horror stories

As a firm, M3 Design has put a stake in the ground for Stakeholder Centered Design. But how and why have we arrived at this manifesto?

Well, we’ve been in the trenches. We’ve seen products developed both ways—overly focused on the end user vs. tuned into all relevant stakeholders.

We’ve watched as stakeholder-related missteps made projects blow up. And we’ve seen stakeholder-savvy products soar to incredible success.

So, in the spirit of preferring hero stories to horror stories, we’re sharing 3 real-life tales of woe—and highlighting the 9 lessons you can take away to avoid disaster yourself.

This topic is incredibly wide and deep, so we’re just beginning to scratch the surface. But the following lessons provide powerful inspiration and guidance for

  • Making real change in your organization
  • Delivering revolutionary new products to the market
  • Developing products that actually make it to market and do well once they are there

When we officially declared that “User Centered Design Is Dead,” we identified the perils of focusing solely on end users and neglecting everyone else.

To dive into this topic further, we interviewed our own team members and explored real-life examples. We discussed previous experiences with other firms and companies, infamous stories from the industry at large, and our own experiences here at M3.

All told, we unearthed a mountain of insight about how to leverage stakeholders well (and how to do it terribly).

Today, we’ll explore:

  • The Blocked Voice: Purposely Shutting out Key Stakeholders
  • The Loudest Voice: Too Much Emphasis on One Stakeholder
  • The Missing Voice: The Stakeholder You Never Realized Was There

The Blocked Voice: Purposely Shutting out Key Stakeholders

It’s not uncommon for stakeholders to be identified, recognized as important, and yet “strategically” left in the dark—often for so long that the stakes get very high.

And before you know it, everything is on the line.

Here’s an example we witnessed first hand:

A very large Asian company housed an 80-person creative team in a Silicon Valley satellite office—quite literally an ocean away from corporate executives.

Under the guise of “protecting the creative team,” local management vowed to “shield the team from corporate” who didn’t “understand the creative process.”

Clearly, local management wanted their creative talent to have the freedom to think outside the box. This isn’t a bad way to create an innovation engine. And the team succeeded.

But siloing this team had created a firewall between the Silicon Valley crew and the parent company that funded them.

This communication barrier was maintained for so long that by the time executives saw the first working product, they not only hated it, but also closed the entire satellite office in one fell swoop. With 3 hours to vacate the building, all prototypes, materials, and evidence of the product’s existence were destroyed.

Although some of local management’s motivations for “protecting” their team were valid and well-intentioned, they missed the mark on finding a middle ground where some communication could take place.

The longer they segregated internal stakeholders under the illusion of solving a communication problem, the more they actually contributed to the problem.

So what can be done to avoid this?

Lessons Learned

Lesson 1: Recognize your stakeholders

First, realize that anyone who has the ability to “kill” your project—or the success of your product—is a stakeholder, particularly if they are funding your project.

Lesson 2: Avoid shock-and-awe unveilings

People in the C-suite don’t need to sit in on weekly design reviews. But they shouldn’t be left in the dark for 4 – 6 months at a time, then surprised by a great unveil when you need money for production.

If you were them, you wouldn’t like it either….no matter how great the product was.

Lesson 3: Customize your communication for the listener

Without diverse perspectives and buy-in from all essential stakeholders—from CFO to end user—you are not playing with a full deck.

To that end, it is up to you to adjust your communication style to facilitate fruitful conversations with necessary stakeholders. For example:

  • If the person you are interacting with isn’t an engineer, don’t show them CAD.
  • If you are speaking to a CFO, present design considerations in the context of a business model that makes sense for the organization.
  • If you are speaking to a CMO, reveal how you are working to align with marketing objectives, increase market share, ensure industry leadership, or achieve their hot-button goal.
  • If you are trying to gain feedback from users, a picture is worth a thousand words, but a simple prototype is worth exponentially more.

And remember to invite feedback at an appropriate time, place, and forum.

The Bottom Line

Overall, resist the temptation to leave key stakeholders out of the process. And put some thought into when and how you include them, as well as into how to best communicate with each.

The Loudest Voice: Too Much Emphasis on One Stakeholder

When certain voices are disproportionately louder than others, the imbalance creates

  • Skewed information
  • Out-of-whack priorities
  • A missed mark of success

Sometimes, a technical expert has the loudest voice, ignoring marketing and sales.

Sometimes, design has the loudest voice, minimizing engineering and manufacturing.

Sometimes, engineering has the loudest voice, while usability and intuitiveness simply aren’t addressed.

In other words, there are many ways to mess this one up. In our example, the “technical expert” had the loudest voice:

This technical expert is a God at his company. He is brilliant. He has his own budget, resources, and unfortunately, a lack of incentive to work collaboratively with other disciplines.

Years ago, we worked hand-in-hand with said “technical expert” to create a new device—one he strongly believed would solve a major problem and be the next great product in their portfolio.

Our team reported directly to this individual and to him alone, bringing his technical vision to life. For the better part of a year, we overcome complex engineering and design challenges to create an elegant, easy-to-use product we were all proud of.

The problem? This was a B2B sale, and in the eyes of the target purchasing department, other products already served the same function—and cost much less.

We later learned that marketing and sales had in fact warned the “technical expert” about the likely challenges of selling such an expensive product in a commoditized space. However, those issues were ignored and not communicated to the larger team.

Had we had this input earlier, we could have deprioritize various bells and whistles, making the product easier to sell at the right price point—while also making the end user’s life easier.

The difference maker? Lack of emphasis on valuable internal stakeholders. Today, this product is on a shelf somewhere collecting dust.

So how do you keep this from happening?

Lessons Learned

Lesson 4: Respect the market early & always

First of all, beware of situations where technologies are looking for a market and yet marketing doesn’t seem to be involved.

Do not minimize time spent understanding your user base, sales channel, etc. We have found much greater success when we encourage marketing, R&D, sales, etc. to pull up a seat at the table as we initially discuss a product’s landscape, as well as during key concept reviews.

Lesson 5: Mockup & meetup

A suggestion: use cheap, foam-core mockups to illustrate concepts. They provide a form that many varied individuals can understand, enabling you to present ideas in a forum with all key internal stakeholders present.

Meetings like this are great, because everyone hears the same thing at the same time.

And mockups are an effective tool for soliciting feedback from a mixed audience of marketing, sales, finance, etc.

But please don’t spin CAD at these meetings!

Lesson 6: Value your internal team

Ideally, you want to conduct internal meetings like this and do a fair amount of field research. Hopefully, this field research will include direct discussions with purchase decision makers, users, and other outside stakeholders.

However, if the perfect research scenario isn’t possible due to schedule or funding constraints, at a minimum, please lean on the people within your organization.

The Bottom Line

Overall, beware of scenarios where too much direction and too many strategic decisions are resting on just 1 individual, particularly if that individual works in a vacuum. It is an expensive mistake to make, and it is not good for business.

The Missing Voice: The Stakeholder You Never Realized Was There

Sometimes, the keys to success or failure lie with a person who has nothing to do with purchase decision-making—or even end use.

So do your best to at least identify every single stakeholder.
The world of endoscopy is a poster child for the problems that can result from failing to do this well.

Case in point: Olympus Corp.’s TJF-Q180V Duodenoscope, which is at the center of numerous lawsuits, including wrongful death claims.

A duodenoscope is a slender, flexible scope inserted though the mouth and used for a variety of medical procedures. According to the Food and Drug Administration (FDA), the design of the Olympus scopes made them difficult to thoroughly clean, resulting in hundreds of infections by a “superbug.”
Central to these lawsuits is the claim that Olympus’s duodenoscope redesign, with the goal of making the product easier to use, in fact made it more difficult to properly clean.

Now, is it obvious that the Olympus designers should design something that makes the surgeon’s procedure easier? Of course.

But clearly, another important stakeholder was missed. And the results were fatal.

Lessons Learned

Lesson 7: Fall in love with product journey mapping

You might think it’s pretty straightforward to identify key stakeholders—both internal and external—and pick out who is “important.”
But like anything else, this process requires its own level of rigor.

When we encouraged our team to start sharing real-world experiences of stakeholder-related misses, we opened up the floodgates for insight and advice. But 1 point cropped up in nearly every interview:

The product journey map is the single most essential tool for properly identifying & leveraging a project’s important stakeholders.

A journey map outlines every step your product will take from conception through disposal, identifying the stakeholders who interact with or influence it along the way. (For more on this process and how to do it well, see Gray McCord’s recent post, “User Centered Design Is Dead”.)

We believe a properly executed product journey map can save your project. And even save lives.

Lesson 8: Let the map lead you to unexpected places

You can create the most detailed product journey map in the world, but it won’t do you any good if you don’t use it to navigate your stakeholder landscape—wherever that may lead.

For example, we at M3 found ourselves spending more and more time in the basements of hospitals, observing sterile processing units before the Olympus lawsuits went public. It is a fairly grim environment populated by a group of individuals who are traditionally ignored, and often times our customers questioned why we spent time there.

But by understanding the instrument-cleaning tools available to these stakeholders, and by brainstorming ways to make their lives easier, we are better equipped to make design decisions that promote sterilization and reduce the spread of infections—something hospitals (and most humans) care about a great deal.

The same goes for scrub techs and nurses. By providing tools that make their jobs easier, we support them in making the surgeon’s job easier, in turn helping improve clinical outcomes.

By fastidiously uncovering all the people who touch or influence a product, then considering them as we design, we avoid countless complications and unearth myriad opportunities. It’s a win for all.

Lesson 9: Your map runs through business territory

To take this one step further, remember that there’s a business driving all of this.

Historically speaking, much surgical device development has emphasized the surgeon, because this was the stakeholder who traditionally had the most influence over purchasing decisions.

But these days, that is less and less often the case.

Hospital administrators and purchasing departments are becoming king. If you are trying to sell a piece of capital that is similar to other pieces of capital they already have, why would they care?

Your purchasers are stakeholders too. Consider their business goals.

The Bottom Line

The key takeaway? Do your product journey map, and let it guide you to your stakeholders. This has hands-down been the most useful tool for helping us uncover individuals we might have otherwise missed.

We think of it as a safety blanket—a tool that helps make sure we aren’t missing something that could ruin all our work.

You might not be able to address all of your stakeholders. But as long as they are identified, they can be considered. If they are never considered to begin with, they are almost certain to get lost.

Conclusion

Communication gone wrong. Teamwork upended. Outcomes destroyed. Whatever the co-stars of the above horror stories, the final spotlight lands on their lack of respect for the paramount importance of stakeholders.

To avoid disaster yourself,

  • Create your journey map
  • Respect the potential importance of every stakeholder it leads you to—whether internal or external
  • Bring your A-game as you observe, communicate with, and understand each individual who influences your product

Here’s to being a hero from this day on.

\

About M3 Design
Founded in 1996, M3 Design is a product development company located in Austin, Texas. We craft and execute product development strategies for leading technology-based companies.

Post a New Comment

Your email address will not be published. Required fields are marked *


All comments are moderated to prevent inappropriate content

*