Moving target of customers’ needs – Unendorsed challenge of building enterprise products

The primary emphasis for building a great product is to discover a right problem and getting married to it. However, customers’ needs and problems are increasingly becoming moving targets. The needs and problems evolve, so do the solutions to address them (i.e. the outcome too evolves) triggering an uncertainty of which needs or problems to address and what outcomes to deliver. It is a challenge that has primarily gone unendorsed or not consciously realized until now. The biggest mistake that Product Managers commit while building new product is to freeze needs and problems at a specific point in time and start building products for those static needs. Nevertheless, Enterprise products address hard problems and building such products consume around 12 – 24 months. With technology evolving much faster than ever, market dynamics changing too fast, and human race undergoing more changes than before, new needs or problems emerge, prevalent needs or problems extinct, and solutions embracing technology advancements to address needs or problems come in various shapes and forms. Primarily, Product Manager cannot taste success building a product for static needs. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. Agile methodologies and MVP (Minimum Viable Product) address those fallacies by reducing development cycles and incrementally validating whether the product is addressing right needs or right problems and delivering right outcomes. However, MVP seldom works for enterprise products.


Why MVP and agile methodologies could not address those problems of dynamic needs?

Enterprise products affect real businesses of customers, they might either help customers increase revenues, manage costs or streamline operations. The fundamental truth is enterprise products affect business in some form and hence they should be robust and resilient with zero-tolerance for failures while addressing a real business problem that is at the top of customers’ priority list. Therefore, delivering something quick, validating it and incrementally evolving the product does not augur well for enterprise products. Enterprise customers seek a complete solution. There is also a necessity for shrouding development efforts of certain enterprise products in secrecy to introduce an element of surprise and euphoria during launch. Then, how do Product Managers validate enterprise products causing minimal interruption to its targeted customers? Through maintaining a subtle balance between using MVP and relying on customer insights and experiments. Product Manager shall use MVP at the initial stages of product development to validate whether there is a real problem, whether the new product is addressing the real problem, and whether the new product is targeting the right customer segment. The problem with that approach is MVP does not consider time as one of its parameters. While constructing a hypothesis and validating assumptions using MVP, Product Manager has to validate assumptions across time space ensuring whether needs or problems persist across the duration of the product lifecycle and identify how they evolve. The appropriate approach is to understand the causal effect between needs, problems and corresponding factors that cause them. MVP framework for such analysis is:


The fundamental premise is to understand what is causing the need while validating the existence of a real problem or need and bundle the findings with customer insights to understand how the need or problem manifests in future. Understanding causal-effect of the need and its corresponding triggers along with customer insights should provide required clarity about the relevance of the need or how the need evolves in future. Customer insights are essential to comprehend what has caused the present to diverge from the past and use that as a reference to anticipate what will cause future to diverge from the present. Building customer insights are one of the key foundational pieces for building great products that enterprise customers want. Product Manager has to build customer insights through experiments and observing customers in their natural habitat, immersing in their business, assimilating their business process, problems and challenges and not just listen to what they say but to read between the lines to understand what they did not say. There is a dire need for restoring the lost art of gathering customer insights. MVP bundled with customer insights and experiments are required for validating any assumptions related to the new product and building a visual map of how customers’ needs or problems evolve and what new outcomes they might desire. Product Manager should learn to hit a moving target anticipating how needs or problems change as a function of time in future. How do you hit a moving target with an arrow, we notice the rate at which the target is moving, how long does it take for an arrow to hit the target and accordingly predict the possible position of the target when the arrow is released. Product Manager should do something similar not just to understand needs and problems of today but also to predict the needs and problems while the new product hits the market. Doing so, the new product will hit the bull’s eye when it hits the market.

Why does moving targets of needs and problems affect enterprise segment alone?

A unique challenge that Product Managers encounter with enterprise products alone and it is not applicable for consumer products is that enterprise customers’ are resistant to frequent product upgrades because of CAPEX (Capital Expense) and OPEX (Operating Expense), they tend to use a product for a longer period of 3-5 years (especially on premise products). On the contrary, business models of most consumer products rely on frequent product upgrades. There is no benefit in stacking all the value in a single product and making customers stick to a consumer product for 3-5 years. The duration for moving target of needs or problems of enterprise customers just shifts from product launch to eclipse the entire duration of product life cycle.


Product Manager should anticipate customers’ needs or problems as a function of time across the entire duration of product life cycle. Customer insights combined with extensive knowledge of how markets evolve, how technologies evolve, and how customers’ behaviors change should provide an estimation of how customers’ needs or problems change as a function of time and what new outcomes are possible. For certain enterprise products, addressing customers’ needs or problems as they evolve is not entirely possible without building a product architecture or a platform that can scale. I was once managing an HW product used by ISPs (Internet Service Providers) for defining policies of their internet users. During the launch of the product, internet speeds offered to each user was low. However, the internet speeds offered to each user raised exponentially far exceeding our predictions and the product could not meet the new requirement resulting in the early retirement of the product (or rather the product has to retire prematurely). In the enterprise segment, we tend to face a similar problem with complex SW products as well and refactoring the architecture can help but it will be costlier. Even so, refactoring the entire HW or product architecture takes time and there is a risk of not being able to address evolving needs or problems in a timely manner. When the only thing that is certain about future is uncertainty, a question that stares at every Product Manager is how to anticipate what needs will prevail and what new needs will emerge. In most cases, needs will be static, but the scale required varies. Another question that stares at every Product Manager is how much to scale and when?


