Charlie Alfred’s Weblog

Seven Deadly Sins of Product Development

In 1321, Dante Alegheria wrote about the seven deadly sins in his work, The Divine Comedy.  Each deadly sin corresponds to one of the terraces of Purgatory: pride, envy, wrath, sloth, greed, gluttony, and lust.  More recently, Morgan Freeman, Brad Pitt, Kevin Spacey, and Gwyneth Paltrow applied this theme in the 1995 movie Seven.

This paper borrows this theme, to discuss the 7 deadly sins that thwart success in new product strategy and execution.  While this set of deadly sins is unlikely to cost anyone their mortal soul, any one of them could ruin the prospects of a product development effort, on its own.

The seven deadly sins of product development explored in this article are:

·       Solution-centricity

·       Overgeneralization

·       Ignoring reality

·       Hollow strategy

·       Misalignment

·       Mismanaging dependencies

·       Failure to prioritize

This paper will explore each of the “sins” individually, with a focus on how they jeopardize product strategy and development efforts.  Following this is a short discussion of how these sins can combine to generate negative synergy, and cripple product strategy and development.


On the surface, solution-centric behavior seems like a great thing.  In our society, who could possibly worry about those who formulate or advocate solutions?  What we need are more and better solutions, and we need them faster.

However, preoccupation with solutions is dangerous.  The value of a solution is in how well it fits the real problem.  Yet, the more complex the problem becomes, the less likely it is that the decision maker(s) understand it sufficiently well.  Complicating this further is the fact that most solutions lack justification, and when this justification is present, it is usually packaged like an attorney’s closing argument – emphasize all of the facts needed to get the desired verdict, and conveniently ignore all others.

One particularly deadly form of solution-centric behavior is a firm that focuses on “what we offer” versus what customers need.  It is much simpler for a firm to focus on what they provide, rather than spend a significant amount of time and effort to study what their customers need.  This is especially true when the firm has had a history of success.  As investment management firms are quick to point out, “past success is not a predictor of future performance.”  This wisdom is especially true when markets evolve rapidly, as in the automotive market in the mid-1970’s or the telephone industry in the 2000’s.

One major way that solution-centric companies get out of sync with the market is to fail to see how the answer to the “who benefits” question evolves.  For example, a global hemodialysis company initially focused its technology on the renal care patient.  When the technology curve began to flatten out, the nurse’s needs became more significant.  However, when opportunities to provide productivity began to peak, the main benefit areas shifted scheduling, supply purchasing, and preventative maintenance – each of which is at the renal care center level.  A lack of a problem focus combined with limitations in network communication in its dialysis machines limited the company’s ability to capitalize on this shift.


Overgeneralization is the failure to see the subtle differences in demand or in competitive offerings.  Overgeneralization differs from solution-centricity in that an attempt is made to understand the external environment, but the vision lacks depth perception.  It is like looking at color-coded maps of the U.S. without the legend and not recognizing differences in climate, topography, population, or wealth levels.

One outcome of overgeneralization is the failure to understand differences between market segments, and how this affects product differentiation strategies.  In Competitive Advantage , Michael Porter discusses four generic competitive strategies, organized in a 2×2 matrix:


In each quadrant except the upper left, formulating strategy depends on the ability to:

·       Understand what external forces, trends, or preferences cause customers to differ from each other.

·       Understand how these differences affect their perception of value

Neither product differentiation nor segmentation are new strategies.  However, their practice has evolved considerably over the years.  As Porter observes, product differentiation must be valuable to a significant portion of the market in order to be meaningful.

Market segmentation got its start by correlating consumer behavior with geographic, demographic, psychographic, or sociological variables.  However, these variables often fail to capture the motivations that underlie complex purchase decisions.  Erich Joachimsthaler discusses the demand-first growth model in his book Hidden in Plain Sight,  and emphasizes firms need to understand how products and services fit into the daily lives of their customers.

