Moving target of customers’ needs – A unendorsed challenge of building enterprise products

The primary emphasis on 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.

5 ingredients to building a great product

Building great product requires a mindset with multi-disciplinary skills. Every Product Manager would learn those skills only through hard way of building products, validating those products with customers and reinforcing the feedback back into building better products.

Based on my experience, I have listed 5 key essential ingredients to building great products.

  1. Audacious problem– Pick an audacious problem to address that no one has addressed it earlier or neither addressed in a way that you are addressing it. Doing so, the product will exceed every expectation to the astonishment of your target customers. All along ensure that customer really care for the problem to be addressed and they definitely pay a premium for addressing it. For doing so, you need to have extensive knowledge about customers and their needs.
  2. Think bold, think future– While picking a problem, think how it manifests in future. Do not just provide a solution for today’s problem. Even though it is critical to address today’s needs, your focus should be on extending the solution to address tomorrow’s needs. While addressing the problem or need, do not constraint yourself with existing technologies or existing benchmarks (What Elon Musk did to electric cars). Probably, your idea or solution to address the need or problem should pave for new technology evolution or change in customer behaviors. When Steve Jobs thought about the problem of stacking 1,000 songs in a device, he would not be constrained by whether any existing technology can store so many songs in a small form factor. Instead, his idea would have driven the evolution of such technology.
  3. Simplicity– This is one principle that is essential for every product. No matter how complex problem you are addressing, there should be simplicity written all over it on how customer will use the product to address their problem or needs
  4. Do one thing right – Be focused on doing just one thing. Do not be everything to everyone. Even if your product has to do multiple things, just focus on delivering awesomeness on specific elements of the product that will drive customers preference towards the products, instead of doing everything right.
  5. Impeccable execution – Nothing beats impeccable execution of the new product. Even a mediocre idea with perfect execution will win over an awesome idea with poor execution. As Ben Horowitz rightly said, focus on the little things and big things will take care of themselves. The statement is true more so during product development, Product Manager should start focussing on all little things even as simple as color and package of the new product.

Are the above five, the exhaustive list? Definitely not, there might be other things as well, but this is what I have learned from my experiences. It is not essential that all great products adhere to the above. For instance, some great products can address a simple problem, but the experiences that they deliver to customers will be a real differentiation.

Beyond those 5 attributes, the most primary aspect is to Start defining the WHY – Strong product vision that outlines the purpose and belief behind the new product

Finally, Product Manager should believe in the product, should believe in her abilities and in the abilities of her team to build an awesome product.

I captured some of those details in my eBook (free copy): Building New Product

