The Seven Deadly Sins of Product Development
In almost 30 years of business, I have seen some exceptional product launches. I have also seen my share of those that were underwhelming. Through these experiences, I thought it might be helpful to go through what I consider the Seven Deadly Sins of product development. These mistakes have turned what could have been a successful product launch into something less.
Deadly Sin #1: Hubris
I call this sin hubris because it is usually articulated as follows: “We know our customers and what they want.”
The very first step of successful product development is figuring out 1) who is your customer and 2) what are their main pain points that you are solving for.
At this point, you may be saying to yourself, “Of course we know our customers.” Really? Take the following example from the healthcare industry: The department head of a hospital helps determine what key clinical and technical requirements they need from a particular product. However, the nurses use the product on a day-to-day basis. The CIO of the hospital will want to make sure the product is compatible with the hospital IT network and security protocols. Then there’s the purchasing manager who will negotiate the best price, which plays a major role in which vendor is ultimately chosen. And don’t forget the biomedical engineering manager of the hospital who wants to make sure his/her team can troubleshoot the product quickly and easily if something were to go wrong. So, who is the customer? They all are because they all play a significant role in the purchase decision. Even if healthcare isn’t your industry, perhaps some of these dynamics are familiar.
Hubris comes from ignoring the unique needs of these individuals or, even worse, believing you know what they want without confirming it. Put in the work -- and by that, I mean qualitative and quantitative market research, conjoint analysis, and ethnography, just to name a few. Beyond that, establish a structured internal process to get regular input from your field-based teams. Be careful here though, because their input tends to be focused more on what features the competition has versus what the customers actually want. This is still valuable, but there is a difference. When taken together and prioritized (this is key, because you can’t and shouldn’t try to solve for everything all at once), these insights should help identify the key pain points you must try to solve.
Deadly Sin #2: Inversion
If you find yourself starting a product development conversation by explaining how sophisticated and cool your technology is, you may very well be guilty of this sin. It could indicate you have identified the technology and determined the technical product specifications before you have a fundamental understanding of the customer and their problems, which is backwards. Ideally, a deep understanding of your customer and their pain points will lead to a set of prioritized requirements for your product, which are then translated into design requirements and technical product specifications.
Starting with the technology and then looking for a problem to solve is rarely a winning approach. Force yourself to go through these logical steps: customer pain points —> prioritized requirements —> specifications. You may actually find through this process that you can relax certain technical specifications and save yourself the time, money and aggravation of designing in something that may not have been necessary.
Deadly Sin #3: Exclusion
If reliability and manufacturability are not a key part of the design process, the sin of exclusion has been committed.
Let’s start with reliability. Maybe you extensively use Failure Mode & Effects Analysis (FMEA) processes and metrics like Mean Time Between Failure (MTBF). Maybe you have even established targets against these metrics. That’s definitely a solid step in the right direction, but here are a few additional questions to consider:
Do you have a detailed set of use cases on how your customers will use the product on a daily basis? (this goes back to “hubris”)
Do those use cases inform your reliability goals for the product? (this goes back to “dyslexia”)
Are these reliability goals at the component level, system level, or both?
How extensively do you test the product against the actual customer use cases you’ve defined, including human factors?
If you aren’t doing (at least) these things, there’s a good chance you’re not doing enough.
Let’s now move to manufacturability. What I have seen in healthcare, particularly in MedTech, is no shortage of brilliant ideas and technologies. I have been in meetings where companies would show me beautiful prototypes of their products and, through these experiences, have come to learn that there are a lot of incredibly talented people who can make one of something. However, there are very few people who can reliably make 1,000, 100,000, 1,000,000 or more. Why? Because they aren’t paying enough attention to this aspect of the product development process – at least not until it’s too late.
Your manufacturing team (or vendor) should be an integral partner during the design and technical requirements process. Consider the challenges of automated manufacturing, for example. You cannot just take any product and run it through an automated factory. The machines performing the operations are “rigid”, they have limits. Due to this, they require product specifications that will allow the machines to perform the work in the desired way. The process requires meticulous integration and coordination between engineering and manufacturing in the design of the product and the definition of the specifications so that the automation process can accommodate the product, and vice-versa. This isn’t only true for a factory filled with robots, it is also true for a more manual manufacturing process, as well.
Reliability and manufacturability aren’t the only two considerations during design. Serviceability, for example, is another element to also consider. However, you cannot do it all. This is why the requirements gathering and prioritization around the main customer pain points are such critical first steps in the entire process.
Deadly Sin #4: Extravagance
The prelude to this sin goes something like this: “This product is more sophisticated than anything else out there and therefore costs more to make than others but, our customers will pay more.”
While this may all very well be true, one thing is almost guaranteed – it won’t be true forever. If you aren’t thinking about your product costs and how you are going to protect your margins as prices inevitably decline, you are making a grave mistake.
Design-to-cost strategies aren’t bad. From your upfront marketing work, you should at least have a sense as to what price the market will bear for your product. If you know what the answer needs to be on the margins / margin rates, then you can solve for cost of goods sold. This is a good way to get started as you set the initial cost targets for the product.
But this isn’t just about the initial cost of the product upon launch. Over time, the cost of product is going to need to come down. Your sourcing and sustaining engineering organizations need to play a key role in identifying cost out strategies. This doesn’t just mean you’ll get a better price from your vendors as volumes go up. That is a given. It also means cost reductions through on-going, methodical value engineering work. Two boards instead of three; leveraging off-the-shelf components; software instead of hardware, etc., etc.
This requires a structured approach to the lifecycle management of the product (more on that later), which informs a sourcing and value engineering cost out strategy that is defined upfront and executed methodically over time.
This sin also has to do the engineering team culture. If your R&D teams don’t take pride in taking cost out of the system, or view designing cost out as activity that lacks innovation / technical sophistication, then you have an environment that is unfortunately ripe for committing this sin.
Deadly Sin #5: Rush or Languish
Time – too little or too much – is an enemy in product development.
Most people would agree that trying to go too fast with R&D can compromise quality. If your project plans require near-perfect execution, you are in trouble before you start. A good program schedule requires a deep understanding of the critical path items and the dependencies. From there, the teams must have a keen understanding of what is needed to retire the most critical risks each step of the way. They should then use this understanding to model the resource and time commitment for these items using risk-based probabilities. Here is a simple test: ask your team to provide you with a schedule they feel they can achieve with 90%+ certainty. How does that match up with the schedule they are working to now? If there is a massive departure between these two schedules, then your team may be relying on flawless execution in order to deliver.
There is a flip side to this too. It may seem counterintuitive but taking too long can also lead to quality issues. Consider the following: a project runs into issues, the timeline slips, costs go up, funding is cut, after a while key people leave. Not only is the organization drained of critical talent, but institutional knowledge is lost as new people come in and try to put the pieces together. After a while, components start to become obsolete, vendors are impacted, new suppliers come into the picture, and so on. Every one of these things impacts quality.
In product development it is critical to find that right balance between recklessly fast and dangerously slow. Those who ask you to choose between speed and quality are usually presenting you with a false choice – you need to do both. Ultimately, your organization should be ambidextrous. This is why talent matters, especially in key roles. A world-class product manager, for instance, understands the importance of speed and knows that a strong schedule is just aggressive enough to make the teams uncomfortable, but not so aggressive that it requires flawless execution and creates a sense of hopelessness. Most importantly, if things go wrong (and they will), a world-class product manager knows how to mobilize the team to juggle and re-prioritize tasks so that precious time, focus and resources aren’t lost, while reliability and quality are preserved.
Deadly Sin #6: Fear
If you have a more evolved product development process, you probably have defined the key steps and established a toll-gate process that governs those steps. For example, maybe Tollgate 1 is identifying customer pain points and determining the prioritized product requirements, and Tollgate 2 is turning those product requirements in technical specifications. Before you can move from Tollgate 1 to Tollgate 2, the key stakeholders need to sign-off that the requirements on Tollgate 1 have been fully met.
If you have a process like this, that’s great. The next question is: “How well do your team members support and drive this process?” If the process isn’t being honored or team members don’t feel empowered to pause progress if key requirements have not been met, then this sin is being committed. One of the potential causes for an underwhelming launch can come from team members who are reluctant to exercise “the power of the pen” – or, withhold signature approval during a tollgate review if they feel certain key requirements haven’t been met. As a result, the program continues to amble forward when it actually requires a pause.
Here, again, culture is critical.
Typically, the reluctance is based in fear – fear of exposing a deficiency either in your own team or another team, fear of causing the program to miss the schedule, or perhaps even fear of retaliation. Ironically, the damage caused by prematurely moving forward is almost always worse than if the program was simply paused to address the issue. One word of caution: while everyone – and I mean everyone – in the program should feel empowered to raise issues to the highest levels of the organization, “the power of the pen” – the ability to actually stop the entire program – should be in the hands of relatively senior leaders, who are less swayed by fear and can exercise a broader perspective and leverage experience and judgement before pausing a program.
Making sure you have a culture that encourages every team member to raise issues and empowers key team members to pause the process if needed, is a critical step to a successful product launch.
Deadly Sin #7: Myopia
This sin depends on where your structured product development process ends. Let’s take a very simplified toll-gate process:
Tollgate 1: Idea generation
Tollgate 2: Product plan
Tollgate 3: Product design
Tollgate 4: Product verification & validation
Tollgate 5: Product launch
If your structured toll-gate process ends at product launch, then you are at risk of committing this sin. What happens after the product launch is just as important as getting successfully through tollgate 5. How will you support and service the product? What are your on-going plans to continue to drive reliability and cost out? How will you decide when the product has reached the end of its useful life? Once that is determined, what are the steps to phase this product out – including the end of service and support, the end of replacement parts, and ultimately, removal from the field?
If these questions aren’t considered as part of your product development process, then you risk exposing yourself to on-going issues with your supplier base and alienating your customers. A successful product development program thinks through the entire product lifecycle, from beginning to end.
So, there you have it – the seven deadly sins of product development. Now, admittedly, my focus has clearly been on product development (versus software or services). However, regardless of what industry you are in or what you are trying to develop, when you boil all of this down, I would submit there are a few fundamental things to make sure you are doing:
Know your customers intimately and put their pain points at the center of everything you do
Be methodical and rigorous — with the process and with picking talent
Create a strong value system and culture and then get out of the way
If you can focus on these things, you will provide yourself and your organization a good chance of not being tempted by these sins.
