Is MVP a trap or are we abusing it too much?

Any development methodology has its own fallacies unless we appropriately use them. With MVP too, we have to be cautious not to fall into a trap of probably relying on it too much (or rather should I say abusing it). MVP (Minimum Viable Product) formulated by Eric Ries is an excellent way to build a product through an incremental process of build, measure and learn. Nevertheless, it does not entitle Product Managers to learn and validate every aspect of product requirements through MVP alone. When it gets difficult for a Product Manager to discover and comprehend customer requirements, the easy way is to put emphasis on MVP. If we start validating every requirement of a 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 every incremental version of the new product thoroughly. While building complex products for enterprise customers, it is always crucial for Product Managers to do extensive customer research for obtaining deeper customer insights and balance those findings with MVP without completely hiding under the veil of MVP and Agile.


Trap 1 (MVP is not one-size-fits-all): The efficacy of any development methodology (Agile or MVP) lay in realizing the true purpose of those development methodologies. Not knowing when to use those methodologies and how to use those methodologies will lead to utter chaos and inefficiency. Eric Reis devised MVP as a methodology because of uncertainty in markets, customer behaviors and their expectations leading to product failures. Because of uncertainty, Product Managers fail to build new products for right needs and for right customers. For eliminating uncertainties through validated learning, Product Manager could leverage MVP for incrementally building the new product in a cycle of build, measure and learn with a primary motivation to validate whether the new product is addressing the right needs, for right customers and as desired by those right customers. However, not every new product caters to uncertain markets. Certain products are conceived for predictable markets with predictable needs incorporating already a proven technology.

In a scenario where competitors are crawling everywhere and there are analysts to provide any information about the need addressed by the new product or about the market targeted by the new product, Product Manager should leverage those details to build better insights about customers and market. What makes certain insights more meaningful is the ability of Product Manager for always reading between the lines to understand what had worked and what had not worked. Product Manager would later augment those insights to define the necessity for MVP and identify what unknowns will be resolved through MVP. MVP cannot be an excuse for lack of insights about customers and markets, MVP should only complement already existing information to obtain better insights. Now, this leads to the second trap, how much to validate and learn?


Trap 2 (Validating too much for too long)
Validating too many hypotheses will unnecessarily delay the development cycles risking the possibility of any competitor with better knowledge of customers and market go past the new product. For every hypothesis, Product Manager should ponder whether it is essential to validate the hypothesis directly with customers or is it possible to validate it based on customer insights. Product Manager by virtue of interfacing with customers, being part of the industry for a longer period should have developed some insights about customers, markets, and technology. Such insights should be useful for conceiving the product. I am in favor of lean practices but not in favor validating every element of the new product with customers. The right balance is required to validate the most critical elements of the new product while maximizing validated learning and minimizing efforts. However, Product Managers often do the contrary.


Trap 3 (Maximum efforts, minimal learning): After optimizing the number of hypotheses to validate, Product Manager has to identify the most optimal ways to validate them. Building a minimal version of the new product might not always be the best answers for validating learning. Dropbox founders validated their idea by building a video because building a minimal product consumes time and any change in the expected behavior of customers requires Dropbox team to alter the product architecture making it costlier and time-consuming. Ideally, Product Manager should follow lean practices even for picking the number of hypotheses to validate, how to validate those hypotheses and how long to validate those hypotheses. Time should be a major consideration while adapting MVP methodology. In the words of Eric Reis

A minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

True to those words, MVP is about achieving maximum learning with most optimal efforts.


Trap 4 (Delivering with little value): Another trap is the risk of alienating customers especially when the new product addresses a need already addressed by competing products. In such scenarios, minimal version of the product that delivers the same value as existing products already in the market might not excite customers and Product Manager risks alienating customers even though there are explicit disclaimers that the product is a minimal version. MVP sometimes should provide a hint of what is in store for customers and it should excite customers just as a movie trailer captures the attention of its audience providing a sneak preview of the entire movie.

