The 11 deadly sins of product development

Editor’s note: This post is an excerpt from “Prototype to Product: A Practical Guide for Getting to Market,” by Alan Cohen.

Thomas Edison famously said that genius is “1% inspiration, 99% perspiration,” and his observation holds true for product development. Developing “genius-level” products certainly requires inspiration, but the bulk of the effort is more like perspiration: work that benefits from insight and cleverness, but is also largely about not screwing up. Most product development efforts fail. It’s been my observation that failures are not usually due to a lack of inspiration (i.e., poor product ideas), but rather from mistakes made during the “perspiration” part.

What follows is a brief catalog of the most popular ways to wound or kill product development projects. Most efforts that get derailed do so by falling into one or more of a small set of fundamental traps that are easy to fall into, but are also fairly avoidable. As an organizational construct, I refer to the specific traps as sins and the more-general negative impulses behind the sins as vices. And since these sins are often fatal, I call them deadly sins to remind ourselves of their degree of danger. Before we get into the specific vices and sins, let’s start off with the fundamental principle that lies behind all of these, a basic truth that largely determines success or failure.

The fundamental principle of product development

There is a basic truth that applies to product development, really a fundamental principle: surprises only get more expensive if discovered later. Putting it another way: product development is largely an exercise in uncovering surprises as soon as possible. In my experience, most of what determines product development success or failure springs from this fundamental principle, and much of the rest of this book consists of strategies and tactics for respecting it. Now, with this fundamental principle for context, let’s list the specific vices and sins that commonly undermine product development.

The vice of laziness

Given the fundamental principle, it’s pretty obvious that putting off until tomorrow what we can do today is a bad idea, particularly for activities that are likely to uncover surprises. One of the most direct, concrete and common examples of this vice applies to testing.

Deadly sin #1: Putting off “serious” testing until the end of development

An obvious decision that delays our unearthing surprises (and making appropriate changes) is holding off on “serious” testing until after prototypes are largely developed. By “serious” testing, I mean the higher-level testing that looks at how usable the product is for our customers (sometimes called product validation) and at how the hardware, software, and mechanical subsystems work together, often called integration test and system test. When neophytes think about product development, they tend to think in terms of, “first we’ll build it, then we’ll do all of that high-level testing stuff.” Seems reasonable at first glance, particularly since some high-level testing can be difficult to do until all the pieces are put together. However, this approach delays our finding issues and making needed changes, sometimes big changes, which can be costly.

The vice of assumption

When developing a product, we’re assuming we know the features needed to achieve market success. Until the product goes on sale and the orders pour in (or don’t), we don’t know for sure if our assumptions are good or bad.

There are two common deadly sins that fall under the vice of assumption:

Deadly sin #2: Assuming we know what users want in a product

It’s pretty typical for product designers/developers to assume we know which product features are needed to make the average customer happy. After all, I know what I want — could other people want something so much different? This might not be a surprise, but if you’re reading this, then you’re pretty unusual. The odds are you’re seriously interested in technology, so much so that you want to learn more about how to develop products. Being enthusiastic about technology is a great thing — without people like you and me, humanity would still be hunting and gathering. But, for better or worse, the majority of humanity are not technophiles like us. Among other things, we technologists tend to be atypical when it comes to what we want in a product. We like things that have more features, more customizations, and that we can fiddle with for hours. “Normal” folks are mostly interested in getting the job done with a tool that’s effective and attractive.

Deadly sin #3: Assuming that users know what they want in a product

Well, if we techies don’t know what typical users want, surely we can just ask them what they want — they should know, right? Sadly, it turns out that users often don’t know what they want — they only know what they think they want. It turns out that what potential users see in their minds’ eyes when envisioning a new product might be very different than their reality once a product is in their hands. Finding out what users really want is largely a function of letting them try things out (features, prototypes, etc.) and seeing if they’re happy; it follows that we should start giving them things to try as early as possible instead of waiting until the end and praying that our assumptions (or theirs) were correct.

The vice of fuzziness

Fuzziness, or lack of specificity in planning a product and its development effort, is a major source of project failure. There are two big challenges introduced by fuzziness:

1. Stakeholders have differing expectations as to what will be developed.
2. It’s rather difficult (OK, fairly impossible) to estimate the resources and time needed to complete development if we don’t know the product’s details, at least to some degree.

There are three deadly sins that fall under fuzziness:

Deadly sin #4: Lack of comprehensive requirements

Product requirements are how we communicate our understanding of what a product will be. They ensure that all stakeholders have the same understanding of a product’s important attributes. When creating product requirements, we must work to capture everything that’s important to us and our customers — otherwise, the results may be different from what we wanted. Here’s an example of the kind of thing that happens often — marketing writes requirements along the lines of:

• The product shall have four wheels
• The product shall have a motor
• The product shall be steerable
• The product shall have an engine
• The product’s engine shall use gasoline
• The product shall be legally operable on all roads in the U.S., and in countries A, B, and C.
• The product shall be attractive.