Please keep watching this space as I revert back to further to continue the conversation on this topic. Meanwhile, I would like to understand whether you agree with above challenges. If so, please share your thoughts in the comments section below or drop me a note at If we are not reaching an agreement on this topic than any further conversations will be futile, looking forward to hearing your thoughts or opinions.

How not to ignore warning signal – To arrest product decline

As a Product Manager, my biggest fear is not to be conscious of the changes that are causing my product to decline much faster and much earlier. The changes could be triggered by either an individual or combination of sources such as competition, technology, customer preferences, new product etc. The changes could be either phenomenal such as 10x change, illustrated by Andy Groove in his book “Only Paranoid can Survive” or it could be incremental/sustaining causing a tangible dip in revenue/ market share.

10x changes do not happen on every day basis, but when occurred they prove disruptive. They create a new business model and trigger a new eco-system paving way for lots of additional opportunities while at the same time making older ways of doing things irrelevant. Microsoft Windows is definitely a 10x change, iTunes is another classic example. Both the products have disrupted desktop and music industry respectively.

I have to regret for repeatedly using Smartphone industry for illustration, nevertheless each one of us have witnessed those changes and hence it would be easy to connect to those illustrations. I would not call iPhone and Android as 10x changes but they definitely had created huge impact and it is evident for all of us. I list Android for the reasons that I had stated in earlier blog post: Has Android really changed the dynamics of Smartphone industry. Online shopping is another example especially after tremendous hit of  in India and for the impact that it is eventually having on retail stores.

All the above changes when unattended might prove disastrous to our existing product and it can even lead to slow death of our product. I am using the word ‘change’ in a more generic way to refer to any impending new product introduction or new competitor arrival or new technology introduction or anything similar that can cause some potential impact to the existing product/ players in the market. The changes that were illustrated earlier do not happen overnight, they happen gradually and steadily leaving us some amount of time to adapt/change/refine our strategy.

So we are eventually heading to the crux of our discussions that any changes will eventually throw certain signals which we should not ignore. Before the change occurs, we might hear about them in press or other tech blogs about possible launch of a new product or arrival of new competitor/technology. Though it would be too early to anticipate the impact, I would at least stress not to discard the changes. We can probably do a scenario analysis on how the changes when occurred would impact us. On the contrary what happens is that we turn out pessimistic about the changes. For instance in case of possible news about iPhone development, all the CxOs were expressing pessimisms over the success of iPhone:

  • In December 2006, Palm CEO Ed Colligan summarily dismissed the idea that a traditional personal computing company could compete in the smartphone business. “We’ve learned and struggled for a few years here figuring out how to make a decent phone,” he said. “PC guys are not going to just figure this out. They’re not going to just walk in.”
  • In January 2007, Microsoft CEO Steve Ballmer laughed off the prospect of an expensive smartphone without a keyboard having a chance in the marketplace as follows: “Five hundred dollars? Fully subsidized? With a plan? I said that’s the most expensive phone in the world and it doesn’t appeal to business customers because it doesn’t have a keyboard, which makes it not a very good e-mail machine.”
  • In March 2007, computing industry pundit John C. Dvorak argued that “Apple should pull the plug on the iPhone” since “There is no likelihood that Apple can be successful in a business this competitive.” Dvorak believed the mobile handset business was already locked up by the era’s major players. “This is not an emerging business. In fact it’s gone so far that it’s in the process of consolidation with probably two players dominating everything, Nokia Corp. and Motorola Inc.”


On the contrary to the perceptions of all those gentlemen, iPhone has tasted tremendous success threatening the existence of traditional players like Nokia, Motorola and Blackberry. The reason for those gentlemen to express pessimism is that each of them had tasted tremendous success and they probably hope that what made them successful at one point of time will ensure their success forever. However we have to understand that every day is a new beginning and what made us successful yesterday will not make us successful today. So it is always fair to keep the threat perception open and constantly revisit until it is proven that the change(s) does not cause any impact. For instance certain products/technology arrives with much fanfare but fade eventually (like Nokia N-gaze)

After the changes has occurred (be it either a new product, new competitor, new technology) the impact will be tangible at least through revenues, negative feedback from sales/distribution channels. Momentary decline or random negative feedback should be OK, so we should look out some common patterns and occurrence of any such patterns should be viewed as warning signals that should essentially caution us and trigger us to do a candid introspection of how our product is performing. Now it brings us back to our earlier blog post discussions on ‘Need for introspection of our target market’ to script turnaround story.

There are also instances where the changes would leave us no chance for survival and we have to graciously kill the product. There is no scope for survival of pagers after mobile phones were established. In such cases it is better not to try too hard to survive by burning lots of money. One simple rule to consider whether to KILL the PRODUCT is to verify whether both the product and market is in sunset mode.