If the new product is another LinkedIn, Gmail or Salesforce, what could be the MVP version of the new product that might excite prospective customers? New Product, which might be a replica of an existing product, should deliver new value or deliver same value as the existing product in a unique way. Otherwise, the commercial success of the new product is questionable. Therefore, as part of MVP, Product Manager should validate the unique value delivered by the new product to verify whether it is a real differentiator. Doing so, MVP will provide a preview of the product differentiators that could excite early adapters. MVP while helping Product Manager validate the efficacy of the product in addressing a need uniquely should also excite prospective early adopters to buy the product.


Trap 5 (Not choosing right customers): Another crucial element for MVP is to choose the right set of customers. Always target customers who would be could be potential early adopters. In addition, the chosen set of customers should share the same passion for the new product as the Product Manager does. Few section of customers get excited about breakthrough products embracing new technology, few other customers want to be delighted with minimal intervention. The later set of customers hate when new the product uses their business environment as a trial ground.

MVP is a double-edged sword. While customers help Product Manager perform validated learning to pivot or preserve product development, customers will also throw feedback for further evolving the product. Product Manager is obliged to honor such requests after validating the fit with the overall strategy of the product. Therefore, it augurs well to focus on a specific target segment that are potential adopters of the new product ensuring that their needs are addressed and the product is out on the market as quickly as possible. Doing so, Product Manager can also avoid the problem of diverse feedback from MVP customers. In a B2B segment, I always prefer picking customers who can generate revenue in first two quarters of releasing the product. A certain section of customers do not generate immediate revenue but provides sufficient infrastructure to validate the product (early innovators).

Not every customer is very vocal about sharing feedback. The right way to perform validating learning is to observe customers using the new product. Never really rely on what customers actually say, what they often say is not what they actually intend. For true validated learning, rely on customer behaviors, body language, and usage patterns. There is a cultural aspect to feedback sharing, not every culture embrace the quality of calling spade a spade. Therefore, I loathe feedback forms, user group interviews etc.


We often follow a herd mentality and blindly adopt the widely used development methodologies. Instead, we should understand the true purpose of any methodologies and adapt it for the value they deliver and not for its popularity or for its wider acceptance among the fraternity. I appreciate your thoughts or rather contrary views on MVP traps specifically for enterprise products.

The focus of this blog is to specifically highlight the MVP challenges for enterprise products. In my previous blog post – Moving target of customers’ needs – A unendorsed challenge of building enterprise products, I have explicitly highlighted the challenges of MVP in building enterprise products. 


Building New Product – Experiences of a Product Manager (free eBook)

I am glad to end 2016 with the completion of the 3rd edition of my eBook – ‘Building New Product – Experiences of a Product Manager’. I released 1st edition of the eBook towards the end of 2014. Ever since, I did a critical review of my work to check whether I had provided enough information in my eBook, accordingly evolved it into 3rd edition. I did so, by holistically reflecting on my experiences of building the new product not just by introspecting what I did better but also being critical about where did I go wrong and what I could have done better. I leveraged those insights to provide more actionable information on how to build a great product that is:

  • Built on a foundation of strong product vision that ultimately defines the purpose and objective (WHY?) behind the new product.
  • Built in alignment with real needs of real customers and as desired by those real customers.
  • Built not just for needs of today but for needs of tomorrow.
  • Built with all essential attributes that drive customer preferences towards the new product.
  • Built with a focus on doing one thing (that drives customer preference) awesomely right instead of doing everything right.
  • Built with a basic premise of think bold, think future unconstrained by any limitations.

I really appreciate if you could take a look and drop your thoughts or comments.

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

You can find the download copy of the eBook at


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.

Building new product – My experiences (Part IV – Planning Phase)

This blog post is continuation of my earlier blogs related to ‘New Product Development – My Experiences’. Next in the series, i would talk about actual ‘Product Development’ and ‘Essential traits of PM for success of NPD’.