A large percentage of purchase choices, whether made by individuals or businesses, are complex considerations involving many variables and several alternatives.  High-cost choices almost always are.  Often, these choices are made based on a conscious cost-benefit analysis.  However, frequent, low-cost choices (such as where to buy the morning coffee or where to purchase office supplies) can be complex, as well.  The experiences and preferences of the decision maker(s) interact with the current and anticipated conditions to influence the choice.  Often, these choices based on unconscious associations and judgments that the purchaser might not be able to reconstruct.  Joachimsthaler discusses Frito Lay’s use of consumption diaries to record consumption and mood to gain a better understanding of the occasions when consumers buy Lay’s or Dorito’s.

In-depth information about purchase decisions is also useful to correlate buying patterns with motivation.  For example, when Sport Utility Vehicles were first marketed, the driving motivation was the outdoor enthusiasts ability to drive off-road to get to hard to reach camping, hunting, or fishing spots.  Over time, different motivations emerged, such as the thrill of driving over uneven terrain, superior handling on snow and ice, cargo space, and added visibility for the driver.  As a result, several new segments of SUV purchaser emerged, each of whom perceived a different type of value.  Not surprisingly, different manufacturers chose to specialize on different segments, and the luxury SUV segment (Cadillac, Lexus, Mercedes, etc.) emerged.

In summary, over-generalizing a market, whether it is health care organizations, cargo shippers, automotive buyers, or airline passengers is a dangerous activity.  Inadequate understanding about the motivations of groups of like-minded buyers leaves a firm in a vulnerable position:

·       Targeting solutions at a broad, generalized market, creating openings for competitors

·       Targeting solutions at the needs of historical customers, while other segments prosper

·       Differentiating their solution from competitors in a way that fails to create value

Ignoring Reality

Self-absorption and over-generalization are two of the significant sins that stymie the of a winning strategy.  Ignoring reality is a third.

Planning must deal with an uncertain future.  Developments in customer preferences, available technologies, and competitor actions can sometimes be forecast.  However, these forecasts are based on certain underlying assumptions, and have inaccuracies in both magnitude and time.  Further, each unexpected occurrence is likely to trigger several compensating adjustments.  Some of these adjustments counterbalance the impact of the event; others amplify it.

Given the importance of uncertainty in planning, ignoring reality is an even greater sin.  Consider the following examples:

·       Certain decisions are integral to the whole.  Many other decisions depend greatly on them.  Changing one of these integral decisions after the fact would be very disruptive.  Consider the pain of widening an Interstate highway after it is in service, or replacing all of the wiring or plumbing in an occupied 50 story building.

·       Certain tasks depend on other tasks.  You simply cannot make progress on the second group of tasks until you have completed (or at least precisely defined) the first.  Yet, people routinely ignore or underestimate the effect of dependencies.

·       Every system has a dominant constraint (also known as a bottleneck).  If it didn’t then it its output would be able to grow without bound.  Ignoring bottlenecks is a sure fire way to make terrible assumptions about what can be achieved or how quickly.

·       The ability of an individual to work on two or more activities at the same time depends on the level of immersion required by the task.  A senior manager who supervises progress at a high level may be quite able to switch between different projects.  However, a consultant or software architect may have great difficulty switching between projects.  This is a direct result of the greater level of immersion.

·       Unless a competitor has more business than they know how to handle, or is completely inept, they are not likely stand idly and watch you take away their business.  Competitors are also businesses, and they face the same pressures for growth and profitability as you do.  As a consequence, they will fight back, either directly or by attacking one of the weaknesses you expose.  If you come out with new features, they will attempt to replicate them.  If you pursue a new market segment, they may chase it or redouble their efforts to penetrate your core customer base (hoping that you are too distracted to counter).

·       Customers are not going to buy more products or services than they need, no matter how much they love your solution.  Once the reach the point of saturation, they will begin to slow down the rate of consumption. 

There are several reasons why people ignore reality.  Five common ones are:

·       People are unaware of facts that could alter their view.  Frequently, this occurs because people suffer from information overload or lack the time to do sufficient investigation.

·       People lack clear understanding of issues in areas that fall outside of their own expertise.  

·       People act out of desperation and feel compelled to make up for past or recent failures.

·       People work backwards from desired goals, and make whichever assumptions are needed to achieve them.

·       People experience pressure from superiors or peers and chose to conform rather than hold their beliefs.  