Being practical sorts who are attracted to quirky designs, the designers/developers go off and build something that they believe will efficiently meet these requirements: a Volkswagen Beetle. Unfortunately, marketing had a somewhat different product in mind: a Lamborghini. While this example is obviously an exaggeration, it underscores the basic issue: requirements are how we make sure that everyone’s on the same page with regard to what’s being produced. We must be careful to include everything that’s important to us, or we’ll end up with (usually unwelcome) surprises. In this car example, some additional requirements from marketing would have helped create a better outcome, for example: “greater than 80% of target market shall agree that the adjective ‘sexy’ applies to the product’s design.”

Deadly sin #5: Lack of a good project plan

Project plans! I can hear your groans as I write this. For most of us, creating a project plan is as much fun as filling out a tax return, and following them as enjoyable as getting a root canal. Adding insult to injury, product plans are also inevitably inaccurate at laying out how we’ll proceed on a project: things rarely go according to plan for very long. Even on projects that are relatively straightforward, stuff happens, and early assumptions turn out to be wrong. Project plans are painful and inaccurate. So why bother?

General Dwight Eisenhower got it right: “Plans are worthless, but planning is everything.” While specific plans are inevitably broken by the end of the first week of work, spending substantial time and effort in the planning process is indispensable. Creating a detailed project plan forces us to think through issues that are easy to miss when we’re planning by taking a rough stab. It helps us to remember important details we’d otherwise forget about.

Deadly sin #6: Not assigning responsibility

Simply creating a task on a project plan with a due date and a budget doesn’t ensure the task actually gets done by its due date and within budget. One common problem is that when the time comes to start a task, we find that a detail’s been missed in the project plan that prevents work from starting on time, and we now have a surprise that impacts budget and timeline. Then once a task begins, there can be confusion around who gets what part done, and how multiple parts come together.

Adding an owner to each task greatly increases the odds of success. The task owner is not necessarily the person who accomplishes the task, but rather is responsible for timeline, budget, communications, and making sure the thing gets done. This helps in a couple of ways: first, it guards against gaps in the project plan. One of the ubiquitous imperfections in project plans is simply missing some tasks and details — there’s a task that needs to get done but we forgot to add it to the project plan. Throughout the project, each task’s owner can (and should) keep an eye on that task’s prerequisites to make sure everything’s falling into place for things to happen according to schedule and budget. Second, there’s no confusion over who will make sure that a task gets completed — no “Wait…I thought you were going to take care of that!”

The vice of cluelessness

The vice of cluelessness covers those things we have no inkling of. Since we don’t even know what to worry about, we’re in a state of blissful unawareness until we smack into a problem late in the game, sometimes even after product release, that can require product changes. A great mitigation for cluelessness is to rely on people with experience in the technical and non-technical areas that our product touches, either as employees or advisors. They’ve walked the walk, and know where the potholes are located. Another mitigation is to read this book: one of primary my goals in writing it is to flag issues that tend to blindside product development efforts. Of course, there are all manner of things that we can potentially not know about. But there’s one area that tends to cause the most trouble, which I’ll touch on next: keeping governments happy.

Deadly sin #7: Not addressing regulations

The classic and common example of getting stung by cluelessness is smacking into government regulations after a design is complete — for instance, finding out that customs is holding up shipments to Europe because our product doesn’t meet relevant EU requirements, or merely because our CE mark labeling isn’t being displayed correctly. Generally speaking, for most products sold in significant quantity, there are really two basic classes of requirements that our product must address. There are the “standard” requirements based on business needs — these are driven by what customers want (e.g., functionality, size, color), and by what our business wants (e.g, profitability, design language consistent with other devices we sell).

There’s also a second class of requirements that are imposed upon us by external parties such as governments and sometimes others such as insurers, as regulations, standards, and certifications. This second class of requirements, which we’ll call imposed requirements, generally addresses product safety, but can also address product performance (e.g., a measuring cup sold in Europe may need to prove it achieves a certain level of accuracy).

These imposed requirements are easily missed during product development as many people aren’t even aware they exist. And even if we’re generally aware they exist, it can be a challenge to find the ones that apply to our specific product: different governments have different regulations, different parts of the government have different regulations (hopefully not conflicting ones!).

Vice of perfectionism

Beyond the normal impulse that each of us has to do our job well, product development adds an extra incentive that pushes toward perfectionism: our work will be judged by many people, perhaps even millions in the case of successful consumer products. There’s the opportunity for much glory and wealth if we get it right, and conversely much embarrassment and the loss of money if our product disappoints: high stakes, which can lead to mistakes. Let’s take a look at some things that can go wrong when we become too obsessed with making the perfect product.

Deadly sin #8: The sin of new-feature-itis

New-feature-itis is the natural inclination to add cool new features as a project progresses. Obviously, this behavior directly violates the fundamental principle of product development, but this particular flavor of violation is worth reviewing because it illustrates some of the specific penalties we might pay.