Product planning phase is very critical phase in the entire product development for two simple reasons

  1. Business plan is evolved to derive more precise details about development cost, timeline etc. So Product Manager could essentially validate the financial viability of developing new product once again in this phase
  2. Program Manager drafts a detailed and elaborate development plan to ensure that the product is built on time with required specification and within the budgeted cost.

Freeze product specifications

First and foremost task in ‘Product planning’ phase is to freeze the list of features that would constitute new product. PRD contains an exhaustive list of requirements. Considering TTM (Time to Market) and constraints of engineering resources, not all the features would make it to the final list. Even though PRD might provide some details on what features could be dropped for the 1st release by clearly marking the priority for each of the features, the task is not as simple as it might sound. It involves lots of tough decisions, negotiations, trade-offs. In case of B2B products, it takes time to stabilize and peak the revenues. So more often quicker TTM would be preferable, so trade-off need not necessarily be feature1 vs feature2 but also between later TTM (with feature1/feature2) vs early TTM (without feature1/feature2). The defining attributes would also provide some directions for trade-offs. For instance if the defining attributes is ease of use and reliability, then Product Manager cannot afford to miss the features that contribute to those defining factors. Instead Product Manager could compromise on other aspects like higher performance in 1st release and focus on the same in subsequent release. The final list of features has to be ultimately approved by the Product Manager and he has to be sure that the frozen list of features along with the defining attributes would provide compelling reasons for customers to buy the product. Negotiations or persuasion skills are the need of the hour for the Product Manager to ensure that the right set of features makes it to the final list.

Evolve the business plan

Program Manager has to evolve the business plan to provide granular information on the following critical items drafted at a high level in the business plan:

  • What is the total cost incurred to develop new product(s)?
  • Detailed product development plans and various dependencies
  • What is the release date for the new product?
    • In case of multiple products, the focus should purely be on the 1st product to be developed
    • In case of multiple products, the focus should be predominantly on how either existing or new platform will be leveraged to build the subsequent product(s) with lesser cost and quicker TTM

While drafting business plan, we would be only deriving a high level ballpark estimate (typically a birds view) for the above items and only during product planning phase Program Manager will outline detailed plans and alert if there is any major deviations from the business plan. For instance if the timeline or the project cost or the total resources estimated during product planning widely varies from the business plan. Moreover the objective of business plan is to ensure that the new product development is viable financially and very less would have been discussed about details of actual product development. So during business review we don’t involve too many stake holders who do not directly contribute to the estimation of product development but will play a key role in areas such as documentation, compliance, manufacturing and supply chain etc.

Meticulous planning of new product development

During planning phase, program manager has to involve all the stake holders and draft a detailed plan not only for the development of the product but also for other allied activities such as documentation, compliance, royalty, intellectual property (if any), supply chain, vendor finalization etc. The Program Manager has to derive a meticulous plan for the development of the product, so any deviations or surprises could be caught much earlier in the product development cycle. Another critical aspect of planning phase is to identify all possible risks (budgeting, vendor management, product performance etc) and assumptions. Program Manager has to outline the time frame to eliminate or mitigate the risks and validate assumptions, preferably the time frame has to be pretty early in the product development cycle so in the event of any major surprises there will be sufficient to time to implement mitigation plans.

Vendor finalization and some of the other activities covered under product planning might take longer duration, so those activities need not essentially start after PRD completion. It can be a parallel activity along with PRD preparation but entire plan for those activities would be frozen and derived post the completion of PRD during product planning phase.

Product feasibility validation