Disclaimer: Even though I have built products, I fell short of building great products. I definitely learned how to build awesome product through the hard way of building and failing:-(.


Cross pollination of agile and waterfall

Withstanding all the hype surrounding agile, we did follow waterfall model while we built the new product. Agile does not work for all kinds of products even though waterfall model had its own flaws of not allowing the possibility to modify the requirements after entering development phase. So in order to introduce agility within waterfall model, we integrated both agile and waterfall. This blog talks about our experiences of experimenting with a new methodology combining both agility and waterfall. The below excerpts are from my eBook – ‘Building New Product – Experiences of a Product Manager

Our traditional approach to product development has always been the waterfall model. Nevertheless, while we embarked on our journey to build the new product we built the product upon the foundation of waterfall methodology while introducing agility within it. The ability or willingness to experiment with processes or methodologies should be fundamental for any new product development. The experimentation of processes or methodologies can occur when we know why we are doing what we are doing. There should always be a fit between the product and its development methodology, alike product-market fit. If we follow herd mentality and religiously follow a methodology without realizing why we are doing what we are doing, there will be hardly any scope for candid introspection of whether the product and its development methodology have the right fit.

Agile - WaterfallWe never consciously discussed altering waterfall and introducing agility within it. Program Manager naturally adapted the waterfall model to accommodate agility while we had several assumptions to validate, unknowns to eliminate and risks to mitigate. During the course of product development phase. There were never any serious discussions to brainstorm how to integrate both agile and waterfall development methodologies. The objectives and constraints of product development phase naturally triggered our Program Manager to combine them. Real kudos to our Program Manager to introduce agility within waterfall model. It is easy to follow stage gate process to ensure that we complete one stage and move to other. However, while we can only partially complete a stage and move to next stage. Later reverting to earlier stages based on the outcome of a current stage, it is extremely difficult to track dependencies across stages. Let me brief what we did.

For an enterprise product, the architecture of the new product is crucial. I can split the product into two blocks. Architecture block and product functionality block. Redesigning the architecture of the product is always costly and it is as good as developing a new product. Further, the choice of an HW is heavily dependent on the architecture and choice of product architecture is dependent on the HW. Both are mutually dependent. There is a necessity to ensure that HW and architecture can allow the software (i.e. functionality block) to scale as needs of customers evolve with little or no change to both the elements. Why are we putting so much emphasis on product architecture? I once came across a tweet that states every scale has an expiry date. True to those words, software has to scale in future as customer needs evolve and product architecture should support such scale requirements in future with little or no changes to product architecture. Certain elements of product architecture are rigid and it is not possible to modify it as new needs arise. Therefore, it becomes crucial to building a product architecture with a hindsight of how customer needs evolve in future. I did vehemently establish the fact several times in this eBook that the new product should cater to needs of tomorrow and not just for needs of today. Building MVP is not viable to identify needs of tomorrow while it is a viable option for identifying needs of today. Developing customer insights along with identification of factors that can influence the evolution of technology, the evolution of the market, the evolution of customer needs are crucial for anticipating probable needs of tomorrow. Clearly, for enterprise products where architecture can play a big role in determining the success of the new product and where the design and development of architecture happen upfront, agile is counterproductive. Incrementally building product architecture is a grave mistake. However, Program Manager introduced agility in building functionality blocks that address actual customer needs.

During requirements phase, we did outline all assumptions, unknowns, and dependencies across requirements of both product architecture and product functionality. The first priority was to eliminate all unknowns and validate all assumptions surrounding the design of product architecture. The design was mere theoretical until we start building it. Therefore, there will be many assumptions primarily around the ability of product architecture to meet scale requirements. To validate all those assumptions and eliminate unknowns, we constructed hypotheses. On those lines, we also constructed hypotheses surrounding product functional requirements. The product development happens in an interval of 6-8 weeks called DTHOs. Our 1st priority was to eliminate unknowns and validate all assumptions related to product architecture in earlier DTHOs. Dependent products requirements were refined based on the outcomes of those DTHOs.


Hypotheses of Product Architecture
Hypotheses Associated Requirements Dependent Requirements
H1 R1 R11
H2 R2 R12
H3 R3 R13
H4 R4 NA
H5 R5 NA


Hypotheses of Product Functionality
Hypotheses Associated Requirements Dependent Requirements
H6 R6 R14
H7 R7 NA
H8 R8 R15
H9 R9 R16
H10 R10 NA

The list of hypotheses surrounding both product architecture and product functionality has provided an indication to Development Manager and Program Manager on two aspects. First, the set of functionalities or requirements (R1…R10) that engineering team should implement during the initial DTHOs for validating hypotheses. Second, the set of functionalities or requirements (R11…R16) that engineering team should delay until validation of hypotheses (H1…H10). Delayed functionalities or requirement are later implemented depending upon pivot or preserve scenario in accordance with the outcome of validating each hypothesis.  PRD has clearly articulated the list of incomplete requirements. As initial DTHOs validated hypotheses (H1…H10) through implementing requirements (R1…R10), I refined all dependent requirements (R11…R16) implemented in subsequent DTHOs. The dependent requirements are mostly functional requirements that are refined after validation of hypotheses related to both the requirements of product functionality and product architecture.

One example of a hypothesis is – Ability of the product to meet throughput scale requirements (Hypotheses – H1). The PRD had a clear requirement for the product to deliver 60 Gbps at an average packet size of 512 bytes while maintaining low latency. The conventional wisdom is to measure and report maximum throughput at an average packet size of 512 bytes. Engineering team did validate the hypothesis by building the entire product but performing sizing through simulation. We identified during hypothesis validation that 60 Gbps is achievable albeit with a higher packet size. As I had indicated earlier, marketing team later did lots of analysis, found out the average packet sizes in customer networks is much higher, and we could conveniently defy the conventional wisdom. We never froze entire requirements. Depending on the hypotheses validation, dependent requirements were refined during the course of the new product development introducing agility within waterfall model.

The biggest criticism of waterfall model is that it always heads in one direction. However, we did introduce agility to shift our thinking back and forth between development, design, and requirements. Requirements (R11…R16) were kept open and refined after corresponding hypotheses are validated. We clearly introduced a loop containing product requirements, product design, and product development until we validated all the hypotheses. However, following a strict waterfall model, we had to build a foundation for product architecture upfront unlike in agile before going in a loop containing requirements, design, and development of product functionality. Such model is required for enterprise software products until we find out a methodology for modularly building product architectures for complex systems. Modular architecture should eliminate rigidness facilitating incremental additions to product architecture without the need for redesigning the entire system.

I really feel bad that some of the Product Managers hide their inefficiencies under the veil of methodologies such as Agile, MVP etc. Those are excellent methodologies drafted with good intentions. Nevertheless, those methodologies are more abused than used. MVP formulated by Eric Ries is an excellent way to incrementally build the product through an incremental process of build, measure and learn. Does it mean that a Product Manager should learn every aspect of product requirements through MVP? When it gets difficult for a Product Manager to comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of the product, it will unnecessarily delay product development. There is always a necessity to strike a balance which I find missing. Further, in the case of enterprise products that have a direct effect on customer’s business, the customers will not be ready to validate it thoroughly. While building complex products for enterprise customers, it is always crucial to do extensive customer research and draft those details in PRD to get the bigger picture of the overall product. User stories do not communicate bigger picture. I can definitely bet if I ask for a PRD, some might even perceive me as a person from the dinosaur age. I am not showing my indignation on everyone. Probably, just a handful of them. My request is to embrace methodologies and process, comprehend them thoroughly and adapt them to suit your new product development. Always find the right fit between the product and its corresponding methodology.

Every incumbent product has vulnerabilities

What does success stories of Tesla and Waze teach every Product Manager?  Every incumbent product is vulnerable and there is an opportunity to beat even awesome products.

Tesla Sales

How many of us would have believed that there is a possibility for a new player to emerge (leave alone succeeding) in the luxury car market, beating the likes of Audi, BWM, Mercedes, Lexus, etc? Yet, Tesla zoomed to the top beating the engineering, luxury, speed, performance, and safety of luxury cars built by Audi, BMW, Mercedes, etc. While sales of every other luxury carmaker were declining, Tesla managed 50% YoY. The phenomenal growth of Tesla when the growth of the entire market was actually declining.

Tesla clearly shows that they have defied every conventional wisdom of building products. Elon Musk has shattered existing benchmarks for building the new product. The first element that an investor would look for while building a new product is whether the target market is a growing market. Similar logic applies to Waze as well. Investors would be interested to know whether the new product is addressing a tangible gap and whether there is a place for an alternate product. How many of us would have had the brilliance to spot the white space in navigation products and boldness to overcome Google Maps. Waze did it, Waze managed to build an amazing navigation product preferred by lots of users over Google maps. I could not imagine someone building a better navigation product than Google considering navigation product require lots of work and even Apple failed in its attempt to build an awesome navigation product.

Those examples are testimonials to the fact that it is highly unlikely to build awesome products adhering to existing benchmarks. Conventional wisdom always believes in building a new product in growing markets and in markets where there is a palpable gap of unaddressed needs. The Conventional wisdom of building products is accrued naturally through precedents set by earlier successful products. Astronomical valuation of Facebook during its initial days based on its active users instead of its actual revenues has set a precedent for every other internet company to focus on user acquisition and not on generating actual revenues. Someone should set the precedent first before it becomes a conventional wisdom. The Majority of great products have set the precedent and not followed any existing precedent set by other successful products. Tesla and Waze have also set a new precedent going against conventional wisdom. They have proven that every incumbent product is vulnerable and there is always an opportunity. However, it is not an opportunity that is visible in plain sight. All it requires is a keen eye to identify white space, bold thinking, appetite for risk, impeccable execution to beat incumbent products.

The above contents are part of eBook – ‘Building New Product – My Experiences’


Building New Product – Experiences of a Product Manager (2nd Edition)

I have rolled out 2nd edition of my eBook – ‘Building New Product – Experiences of a Product Manager’. Much of the focus in the revised edition is around idea validation. Please take a look and share your thoughts.

Please be aware that the book is still WIP (Work In Progress), I am still contemplating to create better frameworks. The efforts are eluding me for a long time, hope I will be lucky soon. Meanwhile, if you have any suggestions or recommendations, please do not hesitate to reach me at murali[dot]erraguntala[at]gmail[dot]com

The latest copy of the eBook could be found at


Building new product – My experiences

I have consolidated all my earlier blog posts on ‘Building new product – My experiences’ into a document (both .PDF and .PPT) and got them uploaded to slideshare.

Please check them below:

Link to slideshare:

The copy can be downloaded from

.PDF version

.PPT version

For ease of reference, i also provided the links to my earlier blog posts related to building new products

Ideation phase

Business review phase

Drafting product requirements

Importance of a monitoring plan

Product development planning

Product development

Essential traits of Product Manager for success of new product development

In the next series, i will focus on articles related to product roadmap preparation. I will try to focus on the following

  • Purpose of product roadmap

Product roadmap serves different purpose to different stakeholders, but product roadmap is required by all the stakeholders(product managers, customers, development team, sales, business development etc)

  • Contents of product roadmap

‘Listen to your customers’ is age old adage that is followed by every business and I am not advocating doing anything differently. I am just trying to emphasis that we both listen and understand our customers, but we do not let them decide our product roadmap. On the same lines, I want to quote the words of Henry Ford “If I had asked people what they wanted, they would have said faster horses.” Ford while listening to his customers understood their innate needs of travelling quickly from A –> B. So does listening and understanding our customers alone would suffice? Can the roadmap be filled with customer requirements alone?

  • Ratio of customer vs market focus features in product roadmap

Product roadmap should focus both on market and customer, the biggest dilemma now is to determine what % of the product roadmap would be occupied by both market and customer requirements?

  • Where product requirements originate

Product Manager alone could not be a single source of origin for product requirements, product requirements could be generated by pretty much all the stake holders (including BDMs, sales, development teams, customers etc). Now the larger question, how could Product Manager ensure that there is a free flow of product requirements from all the stake holders to the Product Manager?

  • How to prioritize product requirements

There will be umpteen requirements gathered from all the stakeholders and what parameters does Product Manager use to ensure that right set of requirements are prioritized in each release and how does Product Manager measure the efficacy of prioritizing the product requirements?

  • How to stick to product roadmap without letting your customers hijack it

PMs diligently prepare the product roadmap to reflect the product growth strategy. Nevertheless nothing works as per the plan. First roadblock that every PM face is some unexpected product requirement requests from their customers and that product requirement will be total deviation from the items planned in the roadmap. How Product Managers could stop their customers from hijacking the product roadmap?

Happy Christmas and Happy New Year


Essential traits of Product Manager for success of new product development

In the concluding section of the blog series related to new product development, I want to focus on the essential traits of a Product Manager required for new product development. At least my take on new product development is that the Product Manager should imbibe the following qualities for a successful product development. The below qualities are in-general required for a Product Manager

  1. Technology Awareness/Market Awareness/Customer Awareness
  2. Embrace Tough Decisions
  3. Meticulous Planning
  4. Attention to Details
  5. Facilitator
  6. Knowing the Constraints
  7. Self-Starter

Please note that the above qualities are not listed in any specific order of importance.

Technology Awareness/Market Awareness/Customer Awareness

Product Managers should have a stronger understanding of 3 elements (technology, market, and customer) and I believe it is the fundamental requirement for any Product Manager. I split customer and market because it makes sense in case of B2B product. Product Managers should have complete knowledge about the characteristics of their target market and how they are using the product. Marketing awareness is more about competition (how competition is currently positioned and how they are evolving?) and trends (how new technology trends would impact the evolution of the product?). For me market and customers are probably two sides of the same coin, I mostly believe that your customers will help you to gain a short term view of how the product should evolve while market will provide a long term view. Product Managers need not have diploma in Computer Science but they should hold necessary acumen to grasp the technology aspect related to the product, when it comes to technology awareness Product Managers are expected to be more of Generalists than Specialists. For instance, in case of IoT, Product Managers should be at least be aware of what is IoT and how it will impact the way the customers use the devices and how the devices could possibly communicate to render new value proposition. Unless Product Manager imbibe all the 3 qualities, I don’t see foresee how a Product Manager could build a new product vision and communicate it effectively to all the stake holders. In addition, Product Manager should facilitate consensus among all the stake holders on the new product vision.

Embrace tough decisions

New product development will invariably have surprises and Product Manager would be sprung with surprise from all corners (and it happens too often). Meticulous planning can only minimize those surprises and it cannot be eliminated completely. Few surprises might be in the form of vendors’ inability to deliver their components as promised, vendors’ inability to support components for the perceived lifetime of the product, cost escalation, new technology not performing as expected, reduction in marketing budget, inability of the product to meet certain standards, competition launching superior product. So Product Managers should be geared to take some quick tough decision and make some trade-offs on need basis. To do so, Product Manager should be well informed about the market, technology and customer. Such awareness can help product manager to take quick and informed decisions, for instance they can quickly cut down certain features to roll the product on time still retaining the value proposition and appeal of the new product.

Attention to details

Product manager has to demonstrate lots of attention to every facet of new product development (business review, PRD, pricing, GTM etc) even for aspects as trivial as labelling, packaging etc. While submitting the business or pricing proposal for new product or reviewing PRD, Product Manager has to pay utmost attention to details, so the proposals or reviews are infallible and Product Manager gets them right the 1st time reducing iterative cycles and thereby avoiding delay. In addition, the focus should also be on how the product is built. PRD would contain information on what to build and why to build, but it will not have any details on how to build. PRD will utmost provide only guidelines for how. During the development, Product Manager has to keep a tab on how the product is built, periodically review the product characteristics (color, shape, design etc) and product features, and finally share the feedback without waiting until the final product is built. Great product could be built only through relentless attention to details and zero-tolerance to mediocrity.

Meticulous planning

There are tons of activities that are performed by Product Manager from ideation till launch and during this time frame Product Manager has to dedicate his attention to entire gamut of activities consisting of product development, product naming, legal, pricing, GTM, compliance, intellectual property, royalty, supply-chain, manufacturing, distribution channels, product documentation, marketing collateral, ordering, beta trials, vendor management etc. Unless Product Manager meticulously plan those activities and derive a precise plan on how to time manage those activities, he will not be able to provide due attention to each of them and implications will be palpable post the product launch.


One important role that a Product Manager should play is an effective facilitator and the significance of this role is even more critical during new product development. Product Manager have to work has if there are no real boundaries to their role. In simple words, Product Managers has to help others get things done while he does not lose focus on his own set of responsibilities. For instance, Product Manager should never ask the development team to cross the bridge to understand the requirements of the customers. Instead Product Manager performs the job and let development team focus on the actual product development. Product Managers while being unreasonable and ruthless in demanding more from the development team, he also needs to provide a shield or protective cover to the team from unnecessary deviations.

Knowing the constraints

Everywhere resources are limited and even the flagship product of any organization would get only finite resources. ‘Resource limitation’ is universal fact, every Product Manager has to confront this reality and still ensure how he could take advantage of available resources (time, headcount, or $ budget etc) to create a vision of the new product and realize the vision. So it does not suffice if Product Manager could create a vision of the new product, he has to be aware of the constraints and should have a clear understanding of how to execute the new product vision within the boundaries of the constraints. Product Manager should never whine about the constraints.

Self-Starter and Persistence

Self-starter attitude should be a primary quality of Product Manager because there is none better than Product Manager to spot the opportunity. Even after the launch of the new product, self-starter qualities alone will trigger Product Manager to generate demand, identify white spaces etc to expand the revenue opportunities of the product. While self-starter quality could act as a catalyst for lot of product initiatives, persistence of a Product Manager would enable them to have the urge to find solutions for any obstacles that stands in the way of accomplishing the initiative. Self-starter and persistence are two qualities that should always go hand-in-hand.

Final Word: Product Manager is the face of the product and he has to rally everyone to create a unified vision of the new product. Even though the role of the Product Manager in successfully building new product is inevitable, Product Managers has to realize that the product is built by a team and he has to let the team take the credit for the success of the new product.

Building new product – My experiences (Ideation)

The process of ideation is to focus on all the possible unmet needs of the customer. Later on, to figure out how to address those needs in a much more effective, efficient, optimal, user-friendly manner and at an attractive price point that is economically viable to customers. I do extend the same definition for Products as well. In my opinion Products either meet the needs of the customer or enhances their experience. They do so in more optimal way in comparison with the competition at a price point that customers can afford or willing to pay. Ability to afford or willingness are two different things, even though your target customers can afford to buy the product they don’t buy unless they feel that the value obtained is worth the price. On the contrary, the customers market might be willing to pay the price but they could not afford. So it is essential to look at both the factors. In case of ‘Willingness’ without ‘Affordability’, it can open doors for new low cost product idea. Much of this space might fall under the category of ‘Fortune at bottom of the pyramid’ devised by C.K. Prahlad.

Idea validation

After formulating an idea depending on the unmet needs of the prospective customer, we need to start validating the idea. The validation process really depends on the nature of the idea. If the idea is an extension of an existing product line, then your existing customer base could act as a sufficient sample for idea validation. The existing products could be over serving/ underserving the target segment or could not meet the needs of a specific segment. So the new product could complement to the existing product line to address the needs of a new segment or unmet needs of existing segment or replace existing product to address the needs of existing segment. In any case, I don’t think it would be too difficult to validate the idea. However if the idea is revolutionary and creates a new product category, then we could possibly consider customers using the perceived alternative. For instance, in case of 1st mobile device, we could have validated the idea of mobile device with users of pager. However in case of revolutionary idea, it is not always advisable to purely rely on customer. In case of 1st mobile device, the customer would be excited about receiving the voice call anywhere/anytime instead of just text. But they could not think beyond the device, for instance success of mobile devices also depends on the operator’s capability to launch the service at an affordable price and governments willingness to auction available spectrum for voice call services. For operators as well, it is huge CAPEX to deploy the required infrastructure. So success of the product really depends on various external factors and this is precisely what I call a product ecosystem.

Timing new product

The larger discussion that needs wider attention is to figure out the right time to start new product development. Timing of the new product is also dependent on whether the new product is an extension to an existing product line or does it create a new product category (most probably a revolutionary idea). In case of new product creating a new product category, there is already unmet needs so the emphasis should be more on hitting the market first. However from the timing perspective, we need to figure out whether the product ecosystem that is required for the success of the product exists. For instance, in case of 1st mobile payment product like m-pesa, the success really depends on the density of mobile usage among rural population and network coverage in rural areas. SPOT (Smartwatch my Microsoft) is a classic example of product release way ahead of its time. The product ecosystem was not too conducive for the success of the SPOT. The discussion bring us to back to the topic of product ecosystem that we discussed during ideation, while timing the new product we have to ensure the readiness of the product eco-system aligns the new product release. I have elaborated more about this topic in earlier blog post ‘Detailed requirements gathering – PRD

However in case of new product belonging to an existing product line, we need to figure out the timeline to develop new product based on deeper understanding of how customer requirements would evolve during the product development phase. Customer might not be able to articulate what business challenges they might face in future, based on the trends impacting the product and the general understanding of the customer business environment, we might need to anticipate customer requirements and ensure that the product being built will optimally address the requirements of the customer when it is released. Other aspect is to watch out for signs (competition, trends, new technology, win/loss trends and declining revenues etc) that would signal the need for new product development. Please take a look at my previous relevant blog posts

Estimating market size

Identify the target customer and estimate the total population of the target customers (we generally call it as TAM – Total Addressable Market) and finally estimate how much of entire TAM can the new product penetrate. Available statistical data or guesstimates could be used to estimate the TAM. The idea might have a global appeal but for some strategic reasons we might target local market first. We need to outline which segment (based on demographic) of TAM are we targeting first. For instance, cloud based education SW to facilitate teaching on a dump terminal is a universal idea and it has global appeal. But initially, we might focus on local geo-market before expanding globally. In any case, the estimated market size should include both.


After estimating the market size, Product Manager has to ascertain whether the size of the market is large enough to break-even and make margins. Firstly understand whether customer can afford to buy the product and is willing to buy the product. Ability to afford or willingness are two different things, even though the target customers can afford to buy the product they don’t buy unless they feel that the value obtained is worth the price. On the contrary, the customers might be willing to pay the price but they could not afford. So it is essential to look at both the factors. In case of ‘Willingness’ without ‘Affordability’, it can open doors for new low cost product idea. Much of this space might fall under the category of ‘Fortune at bottom of the pyramid’ devised by C.K. Prahlad. If the customer is willing to buy the product and can afford to buy the product, determine whether the market is big enough for making profits based on the estimated TAM and penetration rate.

Organization fit

We conclude the ideation phase trying to evaluate whether the new product is aligned with the organizations goals and strategies. The new product development would not be approved unless Product Manager establishes how the new product would align with overall goals and strategies of the organization. Next is to evaluate whether the organization has the required capability and experience to build the new product.

Final Word: More often, an idea might evoke a “WOW” feeling among customers. However one should cautiously evaluate whether sizable number of customers can afford and ready to pay the price to experience the “WOW”. Remember Iridium! Even though it was a great product idea (in spite of some technical glitches), only smaller chunk of customers could afford it.

Building new product – My experiences (Part V – Product development)

This blog is the Vth part in series of blog post on new product development. Actually product development phase is the final phase of new product development. However i am not concluding series, i missed to talk about ‘Ideation phase’. So the next blog post is on ‘Ideation phase’ and the final blog post is to outline the essential traits of PM for success of NPD

The entire product development phase is completely driven by the Program Manager, the role of the Product Manager cannot be negated and I have outlined various activities performed by Product Manager in parallel to the product development for the success of new product. In this blog, I will focus on activities exclusively driven by the Product Manager during product development. The key activity during this phase is to conduct weekly or periodic review meetings with Program Manager to ensure that the program is on track without any delays. In case of any delays caused by delay in development or delay in supply of HW/SW components by the vendor etc, Program Manager will outline the impact to the release timelines. Product Manager has to figure out the risk due to delay in releasing the product and immediately draft a mitigation plan. Even though

Activity checklist

There are lots of activities that are either tracked or performed by the Product Manager during product development phase to ensure the timely release of the new product and it would only get worse if the release gets jeopardized because Product Manger misses to complete at least one of those activities. So preparing a checklist and periodically reviewing the progress is critical. The checklist should pre-dominantly contain the list of items driven exclusively by the Product Manager. I have listed down the basic set of activities common for any new product development, especially HW products

  • Product price
  • Support cost
  • Ordering
  • Creating part numbers
  • GTM plans
    • Marketing collateral
  • ….

The above listed activities might not be exhaustive and the idea is to ensure that the Product Manager drafts an exhaustive list of activities in the form of a checklist, so he does not miss any activity. I would not shy away from suggesting to take some cues from Program Manager on how to prepare an effective checklist. Program Managers are generally more adept at such tasks. Note of caution is to ensure that you and Program Manager do not duplicate the efforts of tracking the activities. At least from my experience, the earlier listed activities are exclusively driven by the Product Manager while Program Manager would focus on product development, supply chain, documentation, compliance, vendor finalization etc.

Know the process

Each organization has their own processes to complete the above activities. As a Product Manager, it is really critical to have a complete understanding of those processes including the timelines required to complete them. Always add 20%-25% buffer to the duration required to complete each activity. Later Product Manager has to figure out how many weeks before the 1st release do each of the earlier mentioned activities has to be completed. Backtrack from the target date to identify the start date. For instance if finalizing product cost takes 8 weeks and the activity has to be complete 4 weeks before the 1st release, then essentially the activity has to be started 14 weeks before the 1st release (4 + 8 + 25% of 8). Also try to understand the dependencies between each activity and plan accordingly. For instance, creating part numbers, product cost and ordering are mostly inter-related items. For instance product cost could not be derived and recorded without part number. Ordering could not be enabled without pricing and part numbers.

It might sound simple, but in most cases Product Manager fails to ascertain the time taken to complete each activity and it happens primarily because of the lack of knowledge about internal processes. New product development is not everyday activity, so it is imperative for any Product Manager to undergo quick training on the list of processes involved in new product planning and development.


The most important premise during pricing phase is to optimally price the product so Product Manager does not leave any money on the table and Product Manager monetizes the product in much more effective way. There are various kinds of pricing (cost-based, value-based) pricing. The exact methodology depends on the nature of the product and market conditions, but irrespective of the methodology, for pricing review it is always best to have some reference point so Product Manager could justify the price point. In case of product being introduced in new category, price of perceived alternate product should be considered as reference point.

In case of cost based pricing, the price of the components used in the product will come down after reaching certain volumes or after specific time period. In such case, would the strategy be to price the product higher initially and lower the price later to retain the same margins or have thin margins initially to drive volumes and compensate for the lost margins little later. There is also an aspect of product life time that will determine the product price as well. Another aspect to note in pricing of B2B products is ‘Discounts’. Is discounting the product a norm and customers always seek higher discount irrespective of the final price, then it is always suggested to price the product higher and later provide higher discounts

In case of value pricing, I would just pick the cost based pricing and add standard margin. Later understand the exact value delivered by the product in tangible terms to the customer, does it save customer money or help them generate revenue, Product Manager has to add % of that tangible value to the cost based pricing and derive the final pricing.

In case of xAAS model, primary aspect is to identify the pricing strategies (consumption model, term/perpetual license, freemium, tiered model) and secondary aspect is to understand infrastructure required to implement xAAS pricing model. There should be mechanism to track licenses purchased by the customer and validate whether customer is using the product or services in accordance with the license agreement. xAAS pricing model should be simple and measurable.

Pricing by itself is a bigger topic, I just outlined the thoughts based on my experiences and there is no right or wrong way to derive the pricing. End of the day what matters is that whether product is recovering the cost and making sufficient margins without leaving any money on the table. Pricing has to be looked alongside the business model of the product as well. Business model primarily outlines how to capture value. Another aspect to consider is total cost of ownership, while the product might be affordable the total cost of ownership might be too high for customers to afford. For instance, the service cost and spare parts of the cars can be higher or in a B2B product the support cost, training cost will be higher.

Price will always be directly proportional to a specific attribute(s) of a product. Before Product Manager starts pricing exercise, he has to ensure that those attributes does not change in the completely built product. For instance, the price of hard disk is directly proportional to its storage capacity and RW speeds etc. Sometimes Product Manager don’t get the pricing correct, it is better have some mechanisms to evaluate the efficacy of the pricing and allow room for any changes even after the product is released.

GTM activities

Putting aside the range of GTM activities, Product Manager need to look at the primary purpose of GTM. The primary purpose of GTM is to effectively communicate product value proposition to the target customers in a more optimal way. Communicating the value proposition is not about creating a booklet but about the ability to tweet the value proposition effectively to target audience. Any product essentially does lot many things and it is appropriate to list them in a product booklet and it is not wise to dump all the information to customer during initial messaging. Product defining attributes outlined during product requirement phase would come handy to formulate an effective value proposition messaging. The messaging should definitely strike a chord with the target audience and should raise the curiosity factor; otherwise Product Manager has failed miserably. Probably Product Manager has failed much earlier while drafting the defining attributes. If those defining attributes are neither striking a chord nor raising a curiosity factor, then customer is not valuing those attributes and the success of the product is really at stake.

Next step is to identify the list of mediums (social media, events, blog or traditional methodologies such as print or TV) through which target audience could be reached. In order to determine which methodology is more effective, identify the cost and penetration rate (ie what % of your target audience could be reached) to rank the mediums based on their effectiveness to reach target audience. In case of budget constraints and the initial estimated budget for GTM was not allocated, simply apply 80:20 rule (20% of your budget should help you reach 80% of your target audience). Ranking process of mediums can help Product Managers implement 80:20 rule to effectively and efficiently communicate product value proposition.

Final activity is to decide the timeline to start communicating the value proposition of the product and through which medium. The timeline purely depends on the exact strategy, for instance in certain cases there is a need for suspense factor and the details about the product would be revealed just few weeks before the launch (eg iPhone). In other cases (mostly B2B products), the suspense factor will be counter-productive and therefore the information would be let out in bits and pieces pretty earlier to create a curiosity factor. I said ‘bits and pieces’ because if the communication is started during the product development and most probably some of the details would be missing. If AIRBUS is building a plane that can go longer distance non-stop consuming less fuel, even though Product Managers would have provided some benchmark numbers for distance and fuel savings, it is not wise to communicate the actual data without testing the completely build product. So Product Manager will start messaging that a new plane being built will travel longer distance while consuming less fuel, initial messaging will not shed any more information on exact distance and fuel savings. The precise idea is to create enough buzz about the product while effectively communicating the value proposition.

All those messaging activities through various mediums have to finally converge in a big launch event for the product inviting the PR, customers and other stake holders. Probably the number of events would depend on the budget and geographic spread of the target audience.

I consider messaging to be primary constituent of the GTM activities, but there are also bunch of other activities including product training (to channel partners, sales team etc), product pages, support document, product images, launch plans etc. Product Manager alone would not be able to drive all of them, but he has to draft a plan outlining the activities and who will be in-charge for those activities and timeline to start and completion of each of the activities.

Whole product approach

Product Manager need take a look at the entire sale process and understand what factors would influence the sale process. Product capabilities alone would not influence the entire sale, there would be other parameters such as reputation of the company, quality of post-sales service, availability of support, reference customers, availability of trained engineers (for B2B products) etc. Whole product approach is to list such factors that are critical for a sale and plan to fulfill them.

The big ticket item of whole product approach is to outline the plan for product ecosystem that was elaborated in ‘Detailed requirements gathering – PRD’ section. If the new product has to spur an entirely new product ecosystem, then Product Managers has to sweat a lot to create a proper ecosystem that would fuel the success of the new product. Another aspect to consider is that the elements of whole product vary as the product evolves through various stages of technology adaption life cycle (describer by Geoffrey Moore). The decision making process of the early adapters are not same as early majority. The early adapters might consider product capabilities as the key deciding factor in the buying process, they are curious to explore new products without worrying about the existence of support, product guides etc. New technology excites them more than anyone else. Whereas early majority might consider good product reviews, existence of support etc in addition to product capabilities as the key deciding factor in the buying process.

Final Word: Product development is lengthiest phase and during this phase Product Manager handles umpteen activities for successful release of the product. Considering that 25% of the products get killed during development, PM has to exhibit attention to details and meticulous planning during this phase. Otherwise product development might go terribly wrong.