“Hey! Wouldn’t it be cool if the product had [fill in cool feature here]?” is probably the most critical — and most dangerous — exclamation in product development. Whether it’s a positive or a negative lies in how and when it’s spoken. At the very beginning of a product development effort, during requirements definition, “Wouldn’t it be cool if…” is our best friend. At this stage, we’re trying to get as many cool ideas out on the table as we can. Once we have this list, we’ll ruthlessly cut it down to a “final” set of features (i.e. requirements) based on the value that each feature adds to the product versus the cost/risk of implementing that feature. Once the requirements are locked down, we can create pretty good estimates for development timeline and budget, and get going with the fun part of development: making stuff. Adding new features once the requirements are locked down will obviously introduce additional time and cost to development.

Deadly sin #9: Not knowing when to quit polishing

The longer we polish a stone, the smoother it will become. There comes a time when we should declare that the stone is smooth enough, and move on. Similarly, we can always make products more polished; it just takes more time and effort. But while we’re spending that time and effort, other things are happening. End users are being deprived of a product that could be improving their lives, even if that product could be made a little better with a little more time. Time is rarely our friend here. So, there comes a time when the product isn’t perfect — it never is — but it’s ready to release. Those thoughts about how we can do things better — as long as our product sells well, we’ll use those thoughts to make our next-generation product even better for our customers. In the case of software, there can be an opportunity to issue updates to product already in the field.

The vice of hubris

This vice has to do with believing that things will go according to plan. It’s easy (and important) to be confident at the start of the project. We have a detailed project plan in hand that looks reasonable and has been reviewed by a number of smart people, what can go wrong? Here’s my promise to you: we’ll find out what can go wrong once development begins. Boy, will we find out! Any bubble of pride that we hold for our ideas and project plans at the start of a project will be punctured quickly once “real” design/development commences. We will fail early, we will fail often, and the measure of a successful effort lies largely in how failures are dealt with.

Deadly sin #10: Not planning to fail

In Deadly Sin #5, I argued the importance of a creating a detailed project plan. Compared to gut feel and rough guesses, a detailed project plan at the start of development is a much better predictor of what our effort will look like. But even a carefully crafted, detailed project plan will be wrong, and it will be optimistic, and this should be accommodated realistically. We must plan to fail. Since we’re planning to deal with surprises, and since surprises are — by definition — unknown, it’s impossible to know for sure how much effort they’ll take to mitigate. In my experience, even detailed timelines and budgets prepared by highly-experienced people should be padded by 20%-30% to account for the inevitable bad surprises. If the folks preparing the initial project plan are not very experienced, or there are seriously new technologies involved, it’s easy for a project to end up 100% or more over budget.

The vice of ego

This vice is about holding customer desires beneath than our own. Other than “labors of love,” successful products, and successful product development efforts, are about what customers want. It’s not about what we personally want. Doing work in large amounts that we don’t enjoy is no good, of course, so the trick is to bring together people who’ll enjoy playing the roles that are needed to maximize customer satisfaction. Let’s look at a common tradeoff that’s often made badly when what we enjoy competes with what’s best for the product.

Deadly sin #11: Developing technology rather than developing products

Most technologists, particularly product developers, love to create new stuff. We tend to think of our jobs in terms of developing new technology. But developing technology and developing products are different things (although they certainly overlap). In particular, when developing products, developing technology is largely optional. We can choose to create technology for our product, or in many cases, we can choose to integrate existing technologies. If the product can be developed quicker/cheaper/better by integrating existing technology (and it usually can be), then that’s the way to go.

Think, for a moment, about Apple and Microsoft, two companies that have been extraordinarily successful at developing products. It could be argued that neither has developed revolutionary technology; they’ve only developed revolutionary products. Both Apple and Microsoft snagged from Xerox the concept of an operating system that uses windows and a mouse. Certainly, both Apple and Microsoft have plenty of resources to create new technology from scratch, and I’m sure they were tempted to do so in all the cases above. What made Microsoft and Apple so successful, in large part, is that they focused on meeting the needs of their customers, rather than on developing technology. To develop great products with reasonable effort, it’s important to adopt the Apple/Microsoft mindset: “What’s best for our customers?”

Final thoughts

As mentioned in the book’s preface, only one in 20 new consumer products are a success. This article has been a rogue’s gallery of some of the major gotchas that, in my experience, can reliably turn fantastic product concepts into a member of the failed 19-of-20. The first step in winning the fight is to recognize the enemy, and hopefully this overview has served in this capacity. If you’re new to product development, perhaps it’s also served as an introduction to some of the higher-level issues that we face: product development is about great hardware and software, of course, but creating this hardware and software requires a good bit of planning, psychology, communications, compliance with regulations, and a host of details that we need to get right.

Of course, just knowing what can go wrong isn’t enough: we also need to know how to avoid, fix, or at least mitigate the problems that can arise, which is the goal of most of the rest of this book. In its chapters, we’ll be getting pointed and practical about charting the best way through the icebergs so that our product has a much better shot at being one of the 1-in-20 product development successes.

Download a free copy of “Building a Hardware Business,” a curated collection of chapters from our IoT library. Editor’s note: this post is an excerpt from “Prototype to Product: A Practical Guide for Getting to Market,” by Alan Cohen, which is included in the curated collection.