The article in this collection: “Three Variables and One Constant Flip Flop” discusses how Quality, the one constant, is often sacrificed instead of changing one of the three variables in product development: Time, Resources, or Features. The excellent Wikipedia article on New Product Development lists the three product development variables as Cost, Time, and Quality.
There are clear differences in perspectives between the variables listed in this article and the Wikipedia article. The Time variable is the only one in common. Perhaps the Wikipedia article thought that Quality was a variable that was limited to good, better, great, or perfect as opposed to “good’ or “bad.” In any event, quality should never be considered as a variable. Quality, as determined by the customer, has become table stakes. It is demanded by customers. Even superior quality has become expected for many products and services and the premium paid for it has decreased as it becomes more commonly expected.
Prior to the launch of the actual product development, there are, indeed, three variables, time, resources, and features that can be discussed. All three variables are interdependent. For example, with more time and resources, more features can be included. (In this discussion, the term features is meant to include functions and performance as well.) Similarly, reducing any one variable will have direct impacts on one or both of the other variables.
However, once development has begun, the three variables are reduced to one or two. With rare exceptions, adding resources, previously thought of as a variable, becomes impractical. Adding people or automated systems after work has begun, most often, reduces the productivity of the existing resources that will invariably be required to find, train, and manage the activities of the newly added resources. This situation is unlike baseball, football, or soccer teams that have players (“resources”) sitting on the bench waiting to be called upon to enter the game to help. Bench strength due to competitive demands for efficiency has been significantly reduced across all enterprises.
At the same time that companies have reduced internal staffs, outsourcing organizations that can provide needed skills when appropriate are rapidly becoming available in most disciplines and most areas. There are even companies that can provide outsourced CEOs on a full-time or part-time basis. Unfortunately, it is often too late to add resources when it is discovered that the other variables or quality are in jeopardy.
Assuming, adding or reallocating resources is not a viable option, the remaining choices are to either extend the development time or to reduce features, the scope of the new product. Both of these options can have significant repercussions.
Extending the development time can have ripple effects internally as well as with prospects and customers. Entire windows of opportunity can close. For example, if a consumer product is delayed, the year-end Holiday Season shopping surge could be missed. Competitors may gain market share. Component suppliers’ inventories may swell and cash reserves, due to a lack of anticipated revenue may plunge. Customers, anticipating the pre-announced availability of the product, may also feel the impact of the delay in their implementation plans. They may be forced to explore other available alternatives.
We have all witnessed the impacts of missed product availability. In the past, some companies have been quite effective in freezing a market by pre-announcing a product in an attempt to delay prospect buying decisions until their offering was ready. Today, with significantly reduced product development and life cycles, pre-announcing products may be a risky strategy by providing more agile companies the ability to offer the same or similar products ahead of time or concurrent when their competitor’s product is available.
Based on the above, if resources and time are not usable variables, adjusting features is the only remaining option. In the past few years, the notion of providing the “Minimum Viable Product” or MVP, has gained wide spread acceptance. The underlying theory is that by offering an MVP, a company can quickly obtain customer feedback which, in turn, will help the company determine which areas (features and functionality) and even which market segments are the best to peruse.
The MVP concept is often associated with the Lean Startup model but is equally applicable to companies of all sizes as well as to new products or enhancements to existing products. However, when curtailing features in order to adjust for time or resource constraints, it is important to guard against dropping below the defined minimum functionality.
Aside from falling below the minimum acceptable functionality, dropping features can have other unintended consequences. Such as:
Internal Development Impacts
- With the complexity of most products or service offerings today, one feature can have impacts on many others. Simply “stubbing out” or masking a feature may not be practical. Its unavailability could impact the functionality of other elements in the product. At a minimum, it could impact testing, documentation, and training.
- As the pressure to enhance the product or address defects occur, the urgency to “go back” and add the temporarily delayed feature may diminish.
- Many customers have different single compelling reasons to buy as described in the article in this collection “One Question, Multiple Parts”. Eliminating a certain feature may make the new offering far less attractive to some prospects.
- Similar to the above, the reduced feature set may not be sufficient to entice existing customers to even consider the new offering. The article in this collection “The Power of Incumbency” addresses this often-overlooked issue.
All-in-all, reducing features may be the best of the bad choices. Obviously, the best choice is to avoid the situation in the first place and adequately plan for sufficient resources, adequate time, and reasonable feature sets while simultaneously never sacrificing quality. The practicality of this outcome occurring in even the best run organization is probably similar to buying only winning lottery tickets. The difference, of course, is that the lottery ticket outcome is pure chance, while planning product development activities is within a company’s control with the opportunity of making mid-course corrections regularly, incrementally, and quickly.