I spoke about ‘RISKS’ in earlier section under ‘Meticulous planning of new product development’, the biggest risk is the inability to build the product as envisioned initially. In such case, Product Manager has to ruthlessly kill the product instead of selling the product that does not meet the customer requirements. Here I am only focusing on how quickly Product Manager could decide to KILL the product without consuming too many resources in case of inability to build product as conceived. During ideation process Product Manager will validate whether the product to be built can meet the customer requirements and sizable amount of customers would buy the product to make sufficient margins. But Product Manager also needs to evaluate whether the development team could built the product as conceived initially. During business review, development team will do high-level feasibility analysis and provide some amount of confidence that product could be built as envisioned or conceptualized. However product development is invariably prone to surprises and several products were killed or abandoned before the launch because of the inability to develop the product as envisioned and it happens mostly in case of adapting new technology or building new product distinct from the traditional competencies of the organization. In such cases chances of failure is high, but what I am insisting here is that the Program Manager need to draft plans to validate the feasibility or ability to build the product as quickly as possible and abandon such product before burning too much money. Suppose if AIRBUS is conceptualizing to build a plane that can travel longer, it would not be wise for the development team to assert that they will never knew how long can the flight fly non-stop until it is completely built, probably there would be some simulations tools that can help make some decision even before the complete product is built. Program Manager along with the development team need to figure out such methodology so the amount of money that needs to be burnt will be very minimal.

Business review to justify product development

Since we would have done a detailed blue print for the product development during this phase, it would be wise to perform a business review once again to ensure that the product development is justifiable. During the business review Program Manager has to outline possible risks, potential delays, development cost (inclusive of engineers, HW, SW etc required to develop new product), release dates and timelines for early customer trials. Intermediate milestone dates to validate the progress of the product and to conduct intermediate demos to internal stakeholders would also be listed during the review.

Final Word: ‘Well planned is half done’, Program Manager should etch a plan that captures lots of minor details diminishing surprises during the course of product development and thereby triggering flawless execution of new product development without major deviations.

Building new proudct – My experiences (Part III – Importance of a monitoring plan)

In this blog post, i am specifically focusing on the importance of monitoring plan in ‘New Product Development’

While conceptualizing new product, we always make assumptions based on both quantitative and qualitative analysis on the following

  • Total addressable market and growth rate
  • Customer value proposition and differentiation
  • Competitive analysis

 The monitoring plan is to constantly revisit the above items and ensure they are intact by trying to figure out the answers for the following queries

  • Is it still a growing market – Any socio-economic/ regulatory or any other macro factors has stalled the growth
  • Is customer preferences still the same
  • Is competition launching better product(s) ahead of us or planning for new product launch.

Keep a tab on macro factors

Product development is a long term process and it would be insane on the part of Product Manager to assume that none of the macro factors impacting the product (either directly or indirectly) changes during the phase of product development. So evaluating the macro factors constantly is a MUST. In case of pure-academic talk, I am referring something similar to PEST analysis but focusing on other relevant parameters such as ‘R’egulatory, ‘E’nvironment etc. Product Manager has to periodically assess all the macro factors and diligently ascertain the impact of any of those changes on the success of new product.

Here I am focusing on the factors that we don’t control either directly or indirectly but it impacts how our products are built or received in the market. So it only makes sense to keep watch on them and ensure that our assumptions are still valid. Any changes require conscious effort to relook at the entire product development plan.

Oh….PMs get emotionally attached to the new product, can they?

The success of this phase lies in the ability of the Product Managers to take rationale decisions based on the outcome of the monitoring phase analysis. But often Product Manager gets emotionally attached to the new product and it would be tough to take some extreme measures like killing the product even before the launch. For instance, a new regulation makes the product unlikely to sell after couple of years. In such case, if the decision is to kill the product because building the product for couple of years is not viable financially, then Product Manager have to promptly take the call and derive a product exit strategy. New product development is always exciting, while Product Managers have to be passionate about building products they should not get emotionally attached to it.

If you wondering about the monitoring plan to track the development schedule, development cost etc, those items will be monitored by the Program Manager during product development phase while plan will be outlined in the product planning phase. I will talk about the product planning in my subsequent blog post.

Final Word: Excitement of new product development should not steer the Product Manager away from ground realities and when macro factors do change there should be conscious effort to introspect whether new product will succeed.