Regardless of the reason, people who ignore reality do so at their own peril, and often put others at risk.  Physics says that 10% of the mass of an iceberg floats above the water’s surface and large ships require a significant amount of time to turn.  Yet the captain of the Titanic felt his ship’s armor sides were invincible and gave the fateful order to proceed full steam ahead.  The Challenger and Columbia space shuttle disasters provide more modern examples.

A software development company embarked in late 2006 on a program to release a product framework by the end of 2008.  Near the end of 2007, it cancelled a major piece of the program and restarted another.  Yet in the post-reset planning, a target release date of December 2008 was considered seriously.  Given 6 months of QA and beta test activities, this left 6 months to ramp up a team and complete all development activities.  By contrast, the original plan called for 15-18 months.  What form of credible plan can possibly be built on this foundation?

Hollow Strategy

In his book, Product Strategy for High Technology Companies,  Michael McGrath writes about how essential it is that a firm has an effective Core Strategic Vision (CSV) for each line of business.  McGrath says the CSV specifies three things:

·       Where are we going?

·       How will we get there?

·       Why will we win when we get there?

The first two questions deal with the visible aspects of the strategy.  The three sins discussed above (solution-centricity, overgeneralization, and ignoring reality) directly affect the quality of the strategy that is formulated.

The third question is arguably the most important of them all.  In answering the “Why will we win when we get there?” question, the firm must address critical issues that are essential to the plan’s rationale – the core that determines its credibility and how well it is communicated and understood.

·       Why will many customers buy what we sell?  Which problems of theirs will it solve?

·       Are we considering the needs of all of the stakeholders for our customers?  For example, are we creating a fabulous user experience for the end users, while creating something that interoperates poorly with existing systems?

·       Do we attempt to sell similar products to the same customers?

·       What are competitors likely to do?  How will we gain or sustain an advantage?

·       Which partnerships must we establish in order to complement our limitations?

·       Are the pieces of our approach consistent, or do they conflict?

·       Is our approach realistic?  Do we have enough resources and time to succeed?

Consider the example of a firm that sells systems to create medical reports that describe the observations and outcomes of clinical events, like admissions, discharges, physicals, progress reports, surgical procedures, radiology interpretations, lab tests, etc.  The firm features the use of automated speech recognition to permit physicians to dictate their reports and correct any errors.  Another group of companies offer products called Electronic Medical Records (EMR) systems.  These firms have a slightly different focus – they maintain the official electronic medical record for patients.  While the first firm sees medical reports as an end (i.e. health care providers are required to produce them), the EMR firms see medical reports as means to maintain the patient’s medical record, and provides mechanisms to enable physicians to create clinical documentation.

This leads to some critically important strategic questions, ones that affect product definition, resource allocation, and marketing strategy:

·       Does the medical report firm compete with EMR’s?  If so, how does it gain and sustain competitive advantage?

·       Is the medical report firm’s product complementary to EMR’s?  If so, with which EMR’s should the medical report firm partner and how best should it complement them?

·       Should the medical report firm license its speech recognition technology to EMR’s?  If so, under what conditions?

The riskiest of all scenarios is not to answer these questions in a clear, decisive way.  It is extremely difficult for the firm to treat EMR’s both as a competitor and a partner.  And it is very difficult for the firm to retain one of its most important sources of competitive advantage (speech recognition) if it licenses the technology to EMR vendors.  In addition, two obstacles challenge the firm’s efforts to partner with EMR vendors.  First, once the overlap between the medical report and medical record products is eliminated, is there enough left over for either side to achieve its financial goals.  Second, because the EMR industry is new, there are no integration standards; the means for integrating with one EMR vendor may be quite different from integrating with another.

As this example clearly shows, it is quite possible to answer the “Where are we going?” and “How will we get there?” questions while ignoring the inherent conflicts.  However, answering the “Why will we win?” question forces critical examination of conflicting forces.  These forces are inherent in the system that includes customers, suppliers, partners, and competitors.  A realistic view of the landscape requires an in-context assessment of the objectives, strengths, pressures and alternatives that face each participant.


A well-formulated and well-communicated strategy is necessary, but insufficient, for success.  Good execution is necessary to convert the best strategy into desirable results.  Alignment of efforts is one essential aspect of good execution.

