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.

Building new product – My experience (Part II – Drafting requirements)

This blog is a 2nd part in a series of blog post on ‘New product development – My experiences’. The focus of this blog is purely on new product requirements

Requirements gathering – PRD

Once new product development is approved, next plan is to draft the detailed product requirements in the form of PRD. PRD should start with justification for new product – So borrow details from business case 🙂

  • Why customers need new product(s)?
  • How does the customer requirements will evolve in future?
    • Very critical to laying a foundation for flexible product architecture or platform
  • What are the key value propositions valued most by customer?
  • What are targeted vectors of differentiation?

The above responses would help Product Manager to outline broader requirements for new product architecture. IMO, Product Managers should be aware of the product architecture and in any new product development should play a key role in finalizing the architecture. While architect team would design the architecture, Product Managers should act as a guiding force in deriving the architecture.

Elaborate ‘Defining attributes’ of the new product

PM has to elaborate in PRD about the defining attributes mentioned during business review. The defining attributes of the product should act as guiding principle for the engineering team and other stake holders involved in the product development. PRD will focus on 2 primary aspects

  1. ‘What’ are the features that constitute new products
  2. ‘Why’ those features are required – The actual purpose and how customer might use those features

Engineering will later focus on ‘How’ to develop those features. While developing the features, defining attributes (such as simplicity, ease of use, reliability or higher performance) would determine how those features are built. For the same reasons, it is critical to determine the defining attributes of the product and list them in the early sections of the PRD before formulating the feature requirements. Defining attributes would also determine the choice of components procured from vendors, so it is vital that every stake holder involved in the development of the products shares a common understanding of the defining attributes.

Drafting requirements and framing MVP list

Next level is to go deeper into specific capabilities of the product. At least in my scenario, the focus is on the extension of existing product line. So I have put my attention on 4 important things

  • Do any of the existing functionalities have to be eliminated?
  • Is there a need to bring-in any new functionality or new technology to align with customer value proposition and differentiation?
  • Do any of the existing functionalities have to be altered to increase the scope or make it better usable?
  • Synergies between old and new products

Add granular feature requirements in PRD and list the priorities for each of those features as it helps in decision making while determining the trade-off between release timelines and product features. We do always have conflicting priorities such as early TTM of product packed with lots of features. So here comes the topic of minimum viable product that could still fetch revenues forecasted in RoI calculations while targeting early TTM. All features that constitute minimum viable product should be tagged appropriately in the PRD.

Deriving synergies between old and new products

It is also imperative to list down the synergies between old and new products. If the new product is an extension of the existing product line and even though it might be built on a totally new platform, Product Managers should outline if there needs to be any synergies between old and new products. Essentially, the majority of the target customers for new product would be the existing customers of older products and it is imperative to take their inputs/requirements/needs into consideration. All the existing customers invariably will look for easy migration from existing devices to newer devices keeping the switching costs really low. Moreover none of the customers would be willing to invest heavily in learning the new product, so the learning curve should be minimal. Product Manager has to capture those requirements in the PRD and later during product planning phase development team would outline how the synergies could be derived.

Finally, ‘Whole product approach’

The last section of the PRD would talk about ‘Whole product approach’. Whole product approach focuses on elements (both tangible and intangible) enabling the core products sell better. PRD should list high level plans for the following

  • Technical support
  • Partner training
  • Product documentation
  • Compliance requirements
  • Sales or distribution channel support

In addition GTM plans (collaterals, PR, launch plans) would also be listed in the PRD. Ironically, ‘Whole Product Approach’ is given least importance in comparison with the actual product. As part of the ‘Whole Product Approach’ we might also have to consider ‘Product Ecosystem’. ‘Product Ecosystem’, according to me is a culmination of multiple players contributing jointly to the success of the ecosystem and the conduciveness of the ecosystem is essential to success of all the players of the ecosystem. However the value rendered by each of the players to the ecosystem will not be identical.

From the perspective of ecosystem, products would be broadly classified under 2 categories

  1. Products that drive the ecosystem – Products that are at the center of the ecosystem and it is instrumental in creating the entire ecosystem

For instance Smartphone OS (iOS, Android) that created an entire eco-system of apps

  1. Products that thrive on the ecosystem – Products that are at the periphery of the ecosystem and significantly contributes to the strengthening of the ecosystem

Even though apps thrive on the ecosystem, their existence strengthens the ecosystem
Both are complementary, existence of apps is critical to success of the apps ecosystem and stronger app ecosystem contributes to the success of apps

If the new product belongs to category (i), then PRD should outline the initiatives to create such an ecosystem. In case of product belonging to category (ii), we need to outline the dependency in the PRD, outline the plan to monitor the evolution of the ecosystem under ‘Monitor Plan’ and outline the risks associated in the ‘Product Planning Phase’. Both ‘Monitor Plan’ and ‘Product Planning Phase’ are elaborated in subsequent blog posts.

Importance of PRD

For me, PRD is a BIBLE to product development and it should act as one stop reference guide for engineers to build the new product. The requirements in the PRD should be exhaustive, but the focus should be only on ‘What’ and ‘Why’ as stated earlier. I will drop a scenario

  1. What – Smartphone requires front camera
  2. Why – For selfie, video calls etc

Probably PRD would not define the specifications for the camera, however ‘What’ and ‘Why’ would set the scope of the feature and it should tickle creative minds of the engineers to formulate the ‘How’. Doing so, the product developed would be aligned to meet the exact purpose. Just like movie scripts enables the actors to visualize the movie, PRD should provide such visualization of the new product.