I’ve played many games of billiards, but I’ve never seen 15 pool balls rack themselves.   Alignment is the result of purposeful action; it rarely, if ever, happens by accident.  Alignment occurs in a system whose parts and behaviors are carefully architected to achieve a specific set of results.  Alignment must occur at many levels simultaneously.  Consider a symphony orchestra.  The conductor must ensure that the wind, string, horn and percussion sections play from the same score at the same time.

By contrast, misalignment is negative synergy.  It occurs when the areas of responsibility in a organization pull in conflicting directions.  The result is that the efforts expended by the various units limit or even nullify each other.  Consider a symphony orchestra whose wind, string, and horn sections are out of rhythm or out of tune.

Misalignment in companies can occur for several reasons.  Some of the common ones include:

·       The organizational structure of the firm creates internal competition.  In the 1980’s Hewlett Packard allowed its scientific and business computing divisions to compete with each other for the same customers.

·       Specialization causes some parts of an organization to be knowledgeable about 20% of the problem, possess surface awareness for 40%, and be largely ignorant of the last 40%.  The ironic thing is that it is rare that specialization inhibits someone for making a decision or arguing in support of some decision that is outside of their area of expertise.

·       Several departments or business units can depend on another department at the same time, and generate inconsistent demands.  These demands might be for different deliverables, or could pull the same deliverable in inconsistent directions, or could exceed the department’s overall resource capacity, or even the capacity of a key shared resource.

·       Goals or reward structures cause different functional departments to optimize their position at the expense of others.  This is a form of specialization that is magnified by external rewards.  Examples here are engineering units who are not rewarded for manufacturing costs, or product marketing units, who are rewarded for time to market or revenue without being accountable for product quality or development effort.

The following Dilbert comic by Scott Adams captures this nicely:


As an example of misalignment, consider a small, privately-held software outsourcing firm.  Over time, its business emphasis had shifted from an exclusive focus on software development projects to a mixture of software projects and consulting engagements.  Consulting engagements had several differences from software development projects:

·       a short duration (2-4 months vs. 12-18 months),

·       used fewer people (2-3 vs. 10-20),

·       had higher billing rates (50-100%), and

·       offered a lower price point to the customer ($100-200K vs. $1-2 M)

The potential for synergy seemed high.  Consulting projects enabled new customers to get started with a relatively small outlay, and provided the firm with an opportunity to get its most talented people in front of the customer.  In theory, this would help to generate development projects, because: a) the customer would be comfortable with the firm’s people, and the firm would already be deeply familiar with the problem.

In practice, several areas of misalignment created serious challenges:

·       Objectivity and impartiality, cornerstones of an effective consulting practice, conflicted with the pressure to convert a large percentage of consulting engagements into development projects.

·       The shorter duration of consulting projects increases volatility in scheduling resources.

·       The individuals who were most qualified to be consultants were also the best candidates for project management, software architect, and internal management positions.

·       Consulting responsibilities were allocated to the existing divisions (vertical markets).  The quarterly revenue targets and compensation plans for division managers made software development projects a higher priority.

Mismanaging Dependencies

Mismanagement of dependencies is a form of misalignment that often (but not always) results from ignoring reality.  Dependencies take several forms:

Natural Dependencies

These dependencies result from natural forces, over which we have little or no control.  Heat, air pressure, and electrical current differentials tend to equalize.  The earth rotates and time of day varies by location.  Humans must breathe, eat, and sleep a certain amount to survive.

Technical Dependencies

These dependencies result from the impact of natural dependencies on things that we design and build.  Certain product capabilities need specific architectural enablers (i.e. cell phones need a network of cell towers and the ability to sustain the call while switching from one tower to another).

Skill Dependencies

Skill dependencies occur when one individual or group does not possess all of the know-how needed to complete a task.  Skill dependencies also occur when two groups with different subject matter specialties need to collaborate, and neither understands the others area well enough to communicate effectively.

Language Dependencies

Language dependencies are a special case of skill dependencies, but are significant enough to mention on their own.  Language dependencies are usually not a major issue on their own.  Lack of fluency often is not an insurmountable barrier to casual conversation, and when it is, a good translator is often a remedy.  However, language dependencies often magnify obstacles in other types of communication, such as abstract technical concepts.    