I recently came across this article ( and was appalled to find that only ~15% of the Product Managers provide right level of details and actionable requirement. Providing right level of details for all the product requirements is one of the single most important responsibility of PM, unless the requirements are actionable and unambiguous, the final product might not be the same as the product envisioned during business review.

PMs should truly demonstrate technical leadership

While drafting PRD, discussing requirements, finalizing product architecture or formulating platform strategy, PM has to demonstrate superior technical leadership, great depth of market/competitive knowledge to quickly gain the trust of the development team. Otherwise it is tough to reach consensus on the vision of the new product and the development team might not believe in the vision of the Product Manager and the product. Even though it is a cliché, I have to re-iterate that PM has no real authority or power. So mutual respect, trust and admiration is the key to influence other stake holders and sell the vision of the new product. Mutual respect, trust and admiration are not formed by our position or authority but by our actions, thoughts and deeds. It might take some time to forge such relationship but once built it will only fuel more product success stories.

Final Word:  Every single feature of the product should have the requirements originated from the PRD and it should have the approval of PM. I am not trying to ascertain the authority of the Product Manager, I am only insisting that Product Manager alone would have absolute clarity on what set of features would facilitate new product to make $$$.

Building new product – My experiences (Part I – Business Review)

After the new product idea is formulated, Product Manager has to start drafting a strong business case that would highlight the need for new product and justify it financially by providing appropriate RoI. In some cases, RoI alone cannot be a deciding factor if the new product is of strategic importance to retain customers and cross sell other products. In order to provide compelling reasons to the senior management to invest in the new product, I tried to draft the queries under 4 broader categories (Market Analysis, Product Analysis, Competitive Analysis and Financial Analysis) and started framing responses to those questions in the form of PPT. Queries is a nice form of formulating and streamlining your thoughts, so wherever possible I would adapt the strategy of first formulating the queries and later try responding to them. Doing so, I first position myself in the role of the reviewer while drafting the queries and start responding to them as a Product Manager. Please note that the business case is a collaborative effort along with account managers, sales team, BDMs, engineering, analysts etc.

Market Analysis:

  • Is it growing market?
  • What is the potential impact of not having new product(s)?
  • What is the total addressable market?
  • Where is the current product positioned in the product life cycle?

Product Analysis:

  • What are the high level specifications of new product(s)?
  • What is the defining attributes of the new product?
  • What is the platform and product line strategy? Are we leveraging existing platform or creating newer platform?
  • What is the total cost incurred to develop new product(s)?
  • Make or buy decision?
    • If make?
      • What is the competence required to build new product(s)?
      • Do we have such competency or does it has to be acquired?
      • What is the timeline to develop new product?
    • If buy?
      • Are their potential vendors to acquire?
      • How much does it cost to acquire?
    • What is the release date for the new product(s)?
      • In case of multiple products, outline the product line strategy along with release dates for each of the product
      • In case of multiple products, outlining a single platform strategy for all the product would be more ideal

Competitive Analysis:

  • How would new product(s) be positioned against competition? What would be vector of differentiation of new product(s)?
  • How the competition is currently positioned?
  • Are we imbibing any new technology into the new product(s)?
  • How potentially could competitive landscape change before the new product is released?

Financial Analysis:

  • What is the ROI of the new product(s)? How much revenues could be forecasted by new product(s)?

The above queries would definitely provide a holistic view of what needs to be considered while preparing a business case irrespective of whether it is a HW or SW product. It gives directions and guidelines to prepare an effective business case. Subsequent section focuses in detail on each of the above items.

Market Analysis

  • Is it growing market?

Analysts can provide precise information on whether the market is stagnated or growing. If growing, what is the CAGR? Growing market alone is not a sufficient reason to invest, unless the new product would have all the required ingredients to capture the growth. Product capabilities would be addressed as part of product analysis. But product capabilities alone cannot capture the market; we need to understand the segment contributing to the growth and how are we positioned to capture that segment. Probably if segment contributing to the growth is not the traditional customer base of the product line, then Product Manager need to outline a plan to position the product effectively and sell the product to that segment. Please take a look at my previous blog for more details Attacking White Space – Identifying Growth Opportunities

  • What is the potential impact of not having new product(s)?

In case of adding new product to the existing product line, it is critical to outline the impact of not developing new products. So management is aware of the negative impact, please note that both tangible and non-tangible impact should be outlined. Firstly outline the revenue impact to the existing product line, more often customers don’t invest if the product line is not evolving. Secondly outline the non-tangible impact of losing the customer base on the other products (different from existing product line under discussion)

  • What is the total addressable market?

Along with the growing market, size of the market is critical because market attractiveness is not universal and it might vary with overall size of the organization. For some companies $100M market might be attractive while for other companies anything less than $1B is not attractive. So understanding of your companies priorities is critical.

  • Where is the current product positioned in the product life cycle?

This would highlight the urgency to develop new product depending on the positioning of the product in the product life cycle, so management could understand how quickly the new product decision has to be made.

Product Analysis

  • What are the high level specifications of new product(s)?

High level product specifications has to be derived taking into consideration both market and customer requirements. Please take a look at my related earlier blog posts
Requirements has to be understood, not queried – It is very important not to ask customers to draft the product specifications, instead engage in conversations on how their business might evolve and what problems they might probably anticipate. The blog provides more details on understanding customer requirements.
Market focus vs Customer focus – New product is all about addressing future problems, so it is essential to take a look at how market will evolve, what trends are critical and how they will shape the requirements of the target segment.

  • What is the defining attributes of the new product?

There should be one or two defining attributes that should be aligned with product differentiation outlined under ‘Competitive Analysis’. The defining attributes can be as simple as one or some of the following

  • Cost effective
  • Best performance
  • Feature packed
  • Highly intuitive and user friendly etc

The defining attributes are required for two simple reasons

  1. It helps in constant messaging of the value proposition of the product both within and outside the organization
  2. It would also act as a guiding force while making decisions or trade-offs regarding product features. In case of cost effectiveness, we might opt for a lean team and cost effective components may be compromising on performance but not on quality
  • What is the platform strategy? Are we leveraging existing platform or creating newer platform?

Depending on the high level requirements of the product, value proposition and competitive positioning (will be elaborated later), the architect team has to outline whether the new product(s) could be built on existing platform or new platform has to be developed. In case of new platform, Product Manager has to be deeply involved in the design/decision of new platform to ensure that the new platform will lay a perfect foundation for all the upcoming products in the product line.
Effective platform strategy provides the capabilities to create a product line by reducing cost (both development and maintenance) and TTM (Time to Market), while ensuring consistent value proposition, differentiation across different products in a product line.

  • What is the total cost incurred to develop new product(s)?

High level cost estimation to develop the product has to be estimated, it involves engineering cost and cost of equipment(s) required for development. COGs of the new product also have to be estimated to derive profit margins during ROI estimation.

  • Make or buy decision?
    • If make?
      • What is the competence required to build new product(s)?
      • Do we have such competency or does it has to be acquired?
      • What is the timeline to develop new product and how potentially could competitive landscape change during this period
    • If buy?
      • Are their potential vendors to acquire?
      • How much does it cost to acquire?

In case of existing product almost in sunset mode and the urgency to launch new product is really high, then probably buy decision would make sense. In case of buy, I am referring to acquisition. I am not a big expert of the decision process involved in acquisition, so I will probably focus on either completely make or partial make/buy.

First and foremost, we need to understand the list of components (both SW and HW) required to build the new product. Later we can assess whether in-house competencies exists to build those components (both SW and HW). During business review, we only make high level assessment and if some of the components (either HW or SW) are to be acquired from external vendors, we derive the possible vendors and approximate cost to acquire those components. Decision to buy can be based on various parameters such availability of in-house competencies, cost to develop, time to develop etc. IMO, the guiding principle for make or buy decision is that all the core components contributing to the value proposition should be built in-house, otherwise you will face troubles with differentiating the product.

  • What is the release date for the new product(s)?

In case of multiple products, Product Manager has to draft product line strategy to list the delivery timelines for each product in the product line in alignment with the market and customer expectations

Competitive Analysis

  • How the competition is currently positioned?

Asses the current position of the competitors from the perspective of their revenue potential and market share. What products do they sell currently and what are their specifications. What are their strengths and weakness (evaluate both product and non-product attributes). In case of non-product attributes, I am referring to items such as support, distribution channel, partners etc. Please note that technical strength of the product alone cannot win a deal, so evaluating strengths and weakness from the perspective of non-product attributes is critical.

  • How would new product(s) be positioned against competition? What would be vector of differentiation of new product(s)?

Based on the analysis done earlier, Product Managers have to carefully derive the unique value proposition that can provide the confidence that new product can make the money and the efforts to build it were absolutely justifiable. Since it is a new product in the existing product line, we can also validate our findings by sharing them with your top customers who can be your potential early adaptors.

Quick analysis of how competitor might react to the new product development plans has to be analyzed, it would be really dumb if we hope that we will develop the product and capture the market while competition would sit idle. Basically the idea is to outline to the Sr. Management on how new product will succeed against competition when it is shipped to the market.

  • Are we imbibing any new technology into the new product(s)?

To support the vector of differentiation, Product Managers along with architect team has to evaluate whether any new technology has to be introduced. Several products fail because of the inability to integrate new technology, either the technology is not mature or the initial assessment of the technology has gone terribly wrong. In any case, the risk is higher and hence it is appropriate to explicitly list new technology introducing during business review.

Financial Analysis

  • What is the ROI of the new product(s)? How much revenues could be forecasted by new product(s)?

I believe it is a simple math, the development cost was derived earlier and based on the COGs, we can compute the break even and NPV for X years (no of years will be based on the product life time) based on approximate sales estimate. Each organization would have its own way of computing the ROI. But deriving the development cost, sales forecast for X years and COGs of the new product would be the main elements required to compute ROI. Irrespective of the price model (cost based, value based, xAAS) that would be adapted for the new product, for ROI calculation I would suggest to adapt simple cost based model (estimated product COGs + x% margin) to derive the breakeven and NPV. So we could keep the ROI calculations really simple.

The entire presentation to the Sr. Management should be like a story telling – It is growing market with huge potential and target segment contributing growth is X and their business needs are Y. Current competitors addressing the segment is A, B and C and the value proposition delivered by them are E, F and G. Our new product D with capabilities M and N etc can better address the requirements of target segment. I was just attempting to build an ‘Elevator Pitch’ for the new product.

Other non-tangible factors to take into consideration is whether our sales channels, delivery channels can effectively position and communicate the value of new product to the target segment X. It need not be elaborated in-detail during business review but worth mentioning, so we complete the entire story in a more convincing manner.

Final Word: New product cannot be a wishful thinking, Product Managers have to be doubly sure that the new product will make $$$ even before it is built and Product Managers do own the bigger responsibility for the success of new product.