Resource Dependencies

Resource dependencies occur when an individual or group possesses a required capability, but not enough of it.

Location Dependencies           

Several resources might need to be co-located, or may collaborate much more effectively if they are.   By contrast, resources might need to be located at different places in order to achieve a goal.

Time Dependencies

One activity might need to occur before or after another, or two activities might need to occur simultaneously.

A business organization or any other complex system contains a vast number of dependencies, usually including members of each of the types discussed above.  Frequently, some of these dependencies conflict, such as the need for half of a team’s members to be offshore (for cost control reasons), while skill dependencies could mean that the offshore team lacks important knowledge about the problem domain.  In addition, natural dependencies, like time zones or language barriers can limit the teams’ ability to collaborate.

Dependencies vary by degree:

·       Loosely-coupled  Failure results in a relatively minor impact.  An example might be a temporary disruption to a network connection.

·       Tightly-coupled   Failure results in a significant cost or delay.  A crash of a server that is a single point of failure disrupts all clients until the server is recovered.

·       Absolute      Failure is unrecoverable or catastrophic.  An example might be not having a full-time project manager for a project involving 10 distinct projects and 100 people.

Failure to Prioritize

Failure to prioritize is the pervasive sin.  It spans strategic and operational activities and occurs across the spectrum of concerns.  Any and all of the areas in the list below are places where there are frequent breakdowns in prioritization:

·       Relative business importance of market segments

·       Significance of pain points within each market segment

·       Relative urgency of product capabilities (tradeoff of features vs. TTM)

·       Relative importance of potential risks

·       Importance of architecture enablers to support product capabilities

·       Relative difficulty to implement

·       Cross-functional concerns (such as design vs. manufacturing vs. field support)

There are several reasons why prioritization rigorous should occur.

First, prioritization is a key input to significant tradeoff decisions.  How can we know which 3 features should be deferred in order to bring the development schedule in by a month, unless we have some mechanism for ranking the features by importance.

Second, effective priorities inform risk management decisions.   All risks have some non-zero probability of occurrence, and create a particular negative exposure if they were to occur.   A set of risks have various probabilities and various exposure levels.  Given limited time and resources, which risks should be managed and which should be left alone?  Priorities are critical?

Third, clear priorities enable groups to act with alignment.  All individuals have instinctive, unconscious decision making processes.  These processes are based on past experiences, prejudices, likes, dislikes, and hunches.  You can see this unconscious process at work when you have an urge to go to a specific restaurant for lunch, or you choose a particular radio station in the car.  You can also see this process at work on a larger scale when you shop for automobiles or homes or chose somewhere to go on vacation.  The same unconscious processes fire when you have a visceral reaction at work to a reorganization, or to a job interviewee.

There is nothing inherently wrong with these gut instincts.  In fact, they have served us very well.  The problem is that they scale poorly.  Get a group of 10-20 people together, and they will all have gut feelings about the same situation, but it is quite likely that these gut instincts will point in different directions.  Give the team members different objectives and expose them to different amounts and sources of information, and the problem is exacerbated.  Priorities are an excellent way for people in a group to come to some consensus about what the problem is, before they try to solve it.  The Decision Analysis process described by Kepner and Tregoe  relies heavily on prioritization to enable people in a group to evaluate decision alternatives in a rational manner.

So, given all this, why are people so reluctant to prioritize objectively?  First, people feel if they prioritize some things higher than others, they are inviting people to drop the items they rank lowest.  For example, a product manager might feel that if 10 features are labeled low-priority, then engineering will seek to drop them immediately.

Second, people often feel that if they identify their highest priority items, other people will be in a position to hold them hostage.  It’s better to be a poker player and hold a few cards in private to force others to guess at what you really want.

Third, people frequently manipulate priorities to justify the outcome they want.  For example, if a hiring manager prefers candidate X, s/he might raise the importance of experience in managing outsourcing partners.  It’s not that this experience is irrelevant, but by overstating its priority, it becomes a way to justify the hiring of candidate X.

Fourth, often people just don’t know what the priorities are.  It can be difficult to rank the relative importance of throughput, response time, security, up-time, and scalability in an enterprise system.  They each are important.  In fact, the real question is the relative importance of different levels of these quality attributes.  The difference between a response time of 1 and 3 seconds might not be as big of a deal as the difference between 3 and 5 seconds.

Fifth, sometimes people do have a clear idea of priorities, but cannot agree on them.  For example, product management’s top priority might be the release date, and their second priority might be a particular feature set.  Engineering’s top priority might be development budget, and their second might be product quality.  Manufacturing’s top priority might be reducing direct cost of material and labor, and their second priority might be having a second source for every supplier.  With a disparate set of priorities across the organization, it will be difficult to converge on product strategy.  In order for the organization to reach consensus, the key stakeholders must reveal individual priorities, discuss their rationale, and reach a mutually agreeable compromise.  Once this step is taken, the pros and cons of the various alternatives will become clearer.


None of the sins that Dante recounted in The Divine Comedy were immediately fatal.  An episode of rage would not drop someone in their tracks; nor would an episode of lust, greed, or envy.  These were sins that had a cumulative effect.  They would gradually eat away at your soul, until there was nothing remaining.

The seven deadly sins that we recount here are the same way.  An occasional bout of being solution-centric won’t ruin your company.  Neither will failing to prioritize, or being unrealistic, or misaligning.  However, practicing any of these repeatedly is certain to doom your corporate soul.  And what of repeated practice of several of them at the same time?  Well, can you imagine a firm where:

·       people rush to a solution before truly understanding the problem,

·       over-generalize the preferences of customers, suppliers, or other departments,

·       rely on wishful thinking as a substitute for realism in planning

·       pursue conflicting strategies without concern for the conflict

·       have multiple departments or projects pulling in different directions

·       let projects that depend on others proceed without top-level direction to align the others

·       fail to prioritize anything, lest something be deemed unimportant

If you don’t have to work hard to imagine this, then get out while you still can.  And if you choose to stay, speak up and try to change things.  If you are not as successful as necessary, take good notes, for it you are not a casualty of these deadly sins, perhaps you can leverage the wisdom at another place and a different time.



  1. […] Seven Deadly Sins of Product Development […]

    Pingback by Seven Deadly Sins « Charlie Alfred’s Weblog — January 18, 2009 @ 4:14 pm

  2. Ok, now we know the Mortal Sins, but, what about Venial Sins?
    Software Product Development can be done in house but also outsourced.
    I think Outsourcing Risks can be seen as the Venial Sins here.

    Here are more information, presented by Nearsoft Inc, about this risks and how to manage them:

    Outsourcing Risks
    Managing Risks

    Comment by Victor Velasquez — January 21, 2009 @ 7:53 pm

    • Very true, Victor. My current employer has been working with an outsource partner (Russia) for the past 9 years. We have encoutered each of the risks you mention and have successfully managed some, and are still wrestling with others.

      I would make a couple of additional comments from our experience:

      1. Even before writing requirements, it is important for the company and its outsource partner to get crystal clear on the problem being solved:
      o why the system is being built,
      o where the value comes from,
      o what the priorities are, and
      o where the most significant challenges are.

      Requirements are outcomes – ways to tell if the system is acceptable. Even the best requirements don’t often tell you where the hazards are and what kinds of tradeoffs can be made.

      2. Some types of systems are easier to develop than others. Client applications with visible UI’s are easier than client/server systems, which are easier than product line frameworks, realtime control systems, or algorithmically intensive systems.

      As systems become more complex, it is critically important to get your outsource partner involved as early as possible, preferably while the problem is being defined (before requirements are written). This will give them enough time to wrap their head around the problem, so that the requirements and architecture definition will make more sense.

      Tossing requirements over the wall, even well-written requirements doesn’t guarantee that they will be understood, which of course, is the real goal.


      Comment by charliealfred — January 21, 2009 @ 9:16 pm

  3. п»ї
    Can I put this article to my site?
    Thanks for the information

    Comment by johnstevens — June 22, 2009 @ 2:18 pm

  4. I have seen some of your posts and really liked them!! I have added your blog to my RSS Feed.

    Comment by Outsourced Software Product Development — April 2, 2010 @ 1:49 pm

RSS feed for comments on this post. TrackBack URI

Blog at

%d bloggers like this: