Building New Product - Experiences of a Product Manager

2016 (3rd Edition)

Murali Erraguntala

www.ProductGuy.in

Page| 1

www.ProductGuy.in

Building New Product – My Experiences

Table of Contents

PREFACE ................................................................................................................................ 5

BUILDING NEW PRODUCT – MY EXPERIENCES ........................................................................ 7

IDEA VALIDATION .................................................................................................................. 9

TIMING NEW PRODUCT – WHY NOW? ................................................................................................ 11 PRODUCT-MARKET FIT - DESIRABILITY ................................................................................................ 14 PRODUCT FEASIBILITY ...................................................................................................................... 25 ESTIMATING MARKET SIZE ................................................................................................................ 26 PROFITABILITY – VIABILITY ............................................................................................................... 27 ORGANIZATION FIT ......................................................................................................................... 28 HIERARCHY OF NEEDS ...................................................................................................................... 28

IDEA VALIDATION PHASE CHECKLIST .................................................................................... 31

BUSINESS REVIEW ............................................................................................................... 33

MARKET ANALYSIS .......................................................................................................................... 34 PRODUCT ANALYSIS ........................................................................................................................ 37 COMPETITIVE ANALYSIS ................................................................................................................... 42 FINANCIAL ANALYSIS ....................................................................................................................... 43 BUSINESS PLAN DILEMMA ................................................................................................................ 44

BUSINESS REVIEW CHECKLIST .............................................................................................. 46

BUSINESS PITCH .................................................................................................................. 48

LAYOUT OF SLIDES .......................................................................................................................... 48 LEAN CANVAS – SUMMARIZE THE PLAN ............................................................................................... 49

NEW PRODUCT APPROVAL .................................................................................................. 51

1:1 EXECUTIVE BRIEFING .................................................................................................................. 52 HANDLE FEEDBACK POSITIVELY .......................................................................................................... 53 EXUDE CONFIDENCE ........................................................................................................................ 53 REFINE.. REFINE.. REFINE ................................................................................................................ 54 IDENTIFY INFLUENCER ...................................................................................................................... 54

WHAT DO YOU BELIEVE – DEFINES PURPOSE ....................................................................... 56

ORGANIZATION BELIEFS ................................................................................................................... 56 TRANSACTIONAL VS RELATIONAL ENGAGEMENT .................................................................................... 58 DID YOU FIND YOUR WHY? ............................................................................................................. 61 COMMITMENT AND CONVICTION ....................................................................................................... 62

DISCOVERING NEEDS – DRAFTING PRD ................................................................................ 64

Page| 2

www.ProductGuy.in


PURPOSE OF THE NEW PRODUCT – THE UNDERLYING BELIEF .................................................................... 64 REQUIREMENT VS NEED .................................................................................................................. 65 DISCOVERING VS UNDERSTANDING REQUIREMENTS .............................................................................. 66 BUILDING THE NEW PRODUCT FOR NEEDS OF TODAY AND TOMORROW ............................................... 66 DISCOVERY OF CUSTOMER FOCUSED NEEDS ......................................................................................... 77 DISCOVERY OF MARKET FOCUSED NEEDS ............................................................................................. 79 THINK BOLD, THINK FUTURE ............................................................................................................ 82 ELABORATE ‘DEFINING ATTRIBUTES’ OF THE NEW PRODUCT .................................................................... 84 DRAFTING REQUIREMENTS AND FRAMING MVP LIST ............................................................................. 85 DELIVERING SYNERGIES BETWEEN OLD AND NEW PRODUCTS ................................................................... 85 UNLEARN AND RELEARN .................................................................................................................. 86 HAZY MARKET – OBSCURE PRODUCT REQUIREMENTS ............................................................................ 87 CATCH-UP CONUNDRUM – DON’T BLINDLY CHASE COMPETITION ............................................................. 88 EVERY INCUMBENT PRODUCT IS VULNERABLE ....................................................................................... 90 PRODUCT/ SOLUTION HYPOTHESES .................................................................................................... 91 FINALLY, ‘WHOLE PRODUCT APPROACH’ ............................................................................................. 92 IMPORTANCE OF PRD ..................................................................................................................... 95 DISCOVERING NEEDS IS A JOURNEY ..................................................................................................... 96 ROLE OF GREAT PRODUCT ROADMAP - TRANSLATING STRATEGY INTO ACTION ............................................. 97 PRODUCT MANAGERS SHOULD TRULY DEMONSTRATE TECHNICAL LEADERSHIP ............................................ 99 DELIVERING AWESOMENESS – ALBEIT SELECTIVELY .............................................................................. 101

DRAFTING PRD CHECKLIST ................................................................................................. 105

MONITOR PLAN ................................................................................................................. 107

KEEP A TAB ON MACRO FACTORS ..................................................................................................... 107 OH…. PRODUCT MANAGERS GET EMOTIONALLY ATTACHED TO THE NEW PRODUCT, CAN THEY? ................... 108 PRODUCT ECOSYSTEM – IS IT READY? ............................................................................................... 109 PIPES VS PLATFORMS .................................................................................................................... 109 CONNECT THE DOTS ...................................................................................................................... 110

MONITOR PLAN ACTIVITY CHECKLIST ................................................................................. 111

PRODUCT PLANNING ......................................................................................................... 112

FORMULATE HYPOTHESES .............................................................................................................. 113 VENDOR/PARTNER SELECTION ........................................................................................................ 114 FREEZE PRODUCT REQUIREMENTS .................................................................................................... 117 METICULOUS PLANNING ................................................................................................................ 117 METRICS, METRICS, AND METRICS ................................................................................................... 118 PRODUCT ACCEPTANCE CRITERIA ..................................................................................................... 120 PRODUCT FEASIBILITY VALIDATION ................................................................................................... 120 EVOLVE THE BUSINESS PLAN ........................................................................................................... 121 FINALLY, BUSINESS REVIEW ............................................................................................................. 122

PRODUCT PLANNING CHECKLIST ........................................................................................ 124

Page| 3

www.ProductGuy.in


PRODUCT DEVELOPMENT .................................................................................................. 126

HIT THE GROUND ......................................................................................................................... 127 ACTIVITY CHECKLIST ...................................................................................................................... 128 KNOW THE PROCESS ..................................................................................................................... 129 PRICING ..................................................................................................................................... 129 GTM ACTIVITIES .......................................................................................................................... 131 WHOLE PRODUCT APPROACH ......................................................................................................... 134

PRODUCT DEVELOPMENT CHECKLIST ................................................................................. 136

MY EXPERIENCES - WHAT DID WE DO DIFFERENTLY ........................................................... 138

CONCEPTUAL VIEW ....................................................................................................................... 138 LOOK INTO THE FUTURE ................................................................................................................. 141 BEGIN WITH AN END IN MIND ......................................................................................................... 143 DATA-DRIVEN .............................................................................................................................. 146 ENGINEERING INTIMACY ................................................................................................................ 149 PLAN MY DAY – TOOK CONTROL OF MY TIME ..................................................................................... 152 ACT AND THINK LIKE A CUSTOMER .................................................................................................... 153 CROSS-POLLINATION OF AGILE AND WATERFALL .................................................................................. 155 LEAN (‘TAG ON’) MARKETING ......................................................................................................... 159 PATH TO BUILDING A GREAT PRODUCT .............................................................................................. 161

ESSENTIAL TRAITS OF PRODUCT MANAGER FOR SUCCESS OF NPD ..................................... 163

TECHNOLOGY AWARENESS, MARKET AWARENESS, AND CUSTOMER AWARENESS ...................................... 164 EMBRACE TOUGH DECISIONS .......................................................................................................... 165 ATTENTION TO DETAILS ................................................................................................................. 166 METICULOUS PLANNING ................................................................................................................ 168 GUIDE ........................................................................................................................................ 168 FACILITATOR ............................................................................................................................... 169 EMBRACING CONSTRAINTS ............................................................................................................. 169 SELF-STARTER AND PERSEVERANCE.................................................................................................. 170

CONCLUDING THOUGHTS .................................................................................................. 172

ANNEXURE A ..................................................................................................................... 173

Page| 4

www.ProductGuy.in


Table of Figures Figure 1 - Problem-Solution Fit ................................................................................... 17

Figure 2 - Product-Market Fit ..................................................................................... 18

Figure 3 - Addressable Market vs Serviceable Market vs Target Buyers ...................... 26

Figure 4 - Hierarchy of Needs ..................................................................................... 30

Figure 5 - Lean Canvas ................................................................................................ 50

Figure 6 - Golden Circle .............................................................................................. 59

Figure 7 - Transformational Engagement vs Relational Engagement ........................... 59

Figure 8 - Threat matrix of virtualization in service provider network ......................... 68

Figure 9 - Growth rate of computing systems ............................................................. 72

Figure 10 - Sales of luxury vehicles in the USA ............................................................ 90

Figure 11 - Product Adoption Life Cycle ...................................................................... 93

Figure 12 - Product Manager Relation Cycle ............................................................. 100

Figure 13 - Product Planning Phase - Timeline .......................................................... 112

Figure 14 - Conceptual view of Smart Parking Solution ............................................. 139

Figure 15 - Conceptual view of Projector .................................................................. 139

Page| 5

www.ProductGuy.in


Preface

Dear Readers,

Building new product is mandatory for any Organization to keep product portfolio

updated, continuously add value to existing and prospective customers, gain market

share, increase revenues, expand into newer markets, align with changing customer

needs and their behaviors, and incorporate technology trends and advancements. New

product development is both exhilarating and invigorating for Product Managers. It is an

exciting phase in the career of every Product Manager and each Product Manager will

yearn for an opportunity to conceptualize, build and launch the new product that

customers love. The primary goal of every product manager is to ensure commercial

success through building great products that customers will embrace readily. Yet, only

50% of new products succeed1. New product development is definitely a challenge and

Product Manager falters somewhere during the course of building the new product. I

intended to drop my humble experiences of building the new product through this eBook

with an intention that it will provide some guidance and actionable insights to building

new products.

Through elaborating my experiences of building the new product in this eBook, I have

structured actionable plans for successfully building great products that are:

Built on a foundation of strong product vision that defines purpose and objective

behind the new product.

Built to address real needs of real customers and as desired by those real

customers.

Built not just for needs of today but also for needs of tomorrow and in alignment

with an evolution of technology trends, market trends, changing customer needs

and their behaviors.

Built with all essential attributes that will drive customer preferences towards the

new product.

Please note that some of the information outlined in this eBook may be biased because

of my experiences of building and evolving B2B (Business-to-Business) HW (Hardware)

product of an existing product line. The eBook talks about new product development from

1 Source: http://www.stage-gate.com/resources_stage-gate_latestresearch.php

Page| 6

www.ProductGuy.in


the perspective of a Product Manager. Therefore, I consciously focused on activities

exclusively performed by Product Manager during various stages of new product

development.

A quick look at various topics of this eBook might throw an idea that we followed waterfall

model for product development. However, it is not the case, we never really followed

waterfall or agile. Instead, we integrated both the models. We did adapt a newer

development methodology, as pure agile or pure waterfall did not fit us. I did delve into

more such unique practices that we followed during new product development in this

eBook as a separate section called ‘What did we do differently’ and I also did attempt to

intertwine those experiences throughout this eBook.

I want this eBook to remain as a guiding force in sharing actionable insights for building

the new product. I have learned about Product Management by reading books, blogs,

articles etc. and primarily through my role as a Product Manager. The eBook is a way of

giving back to my fraternity through sharing my experiences. I would be humbled if

someone finds it useful and I am open to comments to make it better. The information

shared in this eBook is already available in my blog @ www.ProductGuy.in. I appreciate if

you could visit my blog and drop your thoughts and comments.

Copy of the eBook is downloadable from www.ProductGuy.in/eBooks/

Happy Reading!!!

Murali Erraguntala

LinkedIn| Slideshare| Twitter| Blog| Email

http://www.productguy.in/

http://www.productguy.in/eBooks/

http://in.linkedin.com/in/muralierraguntala

http://www.slideshare.net/merragun

https://twitter.com/emurali

http://www.productguy.in/

mailto:[email protected]

Page| 7

www.ProductGuy.in



New product development process consists of various stages (ideation, business review,

understanding and discovering needs, product development planning, product

development, and finally product launch). I tried to focus on activities performed by a

Product Manager in each of those stages. In addition, I have also focused on an additional

stage called monitoring plan, which is mostly a forgotten item in new product

development. I did drop my experiences primarily from the perspective of building the

new product to an existing product line. The major difference between building a new

product belonging to a new category and building a new product belonging to an existing

category is that in the later scenario target customers are mostly existing customers, so

validating new product idea, understanding and discovering needs, deriving the potential

size of the addressable market would be little easier and less risky. Product Manager

should extensively validate the new product idea just in case the new product belongs to

a new category. I recommend validating the new product idea based on the following

three parameters.

Problem-solution fit - Does the product idea address the right need and address it

right?

Product-market fit - Does the product to be built is targeting the right market?

Profitability - Is their sizable audience among target segment to make sufficient

revenue?

Along those three parameters, Product Manager should also identify whether the timing

is right for developing the new product. I have elaborated all those aspects in the later

section called ‘Idea Validation’.

Primarily, the task of a Product Manager in new product development is to either

conceptualize or facilitate conceptualization of new product idea that shapes the future.

Later provide convincing reasons that the new product idea is viable financially, would

add significant value to customers, fits within the overall strategy of the organization and

contribute to increasing the bottom-line of the Organization. In spite of successful

validation of new product ideas, not all product ideas transition into full-fledged products.

During product development phase because of inappropriate planning, wrong estimation

of product development cost, incorrect assessment of market and customer needs,

unsuccessful integration of latest technology or change in priorities of the Organization

etc., some ideas are abandoned mid-way. Yet, some new product ideas reach the finish

Page| 8

www.ProductGuy.in


line and transition into full-fledged products through successful launch only to be devoid

of commercial success. While new product development is exciting, it offers many

challenges to all stakeholders involved (especially to Product Managers). Therefore,

Product Managers could not afford to lose attention during any stage of product

development and should exhibit relentless attention to details with an extreme focus on

ensuring commercial success of the new product.

I have formulated queries for each phase of new product development to provide

actionable insights. Product Manager can leverage queries to obtain a holistic view of all

activities undertaken during each phase of new product development to avoid failures

and possible slips. The approach outlined perfectly works irrespective of whether it is an

HW (Hardware) or SW (Software) product. Queries can stimulate thinking. Queries can

also act as a checklist and can provide directions and guidelines for Product Manager to

meticulous plan new product development and impeccably launch the new product to

resounding commercial success. The checklist is a proven methodology to avoid slips by

Product Manager during new product development by explicitly pushing Product

Manager to ponder over every aspect of new product development.

Page| 9

www.ProductGuy.in


Idea Validation

The Intention of every Product Manager is to build a product that perfectly addresses

customer needs (unmet, untold, latent, under-served or over-served etc.) in a much more

effective, efficient, optimal and user-friendly manner vis-à-vis competition in relationship

to an attractive price point that customers can afford and willing to pay. Otherwise,

customers will not prefer the product. I do apply the same definition when someone asks

me ‘What is a Product’. The product either meets the needs of customers or enhance

their experiences sometimes they do both. It does so in an optimal way in comparison

with competitors in relationship to a price point that customers can afford and willing to

pay.

Every idea is born out of a problem statement. The eBook commences its journey with a

presumption that there is broader awareness of customer needs or problems and team

have conceived idea to address those needs or problems. Next eventual step is for

Product Manager to validate the idea. The idea validation is all about verifying the idea

based on three parameters2.

(i) Desirability - Do customers desire the new product to address their existing

needs or problems.

(ii) Viability – Do customers be willing or can afford to pay to solve their needs or

problems? Is there a sizeable market for business viability?

(iii) Feasibility – Is it technically feasible to build the new product that will optimally

address customer needs or problems?

There is a fourth parameter to idea validation that most of us miss is timing – WHY NOW?

WHY NOT EARLIER? Along with validating the idea on the parameters of desirability,

viability, and feasibility, Product Manager has to validate WHY IT IS NOW THE RIGHT TIME

2 Desirability, Viability and Feasibility was elaborated by Tim Brown in his book ‘Change by Design’

Product either meets the needs of customers or

enhance their experiences sometimes they do

both. It does so in more optimal way in

comparison with competitors at a price point

that customers can afford and willing to pay

Page| 10

www.ProductGuy.in


to turn the idea into a full-fledged product. Understanding WHY NOW is critical to ensure

that the new product is neither too early nor too late to the market.

Even though every idea has to be evaluated based on the above four parameters, the

rigorousness involved in validation process really depends on the nature of the idea. If

the idea is an extension of an existing product line, then the existing customer base could

act as a sufficient sample for validating the idea. The existing products could be

overserving or underserving the target segment or could not meet the evolving needs of

the target segment because of changes in technology landscape or customer behaviors.

Therefore, the new product could complement the existing product line to address:

The needs of a new target segment or

Unmet needs of an existing target segment or

Evolving needs of an existing or new target segment because of changes in

customer behaviors or their needs and changes in technology landscape

Irrespective of the scenario, I do not think it would be too difficult to validate the idea.

However, if the idea is revolutionary and creates a new product category, then Product

Manager should possibly consider customers using the perceived alternative for idea

validation. For instance, in the case of the first mobile device, Product Manager should

have validated the idea of the mobile device with users of a pager. However, in the case

of a revolutionary idea, absolute dependency on customers to validate the idea is not

advisable. In the case of the first mobile device, customers would be excited about

receiving a voice call on their mobile anywhere, anytime instead of just text. Nevertheless,

they could not think beyond the device and its intended use. For instance, the success of

the first mobile devices also depends on the operator’s capability to launch service at an

affordable price and government willingness to auction available spectrum for voice call

services. For operators as well, it is huge CAPEX to deploy the required infrastructure.

Therefore, the success of the product really depends on various external factors and this

is precisely what I call a product ecosystem. Product ecosystem is a combination of

external factors or drivers whose existence should be conducive to success of the product

idea. The ‘Timing’ parameter of validating new product idea can help assess the existence

of those drivers or factors.

Understanding ‘WHY NOW’ is critical to ensure

that the new product is neither too early nor too

late to the market

Page| 11

www.ProductGuy.in


Timing new product – Why now?

During validation phase of the new product idea, the larger discussion that needs wider

attention is to figure out the right time to start new product development or the focus is

more towards understanding why it is now the right time to develop the new product.

Timing is one of the most crucial factors that determines success or failure of the new

product. Product Manager therefore has to answer the most pertinent question – WHY

NOW? Why it is now the right time to translate the idea into a full-fledged product, so

(s)he can ensure that the new product is not too early or late to the market.

Discussions about timing are not very critical if the idea

is fulfilling an already existing need addressed partially

or fully by competitors’ products successfully. In such a

scenario, the focus should be more on ‘How Differently’

is the idea addressing a need. When Mark Zuckerberg

created Facebook, MySpace and other social sites are

already in existence. MySpace was famous at that point

in time. Therefore, the question would have been how

differently Mark should build Facebook to succeed

against competitors. I am not sure whether Mark

Zuckerberg has done any competitor analysis and it is

not significant for this discussions. What is important is

that timing factor might not be pertinent for ideas that

competitors have already addressed.

Any idea can address two broader categories of needs

i) Dormant Need – These are needs that are in existence since a long time but

unaddressed so far. However, the recent improvements in technology or increase

in economic status of the population or any other factor would have made it either

Product ecosystem is a combination of external

factors or drivers whose existence should be

conducive for success of the product idea

Page| 12

www.ProductGuy.in


feasible or viable to address the need. Customers can be either aware of a dormant

need or they might not recognize it.

ii) Emergent Need – There are needs that have emerged or will emerge because of

an existence of certain drivers.

Therefore, for any Product Manager to effectively respond to WHY NOW? I am

fundamentally relying on two parameters

What changes in technology, socio, economic or any other related factors makes

it either feasible or viable to address a dormant need?

What are the drivers triggering an emergent need or rather what drivers will

germinate a need in future?

Dormant need

Under the context of dormant need, let us look back at history to comprehend why digital

photography become familiar in early 2000 while the invention of the first digital camera

happened in 1975. While neural networks have been a familiar topic for 60 years, how

could someone explain the sudden emergence of products related to artificial intelligence

and machine learning only during last few years? I would loathe admitting that the use-

cases emerged only now. Use-cases were in existence and relevant all these years, but

why those technologies took decades to emerge after it was first introduced. The answers

remain in certain factors that have facilitated those technologies to flourish decades after

they were first conceptualized. The focus of evaluating why now is to discover and

understand those factors.

Identify drivers making it feasible or viable to address a dormant need

Improvement in GPUs as outlined by Moore’s law has provided necessary

processing power required to build intelligent AI systems. Those AI systems are now

capable of processing more data and providing meaningful insights to further act.

Availability of IoT, sensor devices, social network sites etc. have facilitated

generation of more data. While evolution in big data systems has made it possible

to store and model structured, unstructured and semi-structured data of various

formats at higher volume and velocity while ensuring the veracity of the data.

Availability of reliable sensors has paved way for lots of IoT (Internet of Things) use-

cases such as smart parking, intelligent health monitoring etc.

Page| 13

www.ProductGuy.in


When it was not financially viable for banks to establish branches in rural areas,

the emergence of mobile banking extended the reach of banking services to rural

people at an affordable cost e.g. mPesa3.

E-commerce enabled the possibility of selling less of more niche products4

profitably. Chris Anderson coined the term long tail for the business model of selling

less of more. Further E-commerce facilitated the creation of a market place to bring

buyers and suppliers much closer than ever before.

A closer look at the above examples will clearly indicate that there were always needs to

be fulfilled. E-commerce has facilitated to bridge the gap between suppliers and

consumers bringing them more closely than ever before. With the increase in a number

of cars, parking was always a hustle in most of the big cities; IoT has facilitated the

possibility of a smart parking system. Rural population always had banking needs to either

receive money from their wards living in faraway cities or borrow money for their farming

activities. Only mobile banking has made it feasible to extend the banking services to the

rural population.

Emergent need

In this scenario, identify jobs, products, or services that did not exist 10 years ago. How

would someone explain the sudden emergence of new products or services had it not

been for the existence of any dependent drivers? The emergence of new disruptive

technologies always spawns new needs. They create a new wave spawning new allied

products or services.

The rise in smartphones has generated the need for Apps.

The increase in demand for sharing and uploading videos has created a need for

better video optimization techniques for better transmission of videos over IP

networks.

The proliferation of more network-connected devices has spurred the need for

additional addresses, resulting in the creation of IPv6 addresses.

Had it not been for the availability of high-speed internet connectivity and

proliferation of handheld digital devices to take high-quality videos, YouTube would

not be successful.

3 Source: http://www.vodafone.com/content/index/what/m-pesa.html

4 Chris Anderson has elaborated about the concept of selling less of more in his book ‘The Long Tail’.

Page| 14

www.ProductGuy.in


Increase in population of elderly people by a factor of 2X in the US by 2030 will

definitely create the need for old age-friendly products or services.

Technology need not be the lone factor contributing to emergent needs. Regulation and

economic status can also contribute to emerging needs

Demonetization and government push for digital economy to create a cashless

society in India will lead to emergence of new products in financial technology

Increase in demand for more energy and inability to meet those demands would

spur the need for technologies to create alternate energy and energy efficient

products.

Depletion of portable water would create the need to derive reliable alternate

sources of portable water

The increase in per capita income increases the spending power of consumers

thereby providing an enormous business opportunity to offer irresistible services or

products. Per capita income is critical factor to watch while launching expensive

goods of services.

Product Manager has to identify whether need addressed by the new product idea is

dormant or emergent. Accordingly, Product Manager should evaluate whether an

environment is conducive to build the new product and whether it is now the right time

to start productizing the idea. If timing is inappropriate, then there should be a possibility

for an Organization to preserve the idea instead of discarding it. Product Manager should

reincarnate the idea when environment is conducive for it to prosper.

Product-Market fit - Desirability

While talking about timing, I was focusing on a set of drivers that (i) makes it feasible or

viable to address a dormant need or (ii) generate a new emergent need. The focus was

on factors independent of customers that can be conducive for an idea to flourish into a

full-fledged product. Whereas the purpose of establishing product-market fit is to validate

the following critical aspects that are crucial for success of the new product

1. Whether there is a genuine need?

2. Can the product idea address a need?

3. Whether the new product idea can address a need as desired by customers?

4. Is it the right product idea for the right market?

Page| 15

www.ProductGuy.in


Product Manager has to establish product-market fit even before contemplating the

possibility of developing the idea into a full-fledged product. Evaluation of product-

market fit will ensure that there is a market with an existence of real needs and the new

product will satisfy those genuine needs of the market in accordance with expectations

of the market. In addition to evaluating the veracity of a need in case of both B2B

(Business to Business) and B2C (Business to Consumer) products, there is also a necessity

to evaluate whether the new product is built for the right market in a way that the market

will readily embrace the new product.

Is the need real?

Product Manager could ascertain the reality of dormant need by identifying the positive

impact brought to lives of customers by addressing the need or rather by ascertaining the

adverse impact of not addressing the need. For the need not recognized by customers,

Product Manager could still anticipate the impact of addressing the need and

communicate it back to customers in a way that they get excited about how their lives

could get better. For instance, not many customers understand the concept of ‘SMART

HOMES’ and even governments are ignorant about the concept of ‘SMART CITIES’.

‘SMART CITIES’ is not just about smart parking. In both the cases, I do not foresee any

difficulty in helping customers understand the value rendered by any product towards

accomplishing the value of ‘SMART HOMES’ and ‘SMART CITIES’. The challenge with

dormant need might not remain in establishing the reality of the need but in evaluating

feasibility and viability of addressing the need. Later sections of this eBook elaborate on

topics related to feasibility and viability of the new product.

In certain cases, mostly related to emergent needs, customers cannot vouch whether

there is a real need. In such scenarios, the drivers that I had indicated in the section about

‘Timing of the new product’ establish existence or emergence of real need. The existence

of drivers causing the need could be a source of truth for the existence of a real need. So

In addition to evaluating veracity of a need,

there is also necessity to evaluate whether the

new product is built for the right market in a way

that the market will readily embrace the new

product

Page| 16

www.ProductGuy.in


in order to establish the existence of a real need, Product Manager has to establish the

existence of drivers causing the need. Identifying a trend of increase in billionaires in a

developing country can signal the genuine demand for luxury cars. Accordingly,

manufacturers of luxury cars like Rolls Royse, Maserati, and Bentley etc. can open shops

to sell their products. Identifying the trend of increase in devices generating and

consuming more data and migration of applications to the cloud can signal the need for

high bandwidth connections. Simultaneously, increasing trend of internet usage and

increasing trend of cloud-hosted applications also validate the need for high bandwidth

connections. Those trends should signal network giants like Cisco to either invest in high-

end routers or alternatively build products to optimize the usage of internet traffic using

innovative techniques. Identifying and establishing drivers causing the need can also

indirectly indicate the impact of not addressing the need. In accordance with discussions

until now, I have dropped a checklist to validate genuineness of the need.

What are the drivers causing the need? Is there a trend?

Do customers really care if the new product is addressing their need?

Does the absence of the new product adversely affect customers?

Does addressing the need significantly improve lives or businesses of customers?

Does it do so by i) enhancing experiences, ii) saving time, iii) cutting costs, iv)

facilitating operational excellence or v) helping customers generate revenue?

Will the product idea address the need?

Once the reality of the need is established, next step is to identify whether the product

idea is addressing the need. To do so, it might not be sufficient to identify the existence

of the need but should go beyond to identify what causes the actual need. There might

be a need for online purchase of goods, to better address the need it is always essential

to identify why customers are willing to purchase goods online. Efforts taken earlier by

Product Manager to identify the existence of the need, to understand drivers causing the

need, and to understand consequences of not addressing the need can help identify the

core need. I would categorize needs into the core and allied needs. Customers really care

if the product idea addresses their core needs. Addressing allied needs alone does not

help win customers. The answer to whether the product is addressing the need lay in the

ability of Product Manager to identify core needs and ensure that the product idea is

addressing them.

Page| 17

www.ProductGuy.in


Core needs and allied needs are synonymous with needs vs wants. Customers would

consider the new product only if it is addressing the needs and addressing wants should

be an afterthought. Addressing wants might provide an edge. However, it will not be the

reason to drive customer preferences towards the new product. To understand core

needs, identify what are customer needs and what are customer wants. Product Manager

should be able to differentiate the underlying problems or pain points that the new

product will address into needs and wants. Customer will pay for the new product only if

it addresses their needs, addressing wants is always optional. However, as the new

product evolves and once all the needs are satisfied, the product should start addressing

wants to drive customer preferences towards the product.

Figure 1 - Problem-Solution Fit

Will the product idea be desirable for customers?

Apart from validating the reality of the need and identifying whether the product idea can

indeed address the need, there is also a necessity to understand whether the new product

will meet the needs in accordance with the aspirations of a market. While building the

new product, the focus should not be purely on addressing the need but also on how the

new product is addressing the need. Does the new product address the need as per the

expectations of a market? MVP (Minimum Viable Product), prototypes, mock-up screens,

or video presentations go a long way in evaluating whether the workflow of the new

product to address the need is in alignment with expectations of the market. The focus

should also be on design especially while building products under the new category (for

instance building first home automation and first shopping trolley). In those cases, there

should be lots of emphasis on design to ensure the usability of the product without

altering customers’ behaviors. Any product that demands change in customers’ behaviors

might not get appropriate acceptance from customers in spite of precisely addressing

their needs.

Page| 18

www.ProductGuy.in


Right product for right market

Identifying the right market for the right product is an exploration process to find a perfect

match between product capabilities and market needs. If Product Manager either fails to

build the right product or fails to identify the right market, then it is a colossal failure.

While validating the authenticity of the need, Product Manager can identify the target

market for whom addressing the need is crucial. Even if the new product is average,

positioning it to the right market will put the new product on the path to tremendous

success. Market with genuine need will always pull the right product.

Identifying product-market fit is a continuous process even after rolling out version 1.0 of

the new product. Continuously evaluating the fit will help evolve the product in

accordance with changing customers’ needs and their behaviors. Understanding buying

process and understanding how customers make their buying decision will help Product

Manager corroborate existence of the fit and take appropriate corrective measures post

the FCS (First Customer Shipment). I drafted an eBook on ‘Comprehending Customer

Buying Process’ that precisely outlines framework to identify how customers make a

buying decision and what factors would drive their preferences towards the product. The

downloadable copy is available at www.ProductGuy.in/eBooks.

Figure 2 - Product-Market Fit

Product traction, increase in the pull through rate of customer inquiries, increase in sales

especially from existing customers, reduction in the cost of acquiring new customers,

positive feedback, increase in conversion rate from free trial to paid customers and more

product requests etc. will clearly indicate to Product Manager that product-market fit was

reached. Nevertheless, the other real indicator of reaching product-market fit is when

customers start exclaiming that is the product for me.

The real indicator of reaching product-market fit

is when customers start exclaiming that is the

product for me

http://www.slideshare.net/merragun/comprehending-customer-buying-process-to-sell-better


http://www.productguy.in/eBooks

Page| 19

www.ProductGuy.in


Evaluate product-market fit

Product Manager should always look out for both quantitative and qualitative ways to

ascertain the authenticity of the need. Product Manager should establish the authenticity

of the need without any iota of doubt in multiple ways through reliable methodologies.

Some people insist that Product Manager is wasting too much time validating the

existence of the need. They might persuade engineering team to proceed with

development of the new product with lots of assumptions around the existence of the

need. To all those critics, I could only insist that efforts put towards validating the need

will offset by faster development cycles, as the need is now well known. There is a real

value in time spent on validation of the need.

You know the If I had an hour to solve a

problem I'd spend 55 minutes thinking about

the problem and 5 minutes thinking about solutions.”

- Albert Einstein

After ascertaining the authenticity of the need, Product Manager has to evaluate whether

the new product would be desirable by customers to address their needs. Therefore, any

methodology to evaluate product-market fit should at least validate one of the following

premises.

1. Authenticity of the need

2. Ability of the new product to address the need

3. Ability of the new product to meet the need as desired by customers

I did try to elaborate few methodologies based on my experiences, but those are not the

only available methodologies. Loads of creativity is definitely required to identify an

appropriate, efficient, and optimal methodology to evaluate product-market fit.

Look for signs

Looking out for signs is an appropriate methodology to ascertain the existence of

a need especially while addressing an emerging need. Product Manager has to spot

signs indicating the presence of drivers triggering the need. I have earlier talked

about an emergent need for luxury products (for instance cars) in developing

countries. What might be possible signs that indicate the existence of the real need

for luxury cars – Quite obviously reliable reports indicating the rise of high net

Page| 20

www.ProductGuy.in


worth individuals in a developing country along with confirmation of their

penchant for luxury goods is sufficient indication that companies like Bentley can

sell their cars in a developing country.

What signs indicate the need for a smart parking system? The Increase in a number

of cars and scarcity of available parking spaces forcing people needlessly circle

around in search of free parking space are sufficient indicators. Smart parking

might not be viable if there is an abundant space for parking.

There could also be signs indicating gaps with respect to existing product offerings.

Freshdesk (a customer support product) backed by prominent investors like

Google Capital, Accel Partners, and Tiger Global Management was formed by a

simple comment about dissatisfaction levels of customers with an incumbent

customer support product5. Freshdesk identified the gap (or could I say ‘White

Spaces’) to successfully emerge as a reliable alternate player in customer support

software.

Signs indicating an existence of a need are definitely ubiquitous but sources

signaling a need are well defined. Depending on the need, narrow down sources

to look for signs indicating an existence of the need. Looking out for signs indicating

a need is not mandatory as long as there is a confidence on part of the Product

Manager to generate demand for a need. In such a scenario, Product Manager

need not look for signs indicating an existence of the need, instead (s)he can

validate the existence of drivers that can be conducive to generate a demand for

the need.

5 Source: http://blog.freshdesk.com/the-freshdesk-story-how-a-simple-comment-on-h-0/

Signs indicating existence of a need are definitely

ubiquitous but sources signaling a need are well

defined.

Page| 21

www.ProductGuy.in


Share the idea

Robert Kennedy co-founder of MaxMyTV pitched the idea of Interactive TV at a

startup event in Pittsburgh in 20126. Encouraged by positive responses from

attendees (including Andrew Moore, VP at Google) at the event, Robert Kennedy

began working on his product idea along with his other co-founders. Some

naysayers still insist on not sharing the idea with anyone citing that idea would be

either stolen or ridiculed. The value of the idea lay in execution and not in the idea.

Instances as illustrated earlier only prove that there is lots of value in sharing the

idea. Nevertheless, sharing the idea at right forums to the right set of audience to

fetch feedback is far more effective especially if the idea belongs to a new category

like MaxMyTV. Every major city has startup forums that invite people to share

ideas. Augmenting such forums to get substantial feedback about an idea even

without any initial prototype would immensely help to validate new product idea.

Scott Weiss, co-founder of IronPort (an email security company) did something

similar to validate his idea7. Instead of pitching his idea in a startup event, he

handpicked industry experts and reached them through emails, cold calling etc. to

validate his idea and his analysis about email security market. IronPort later

established as a leading player in email security and Cisco acquired it in 2007.8

Prototype – Fake the product

The prototype can be a product concept, mockup, wireframe screens, video, or 3D

design of the new product idea to validate it among prospective customers. The

prototype is also a reliable alternative to secure funding and further expand the

idea into a full-fledged product. The prototype is required if the idea is entirely new

and prospective customers or VCs need something physical or visual to understand

what they can expect when the idea is converted into a full-fledged product. The

prototype is a cost-effective and proven mechanism to fake the new product and

to gather feedback to evaluate product-market fit before proceeding to build the

new product entirely.

6 Source: http://yourstory.com/2014/09/maxmytv/

7 Source: http://blogs.wsj.com/accelerators/2014/10/20/scott-weiss-round-up-the-experts/

8 Source: https://en.wikipedia.org/wiki/IronPort

Page| 22

www.ProductGuy.in


The reason for prototyping purely depends on its purpose. If there is a purpose,

then purpose will dictate the need for a prototype and type of prototype as well.

If the purpose of a prototype is to evaluate the technical feasibility of the new

product idea, then investing on product concept makes sense. The Product

concept is a primitive way of building the new product to demonstrate the core

functionality sans any frills. If the idea is to validate how customers would react to

the new product idea, then mockup screens or videos is an ideal option. On the

other hand, if the purpose is to validate product design with prospective

customers, then the 3D design of the new product is an ideal option.

Prototypes are required to evaluate the existence of a need and to seek feedback

about the efficacy of the new product idea in addressing the need from prospective

customers in a quick and dirty way. Prototypes can be as simple as creating a

landing page and investing in google online advertisements for internet product to

identify how many customers would express interest in the idea. Prototype

precedes development and business review phase. Therefore, it necessitates not

only completion of the prototype but also fulfilling the purpose behind prototype

before seeking funding and approval for the product idea.

It is really a revelation to hear some stories about how new product ideas are

validated with minimal effort. Dropbox founder validated his idea by building a

three-minute video9.

Minimum viable product

MVP (minimum viable product) is one of the most familiar methodologies to

validate whether the new product is addressing a genuine need and whether it is

addressing the need as desired by customers. Product Manager can do so, by

evaluating behaviors of select few customers (aka early adaptors) while using MVP

version of the new product. Product Manager cannot complete development of

the new product with assumptions surrounding customers’ needs and their

behaviors. In case of new product going beyond boundaries of existing product

categories, Product Manager might not be sure whether the new product is

actually addressing a genuine need. Even otherwise, Product Manager might not

9 Source: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

Page| 23

www.ProductGuy.in


be sure whether the proposed new product is in alignment with expectations of

customers. Conceptualization of the new product invariably starts with

assumptions involving customers’ needs and their behaviors. Product Manager

should outline exhaustive list of assumptions around customer needs and how

customers will use the new product to address their needs. Later construct

hypotheses and identify methodologies to test them. MVP is one of the

methodologies to validate those hypotheses by explicitly measuring whether the

new product addresses customer needs and whether workflow of the new product

excites customers to use the new product. If assumptions involving either

customers’ needs or their behaviors are false, then Product Manager has to pivot

new product development and should formulate alternate hypothesis to proceed

further.

MVP can actually solve two purposes:

Does the new product idea address a genuine need?

Does the new product idea address the need as desired by customers?

It would be tough to build an MVP without outlining the exhaustive list of

assumptions or unknowns and without formulating the list of hypotheses to

validate those assumptions or unknowns. The objective of MVP is to identify what

to learn, accordingly build a minimum viable product that can help validate

assumptions or unknowns in a continuous cycle of build, measure and learn. The

motivation behind eliminating all unknowns and validating all assumptions will

form a baseline for what to learn. Based on the results of an iterative cycle of build,

measure and learn, Product Manager has to either preserve or pivot. I will focus

more on it in product planning section. For business review, highlight the plans to

build an MVP and the purpose behind building an MVP.

Prototype vs MVP

The prototype is a very primitive version of the new product in the form of video

or mock-up screens or product concept. On the contrary, MVP can be termed as a

trimmed version of fully conceived product with a basic set of functionalities

sufficient for early adaptors or early innovators to use it, validate it, and provide

feedback about it back to the product team. Product Manager might decide not to

sell MVP to customers but offer them MVP to gather feedback. I strongly feel that

Page| 24

www.ProductGuy.in


the released version should be different from MVP. I would call released version

as Minimum Valuable Product. MVP and prototype can at times serve the same

purpose but the path that they undergo is drastically different. There is no hard

and fast rule to choose between MVP and prototype. However, the efficacy and

efficiency of respective methodologies will determine the choice between MVP

and prototype. I would generally recommend using prototype alone to validate the

existence of need because building prototype is quicker and validating existence

of need is if fundamental before making any kind of progress. While I would

recommend MVP in the absence of any possibility of extending prototype for

identifying whether the new product is actually addressing the need that is most

critical to customers and whether it is addressing the need as desired by

customers. Product Manager has to target for completion of prototyping process

for validating the existence of need before the business review. The procedures to

validate whether the new product is addressing the need and whether it is

addressing the need as desired by customers can be done after business review.

Highlight the plans (what to validate) and appropriate methodologies (how to

validate) during the business review.

Is MVP necessary?

MVP is definitely not mandatory. MVP is required only if there is a testable product

or market hypothesis to validate assumptions or unknowns. Zappos built a landing

page to test whether customers would buy shoes online. Once the fact that

customers are willing to buy shoes online is pretty much established, there would

not be a need for any competing products in similar space to test whether

customers would buy shoes online. What might be required is to test buying

behaviors of online customers for enhancing their shopping experience to an

entirely new level.

Firstly, identify whether there is a need for MVP. Unless Product Manager has clear

view on what to validate, how to validate, why to validate, (s)he cannot determine

whether MVP is actually required. If affirmative, Product Manager should be very

The efficacy and efficiency of respective

methodologies will determine the choice

between MVP and prototype

Page| 25

www.ProductGuy.in


lucid on how the outcome of MVP would affect new product development. The

outcome of MVP should be binary, it should result in either pivot or preserve and

Product Manager should be unconditionally clear in how the new product would

evolve in both the scenarios.

What is the ideal methodology?

There is no definitive answer, then how do Product Manager determine what the

ideal methodology is. Two things that are heavily scarce during new product

development are ‘TIME’ and ‘MONEY’. During the process of building the new

product and dedicating it to customers, the entire team will race against time to

bring the new product to market after thoroughly validating all assumptions and

eliminating all unknowns. Of course, there would not be too much money to burn

either. The ideal methodology depends on its capability to achieve the objective of

validating all assumptions and eliminating all unknowns consuming less TIME and

burning less MONEY. If there are more than one methodology, I will rather pick

one that can help achieve the objective in less TIME and with less MONEY

irrespective of the complexity of the methodology. In certain cases, where there is

a conflict between TIME and MONEY, I believe TIME takes higher precedence.

Product feasibility

In addition to establishing veracity of the need and ability of the new product to address

the need as per expectations of the market, Product Manager has to assess whether

building the new product as envisioned is feasible. In collaboration with architect team,

Product Manager has to ensure that there are no technical challenges and building the

new product adhering to all the required compliances (if any) and as envisioned is

possible. During idea validation phase, a high-level evaluation of technical feasibility to

build the new product should suffice. Product prototype is an appropriate way to validate

the technical feasibility of building the new product. In the presence of any technical

challenges in building the new product, the existence of product prototype would be a

critical parameter to secure funding for the new product.

Feasibility is not only about evaluating technical feasibility but also about evaluating

feasibility to build the new product as envisioned within acceptable cost structure and

timeline. Irrespective of the pricing model, Product Manager should always strive to keep

Page| 26

www.ProductGuy.in


costs low while maximizing the value rendered by the new product. So evaluating the

ability to build the new product as envisioned, yet within the limits of acceptable cost

structure and without any possibility of schedule slip is essential.

Estimating market size

Identify target customers and estimate the total population of target customers, generally

called as TAM - Total Addressable Market and finally estimate how much of entire TAM

can the new product serve. Product Manager can use available statistical data or

guesstimates to estimate the TAM. The idea might have a global appeal but for some

strategic reasons, Product Manager might target local market first. Product Manager has

to outline which segment (based on demographic) of TAM is targeted first.

Figure 3 - Addressable Market vs Serviceable Market vs Target Buyers

For instance, cloud-based education software to facilitate teaching on a dumb terminal is

a universal idea and it has global appeal. Nevertheless, Product Manager might focus on

Feasibility is not only about evaluating technical

feasibility but also about evaluating feasibility to

build the new product as envisioned within

acceptable cost structure and timeline

Total Addressable Market

Total Serviceable Market

Target Buyers

Page| 27

www.ProductGuy.in


local geo-market before expanding globally. In such case, Product Manager should initially

pick the local geo-market as serviceable market and should figure out how many target

buyers within the serviceable market are potential customers (penetration rate) of the

new product. Product Manager should capture plans for expansion of total serviceable

market triggering the increase in the count of overall target buyers in the business plan.

The purpose is to indicate growth potential of the idea. The growth can arise by either

increasing penetration rate or total serviceable market or combination of both. The

business plan should reflect those plans at a high-level.

Profitability – Viability

After estimating market size, Product Manager has to ascertain whether the size of the

target market is large enough to break-even and make margins. Firstly, understand

whether customers can afford to buy the new product and is willing to buy the new

product. Affordability and willingness are two different aspects. Target customers can

afford to buy the new product but there would be a lack of willingness unless they realize

the value of the new product. On the contrary, the customers might realize the value and

be willing to pay the price but they could not afford it. Therefore, it is essential to look at

both the factors (affordability and willingness). In a scenario 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’10 conceived by C.K.

Prahlad11. If the customer is willing to buy the product and can afford to buy the product,

determine whether the size of the market is sufficiently big to make revenues based on

the estimated total addressable market, total serviceable market and penetration rate.

Simultaneously determine the cost of building the new product to calculate margins,

break-even period, ROI etc.

10 Reference: https://en.wikipedia.org/wiki/The_Fortune_at_the_Bottom_of_the_Pyramid

11 Reference: https://en.wikipedia.org/wiki/C._K._Prahalad

Target customers can afford to buy the new

product but there would be lack of willingness

unless they realize the value of the new product.

On the contrary, target customers might realize

the value and be willing to pay the price but they

could not afford it

Page| 28

www.ProductGuy.in


Organization fit

Product Manager should conclude the ideation phase trying to evaluate whether the new

product is in alignment with the Organization goals and strategies. There is hardly any

chance for approving new product development without clearly establishing how the new

product would align with overall goals and strategies of the Organization. Next step is to

evaluate whether the Organization has the required capabilities and experiences to build,

launch, market and sell the new product.

Hierarchy of needs

Maslow defined the hierarchy of needs for human beings. The hierarchy defines needs in

a pyramid structure where the needs at the bottom are the most important needs.

Human beings meet those needs first before proceeding to other needs in the hierarchy.

For human beings, food, shelter, clothing, financial security, love forms the basic needs.

Probably communication comes next in Internet era. Without meeting those needs,

human beings do not normally attend to other needs in the hierarchy, probably buying a

car. While validating the new product idea, especially in a B2B segment, Product Manager

has to define a similar hierarchy of needs for a B2B customer segment.

The B2B customer segment has lots of needs primary among them being profitability,

shareholder relationship, employee connect, social responsibility etc. In order to fulfill

those needs directly or indirectly and ensure continuity in business, customers buy

products for office automation, payroll, email communication, sales and leads tracking

tools, collaboration, connectivity, data center etc. Product Manager has to identify all

those needs and define a hierarchy of those needs. Later should ascertain the level at

which the need addressed by the new product idea is positioned. Customers, while

expressing their willingness and affordability to buy the new product will respond in

isolation without dwelling too much into their buying economics. However, when

customers either allocate or estimate budget for actual purchases, they will prefer buying

products at the bottom of the pyramid and will go upwards to satisfy other needs. Product

Manager has to ensure that customers’ budget does not dry before reaching the level

marked by the positioning of the need addressed by the new product. If a majority of

customers could not reach that level, then the new product hardly stands any chance for

survival. Product Manager might have to either strategize to push the need towards the

bottom of the pyramid by articulating the value that the new product could bring to

customers’ business or gracefully discard the idea of building the new product. Either way,

Page| 29

www.ProductGuy.in


Product Manager has to consciously identify where in the hierarchy, does the need

addressed by the new product is positioned and ascertain whether the new product has

any chance of survival.

Hierarchy of needs will indicate the desperation index of customers to satisfy the need

addressed by the new product in relation to their other existing needs. Customers will

start buying products in the descending order of desperation index. The product that

addresses needs with higher desperation index is at the top of customer purchase list.

Purchase list will contain an exhaustive list of products that customers purchase to

address their entire business needs.

The presence of need addressed by the new product at the bottom of the pyramid does

not essentially guarantee success. It will only provide an opportunity for survival. Whereas

survival will further depend upon how efficiently the new product is addressing the need.

In addition, effective positioning of the new product among target customers, prudent

pricing of the new product and optimal ways of selling the new product will also

determine the survival instincts of the new product. Formulating a pyramid outlining the

entire hierarchy of needs and later identifying the layer in which the need addressed by

the new product is positioned can also help Product Manager ascertain the impact to

sales during a recession and financial slowdown. Especially during those tough times

when customers drastically cut the budgets, using the pyramid Product Manager can

easily identify what needs do customers might be willing to forego.

Seth Godin has proposed the below pyramid for the hierarchy of needs for B2B sales. I

am providing it as a reference for Product Manager to define their own hierarchy of needs

based on their understanding of their B2B customers’ needs. It is essential to identify an

exhaustive list of needs that are on the purchase list of target customers and organize

them in the pyramid in accordance with the desperation index of target customers for

each need. After constructing the pyramid, Product Manager could validate it by

Hierarchy of needs will provide a desperation

index of customers to satisfy the need addressed

by the new product in relation to their other

existing needs

Page| 30

www.ProductGuy.in


observing purchasing patterns of customers. Purchasing patterns of not specific products

but entire products in the purchase list.

Figure 4 - Hierarchy of Needs12

Final Word: More often, an idea might evoke a “WOW” feeling among customers.

However, one should cautiously evaluate whether the 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.

12 Source: http://ganador.com.au/retailsmart/2012/6/19/b2b-hierarchy-of-needs.html

Source: http://sethgodin.typepad.com/seths_blog/2012/05/a-hierarchy-of-business-to-business-needs.html

http://ganador.com.au/retailsmart/2012/6/19/b2b-hierarchy-of-needs.html

http://sethgodin.typepad.com/seths_blog/2012/05/a-hierarchy-of-business-to-business-needs.html

Page| 31

www.ProductGuy.in


Idea Validation Phase Checklist

Idea vs Customer Needs

What is the new product idea?

What are the most critical customer problems or needs that the new product

idea will address?

Why Now?

Is it a dormant need?

o What are the drivers making it feasible to address the need?

Is it an emergent need?

o What are the drivers triggering the need?

Product-Market fit - Desirability

Is the need real?

o What are the drivers causing the need? Is there a trend?

o Do customers really care for the new product idea to address their

needs?

o Does absence of the new product adversely affect customers?

o Does addressing the need significantly improve lives or businesses of

customers?

Does the new product idea address the need?

Does the new product idea target the right market?

Can the new product idea meet market expectations?

Is the new product desirable by target customers?

Evaluate Product-Market fit

Are there any signs indicating the existence of need?

Are there any substantial gaps with existing products that signify existence

of a need?

Can Product Manager augment existing forums to get substantial feedback

on the new product idea?

Is it possible to fake the new product to evaluate product-market fit?

Page| 32

www.ProductGuy.in


Did Product Manager identified right methodologies (MVP, Prototype,

Looking for signs, Faking the product, Sharing the idea etc.) to evaluate

product-market fit

Profitability - Viability

Who are target customers?

Can target customers afford to buy the new product?

Are target customers willing to buy the new product?

What is total market size?

What is serviceable market size?

What is penetration rate (aka size of target buyers)?

Is the market big enough to make sufficient margins and ensure business

viability?

Feasibility

Can engineering team build the new product as envisioned?

o Is it technically feasible to build the new product?

o Is it possible to build the new product adhering to all the required

compliances?

o Can engineering team build the new product within acceptable cost

structure and timeline?

Organization fit

Is the new product in alignment with goals and strategies of the

Organization?

Does the Organization have the capabilities to build the new product?

Can the Organization excel at creating value (building), communicating

value (marketing) and capturing value (selling)?

Hierarchy of needs

Wherein the hierarchy of needs, is the need address by the new product

positioned.

Page| 33

www.ProductGuy.in


Business review

After formulation and validation of the new product idea, Product Manager has to start

drafting a strong business case that would highlight the need for the new product and

justify it financially by providing an appropriate ROI (Return on Investment). ROI alone

cannot be a deciding factor always if the new product is of strategic importance to retain

customers and cross sell other products. In order to provide compelling reasons for senior

management to invest in the new product, I tried to draft queries that would provoke

thoughts for business justification, under four broader categories:

1. Market Analysis

a. What is the need?

b. What is the potential impact of not addressing the need and not building

the new product?

c. Who are target customers? Does the Organization has required capability

to reach the target segment?

d. What is the size of total addressable market? What is the size of total

serviceable market for version 1.0 of the new product? What is the

penetration rate? Is it a growing market?

e. Is the market attractive?

f. Are there any market hypotheses? What are the plans to validate them?

2. Product Analysis

a. What are the top three needs that the new product will address?

b. What is the solution? What are high-level specifications of the new product?

c. What are the defining attributes (USP – Unique Selling Point) of the new

product?

d. Can the new product have profound impact on lives of target customers?

e. What is the platform strategy? Are we leveraging existing platform or

creating newer platform?

f. What is the total cost incurred to develop the new product?

g. Make or buy decision?

h. Are we imbibing any new technology into the new product?

i. What is the release date for the new product?

j. What is the positioning of the current product in the product life cycle?

k. Are there any product hypotheses? What are the plans to validate them?

Page| 34

www.ProductGuy.in


3. Competitive Analysis

a. How does Product Manager position the new product against competition?

What would be vectors of differentiation for the new product?

b. What is the current positioning of competitors?

c. How competitive landscape could potentially change in future?

d. What is the unfair advantage?

4. Financial Analysis

a. What is ROI of the new product?

Product Manager has to start framing responses to the above queries to formulate

business plan in the form of a word document or a .PPT and present it to senior

management. It is a well-established fact that queries stimulate and streamline thoughts,

so wherever possible I would adapt the strategy of first formulating queries and later try

responding to them. Doing so, I also try to first position myself in the role of a reviewer

while drafting queries and understand what kind of information would reviewers like to

hear from Product Manager. Later I start responding to those queries. Please note that

business review is a collaborative effort along with account managers, sales team, BDMs,

engineering team, architect etc.

Market analysis

What is the need?

Outline the exact need that the new product will address. There is always a

dilemma whether to start the review with a problem (i.e. need) or a solution. If the

need is well known and the solution is unique, I would suggest focusing on the

solution first. So start with product analysis. Otherwise, start with market analysis.

Use the analysis done during idea validation to elaborate the exact need and to

outline the findings that confirm the authenticity of the need.

What is the potential impact of not addressing the need and not building the new

product?

Product Manager has to identify the adverse impact on lives of customers without

addressing the need. Product Manager should also analyze adverseness of the

impact that customers do really care for addressing the need.

Page| 35

www.ProductGuy.in


Not building the new product is not a zero-sum game, if it is an extension to an

existing product line. Product Manager has to outline both tangible and intangible

impact of not developing the new product to the Organization, so management is

aware of the consequences of such a decision. Firstly, outline the revenue impact

to the existing product line, customers do not invest on existing products if the

product line is not evolving. Secondly, determine the possibility of losing customers

on adjacent products as well and revenue impact thereof.

Who are target customers? Does the Organization has required capability to reach

the target segment?

Product Manager has to identify the segment for whom addressing the need is

critical. Later identify whether Organization has the capability to capture that

segment. If the target segment is not the traditional customer base of the

Organization, then Product Manager need to outline a plan to position the new

product effectively and sell it to the new market segment. In addition, outline the

exact personas of the target segment to determine the overall market size.

What is the size of total addressable market? What is the size of total serviceable

market for version 1.0 of the new product? What is the penetration rate? Is it a

growing market?

Analysts can provide precise information on the overall size of the market and

ability of the market to grow. If it is a growing market, what is the CAGR? Growing

market alone is not a sufficient reason to invest unless the new product does not

have all the required ingredients to capture the growth. Product analysis will

address unique capabilities of the new product that would garner the interest of

target market.

If there is no sufficient analysts’ data about the market size and the ability of the

market to grow, look for alternate ways (even though crude) to identify market

size and to establish growth potential of the market.

i. Use Google trends tool to identify how a trend is evolving based on keyword

search trends.

Not building the new product is not a zero-sum

game, if it is an extension to an existing product

line

Page| 36

www.ProductGuy.in


ii. For B2C products, after identifying the ideal target customer. Use the census

data provided by the governments of each country to determine the overall

size of target customers and at what rate they are growing.

iii. Alternately, use guestimates to determine the size of the market. For

instance, what is the total population traveling through a particular highway

– To estimate the TAM for the highway motel.

iv. For B2B products, use the existing customers’ data for new products

introduced to an existing category. For products added to a new category,

use perceived alternative products to estimate the market size. Sales data

of existing products along with the rate at which it is increasing should

provide Product Manager an estimate of the potential market growth in

future. Alternatively, establish cause and effect relationship between the

growth of existing products and the dependent factor(s). Increasing

adoption of smartphones and easy payment options (like Cash on Delivery)

has contributed to the growth of mobile e-commerce.

Do not entirely rely on analyst data. Ideally, Product Manager had to look at more

than one data point to authenticate an existence of a growing market. Doing so,

Product Manager can avoid false positives in evaluating the overall size of the

market and its growth potential.

It might not be pragmatic to target the overall addressable market initially, identify

the serviceable market targeted by version 1.0 of the new product. Probably, the

focus could be on specific geo market for focused marketing efforts to reap better

benefits.

Is the market attractive?

Market attractiveness is not universal and it might vary with the overall size of the

Organization. For some Organizations, a $100M market might be attractive while

for other Organizations anything less than $1B is not attractive. Therefore,

understanding of Organization’s priorities and expectations is essential. There are

certain exceptions with respect to the new product addressing a trend, the initial

addressable or serviceable market will be abysmally LOW but it can have huge

potential in long term. In such cases, highlight the potential and provide strong

justification on why it is necessary to enter the market now with the new product

to realize the vast potentiality in long term.

Page| 37

www.ProductGuy.in


Are there any market hypotheses? What are the plans to validate them?

Outline all possible assumptions (if any) related to market (growth, target segment

etc.), formulate a hypothesis to validate each assumption and finally suggest a

methodology that will be employed to test market hypotheses.

Product analysis

What are the top three needs that the new product will address?

The new product can address many needs. However, during business review,

Product Manager should unambiguously indicate the top three customer needs

that the new product will address. It would be worthy to provide some proof points

on why customers value those three needs most. Product Manager should outline

how the new product is addressing those top needs distinctly from competitors’

products as part of competitive analysis.

What is the solution? What are the high-level specifications of the new product?

Product Manager has to describe how the new product will address the most

critical needs. Elaborate the solution as a workflow or using mockups. In addition,

describe the product specifications especially if the new product is an extension to

an existing product line, so everyone will get a fair idea of how the new product is

different from existing products. Providing product specifications is not mandatory

especially if the new product is addressing the needs of an emerging market with

lots of ambiguity where the exact set of product specifications will remain unclear

at least until validating hypotheses related to market, product, and solution.

What are the defining attributes (USP – Unique Selling Point) of the new product?

Attributes are those elements of the new product that uniquely differentiates it

from competition. The attributes should be in alignment with product

differentiation outlined under ‘Competitive Analysis’. The defining attributes can

be as simple as one or more of the following

Cost effective

Best performance

Feature packed

Highly intuitive and

User friendly etc.

Page| 38

www.ProductGuy.in


The defining attributes are required for two simple reasons

1. It helps in constant messaging of the value proposition of the new 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 and high-quality

product, there might be preferences for a lean team and cost effective

components probably compromising on performance but not on quality

Can the new product have profound impact on lives of target customers?

Even though it is essential to talk about product features and its USP, those details

might not capture the attention of executives. Product features and its USP often

sound alien even to executives within the Organization, so it is essential to

communicate the value delivered by the new product. Product Manager has to

articulate coherently how the new product can have a profound impact on

customers’ lives, how the new product will change customers’ lives for the better.

Focusing on the outcome will help Product Manager in lucidly communicating the

impact of the new product on lives of customers.

What is the platform strategy? Are we leveraging existing platform or creating

newer platform?

Depending on high-level requirements of the new product, value proposition, and

competitive positioning, the architect team has to decide whether the existing

platform is extensible to build the new product or new platform has to be

developed. When there is a necessity for developing a new platform, Product

Manager has to be deeply involved in the design and decision-making process of

the new platform to ensure that the new platform will lay a perfect foundation for

all upcoming products in the product line. While the architect defines HOW the

new platform will be built in accordance with the requirements shared by the

Product Manager, Product Manager has to ensure that the HOW is aligned with

WHAT and WHY of the new platform. Product Manager has the unique

Product Manager has to articulate coherently

how the new product can have profound impact

on customers’ lives, how the new product will

change customers’ lives for the better

Page| 39

www.ProductGuy.in


responsibility to connect the dots to decide whether the new platform will address

the purpose and objective behind creating a new platform.

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 the new product?

Product Manager should estimate the high-level cost required to develop the new

product. It involves engineering cost, marketing cost and cost of equipment(s) or

tool(s) required for new product development. For an HW product, additionally

estimate COGs (Cost of Goods) of the new product, amount of HW required to

build the new product, and cost to manufacture and distribute to derive profit

margins and break-even period for measuring ROI (Return on Investment).

Make or buy decision?

o If make?

What is the competency required to build the new product?

Does Organization have all required competencies to build the new

product or does it have to acquire any of those competencies?

What is the timeline to develop the new product and how potentially

could competitive landscape change during this period?

o If buy?

Are there any potential vendors to acquire?

How much does it cost to acquire?

Decision process involved in an acquisition is beyond the scope of this eBook, so I

will restrict my focus on a partial make and a partial buy. However, it is essential

for Product Managers to understand in which scenarios do absolute buy would be

beneficial.

Consolidation to draw synergies from the integration of multiple products. E.g.

Dell acquisition of EMC to consolidate server, network, and storage for

delivering converged solutions to customers

Expansion of product portfolio for a significant value addition. E.g. LinkedIn

acquisition of Pulse to have users spend more time on LinkedIn

Page| 40

www.ProductGuy.in


Entering new market or new technology domain. E.g., VMWare acquisition of

Nicira and Cisco acquisition of tail-f to make the foray into emerging

technologies like SDN/NFV by picking probable early winners.

In-house development of any new product is not entirely viable. Partial make and

buy are quintessential for any new product development. Primarily, there needs

to be a broader understanding of the entire list of components (both SW and HW)

and competencies required for building the new product. Later Product Manager

can assess whether in-house competencies exist to build those components (both

SW and HW). There could also be scenarios where Organization does not acquire

components, but it acquires competencies. For instance, lots of Organization take

help of design companies like IDEO to better design the new product. During the

business review, Product Manager only makes a high-level assessment of whether

it is essential to acquire any components or competencies for building the new

product. In the case of necessity to acquire any of the components (either HW or

SW) or competencies from external vendors, Program Manager would derive the

possible vendors and approximate cost to acquire them.

Product Manager and Program Manager will collaborate to identify the choice of

vendors to acquire each component or competency and will later follow a detailed

and rigorous process to finalize vendors for each component or competency during

product planning phase. In product planning section, I have elaborated on how to

choose a probable list of vendors and what is the process behind vendor selection.

During the business review, Product Manager should justify the need to acquire

components or competencies. Various parameters such as existence of in-house

competencies, cost to develop, time to develop etc. can determine the choice

between buy or make. The guiding principle for make or buy decision is that all

core components contributing to value proposition of the new product should be

built in-house, otherwise there might be trouble with differentiating the new

product.

Are we imbibing any new technology into the new product?

To support the vector of differentiation, Product Managers along with architect

team has to evaluate the necessity to introduce any new technology. Several

products fail because of the inability to integrate new technology. Either

technology is not mature or the initial assessment of it has gone terribly wrong. In

Page| 41

www.ProductGuy.in


any case, the risk is higher and hence it is appropriate to explicitly list new

technology introduction during business review.

What is the release date for the new product?

The release date is the finish line for new product development process. The

release date target should be realistic and it should set the course for building the

new product by allowing all stakeholders to appropriately plan in accordance with

the release date. During the business review, Product Manager has to outline to

marketing, sales, BDMs and account teams the ideal time to let the world know

about the new product. If there is any teaser or press release to break the news of

pending new product launch then everyone has to maintain secrecy until then. I

would probably suggest breaking the news after eliminating most unknowns and

validating most assumptions providing enough confidence that the engineering

team will build the new product as envisioned. What I had outlined just now is the

safer date for an announcement but the actual date can be much later in

accordance with a right market strategy to create sufficient momentum among

target customers about the new product.

In case of multiple products, Product Manager has to draft product line strategy to

list the delivery timelines of each product within the product line in alignment with

market expectations.

What is the positioning of the current product in the product life cycle?

In the case of introducing the new product to an existing product line, it is essential

to highlight the urgency to develop the new product depending on the positioning

of the existing product in the product life cycle. Accordingly, Product Manager

could estimate how quickly to make the decision to build the new product. Use s-

curve to highlight the current positioning of the existing product, if the existing

product is flattening or will flatten shortly because of the changes in preferences

in customers or evolution of new technology that delivers superior performance,

then it should provide sufficient reasons for senior management to approve the

development of the new product as soon as possible.

Are there any product hypotheses? What are the plans to validate them?

The idea validation process should have bought absolute clarity to the following

questions

Page| 42

www.ProductGuy.in


(1) Does the proposed new product addresses the right problem?

(2) Does the proposed new product addresses it right?

For some reasons, if there is no absolute clarity and still some hypotheses left to

validate, Product Manager has to outline the plans. To be more precise, Product

Manager has to outline methodologies to those validate hypotheses. In addition,

Product Manager should also articulate what are the possible outcomes of

validating each hypothesis and how each outcome would affect the development

of the new product.

Competitive analysis

How does Product Manager position the new product against competition? What

would be vectors of differentiation for the new product?

Based on the market analysis and customer analysis done earlier, Product Manager

should carefully derive unique value proposition that can provide confidence that

the new product becomes commercial success beating competition and efforts to

build it was justifiable beyond any doubt. If it is a new product to the existing

product line, Product Manager can also validate his findings by sharing the new

product details with their top customers who can be potential early adaptors.

Product Manager should be able to elaborate why customers would prefer the new

product to competitors’ products. There should be a clear indication of what

elements of the new product would drive customers’ preferences towards the new

product.

What is the current positioning of competitors?

Assess the current position of 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 the case of non-product attributes, I am

referring to items such as support, distribution channel, partners etc. Please note

that not all well-built products attain success, so it is essential to evaluating

strengths and weakness from the perspective of non-product attributes.

Page| 43

www.ProductGuy.in


How competitive landscape could potentially change in future?

Product Manager should analyze how competitors might react to the

announcement of new product development plans. It would be dumb if Product

Manager hopes that her Organization will develop the new product and capture

the market while competition would sit idle. The idea is to outline to senior

management on how the new product will succeed against competitors when

launched among target segments and what are defenses against possible

competition moves.

What is the unfair advantage?

What is the unfair advantage of the new product that competitors can neither copy

nor replicate? The unfair advantage need not be restricted to product

functionality. Unfair advantage can also exist on the periphery of the product that

makes it attractive for customers to buy the new product. Efficiency in building

products at low cost, unmatched distribution or partner network, brand loyalty,

and endorsements by industry experts can also be termed as an unfair advantage.

Financial analysis

What is the ROI of the new product(s)?

Calculating ROI can be a simple math. Product Manager can compute the

breakeven period and NPV (Net Present Value) for X years based on approximate

sales estimate using development cost, and COGs derived earlier. Approximate

product lifetime will determine the number of years for using in ROI calculation.

Each Organization would have its own way of computing the ROI. Nevertheless,

estimating the development cost, sales forecast for X years and COGs of the new

product are fundamental elements required to compute ROI. Irrespective of the

pricing model (cost based, value based, xAAS etc.) that would be adapted for the

new product, for ROI calculation I would suggest adapting simple cost-based model

(estimated product COGs + x% margin) to derive the breakeven period and NPV.

Doing so, Product Manager could keep the ROI calculations simple.

It would be dumb if Product Manager hopes

that her Organization will develop the new

product and capture the market while

competition would sit idle

Page| 44

www.ProductGuy.in


Other intangible factors to take into consideration is whether our sales channels, delivery

channels can effectively position and communicate the value proposition of the new

product to its target segment. Those details need not be elaborated in-detail during the

business review but worth mentioning, so Product Manager could complete the entire

story in a more convincing manner.

In the business plan, highlight all hypotheses related to product, market, customer and

competition. Hypotheses should outline an exhaustive set of assumptions and unknowns

in each of those categories. Highlight most critical assumptions and unknowns.

Simultaneously provide the plans to validate them in the business plan. Later in product

planning section, I have outlined details on formulating and validating hypotheses to

validate every assumption, to eliminate every unknown and to mitigate every anticipated

risk. Please be aware that validation or mitigation of some of the assumptions or

unknowns is essential prior to an aggressive start of the new product development.

The entire presentation to the Management should be like a STORY TELLING –

“It is a growing market with huge potential and target

segment contributing to 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. has better potential

address the requirements of target segment and it can

also aid in overall strategy of the Organization”

I am merely attempting to build an ‘Elevator Pitch’ for the new product.

Business plan dilemma

The one debatable aspect in the business review is whether there is a need to draft a

detailed business plan. Writing a detailed business plan stimulates thinking and pushes

Product Manager to think holistically about every aspect of the new product idea. The

business plan is not a document written on a rock, it is a plan and many elements related

to the new product will evolve as we progress through various phases of new product

development. In certain situations, the final plan might be entirely different from the

Page| 45

www.ProductGuy.in


initial business plan. Yet, the business plan is a good start. Drafting a business plan is a

process that will push Product Manager to think hard through various issues, evaluate

options and finally identify a plan that works. The importance of business plan in the

words of Jeff Bezos13.

You know the business plan won't survive its

first encounters with reality. It will always be

different. The reality will never be the plan, but the

discipline of writing the plan forces you to think

through some of the issues and to get sort of mentally

comfortable in the space. Then you start to

understand, if you push on this knob this will move

over here and so on. So, that's the first step.”

Final Word: New product cannot be a wishful thinking. Product Manager has to be

categorical that the new product will make $$$ even before it is built and Product

Manager do own the entire responsibility for commercial success of the new product.

13 Source: http://www.businessinsider.com/instant-mba-business-plans-are-important-and-necessary-2011-4?IR=T

Page| 46

www.ProductGuy.in


Business Review Checklist

Market Analysis

What is the need?

What is the potential impact of not addressing the need and not building the new

product?

Who are target customers? Does the Organization has required capability to

reach the target segment?

What is the size of total addressable market? What is the size of total serviceable

market for version 1.0 of the new product? What is the penetration rate? Is it a

growing market?

Is the market attractive?

Are there any market hypotheses? What are the plans to validate them?

Product Analysis

What are the top three needs that the new product will address?

What is the solution? What are high-level specifications of the new product?

What are the defining attributes (USP – Unique Selling Point) of the new product?

Can the new product have profound impact on lives of customers?

What is the platform strategy? Are we leveraging existing platform or creating

newer platform?


Make or buy decision?

o If make?

What are the competencies required to build the new product?

Does Organization has all required competencies or does it has to

acquire any of those competencies?

o If buy?

Are their potential vendors to acquire?

How much does it cost to acquire?

Are we imbibing any new technology into the new product?

What is the release date for the new product?

What is the positioning of the current product in the product life cycle?

Are there any product hypotheses? What are the plans to validate them?

Page| 47

www.ProductGuy.in


Competitive Analysis

How does Product Manager position the new product against competition? What

would be vectors of differentiation for the new product?

What is the current positioning of competitors?

How competitive landscape could potentially change in future?

What is the unfair advantage?

Financial Analysis

What is the ROI of the new product?

Page| 48

www.ProductGuy.in


Business pitch

Business plan document is more detailed and not every intended audience reads it in

detail. Yet I would recommend preparing a document to capture all the nuances. For the

sake of presenting attractiveness of developing the new product to senior management,

it is always advisable to create slides that capture both the details unearthed during idea

validation phase and also outlined in the business plan in a succinct form.

Layout of slides

The basic intention of a business pitch is to address the following: Is there a genuine need?

What is the customer segment that wants the new product to address their needs? How

is the new product addressing the need? Why would customers prefer the new product

to competitor’s products? How will the new product beat the competition? What is the

USP and unfair advantage of the new product? Is it a growing market segment? How will

the new product capture target market? Is the product viable financially? Finally, focus

on why it is now the right time to address the need (if applicable).

Slide 1:

What are the needs addressed by the new product? If there are many, highlight

the most important ones (probably top three).

Slide 2

What is the target segment that wants the new product to address their needs?

Slide 3

What is the size of the total addressable market? What is the size of the total

serviceable market for version 1.0 of the new product? What is the penetration

rate? Is it a growing market?

Is the need recognized or known to customers or does the new product has to

generate demand?

Mar

ket

Page| 49

www.ProductGuy.in


Slide 4

What are high-level product specifications? What is the product USP?

What is the solution? How does the new product change lives of customers?

Slide 5

What is the competitive landscape? How it will possibly change as the new

product development progresses?

Why would customers prefer the new product to competitors’ products?

Slide 6

What are the GTM (Go-To-Market) plans?

How does the new product capture initial serviceable market? What are the

expansion plans?

Slide 7

What is the business model? What are the cost structure and the revenue

model?

What is ROI? What is break-even period?

Slide 8

How will the new product comply with Organization goals and strategies?

Slide 9

No business plan is lucid and assumptions are an integral part of any business

plan. Outline all the risks related to those assumptions from the perspective of

three broader categories (1) product, (2) market and (3) solution.

Lean canvas – Summarize the plan

The final slide would contain a summary. There is nothing better than the lean canvas

derived by Ash Maurya to provide an excellent overview of the business plan. The

download link for lean canvas poster is available here and an attachment of the copy is

available below.

Pro

du

ct/

Co

mp

eti

tio

n

$$

$ V

alu

e

https://my.leadpages.net/leadbox/1401bda73f72a2%3A178b72cd4b46dc/5652786310021120/

Page| 50

www.ProductGuy.in


Firstly, I am a big fan of Alex Osterwalder’s one-page business model canvas elaborated

in his book Business Model Generation. Ash Maurya had adapted one-page business

model canvas intelligently and meticulously to create a lean canvas to highlight how a

product fits the market outlining all the connected pieces of USP, unfair advantage, cost

structure, revenue structure etc. Lean canvas can summarize how the new product can

capture the market and generate profits. Product Managers should use lean canvas to

represent the entire business model of any product in a succinct and yet effective way.

Product Manager can leverage lean canvas to summarize entire business pitch in one

slide. The only aspect that is not considered by lean canvas is ‘Timing – Why NOW?’ Start

the business pitch with nine slides that I had indicated earlier. Later focus on ‘Why it is

now the time to address the problem’, just in case if it is applicable. Finally, conclude the

slides with a summary leveraging the lean canvas.

Figure 5 - Lean Canvas14

14 Source: https://leanstack.com/businessmodelcanvas/

http://www.businessmodelgeneration.com/book

https://leanstack.com/businessmodelcanvas/

Page| 51

www.ProductGuy.in


New product approval

The way we look at the world is a reflection of how we think and look at ourselves.

Product Manager often presumes his/her idea is great, everyone will buy the idea and it

will be a cakewalk literally getting approval for the new product proposal. WAKE UP, the

reality is different. Just because Product Manager sees the brilliance, do not ever assume

that everyone would look at the new product proposal in a similar way. New product

approval process can be exhausting and exhilarating unless Product Manager

meticulously prepares to convince all executives involved in approving the new product

proposal.

The earlier recommended guidelines for preparing business review slides will concisely

elaborate why it is necessary to develop the new product and how it can complement

overall strategy of the Organization. Yet, remember that Product Manager should submit

the plan before multiple executives each with varying degrees of expectations and

objectives. Even though the business pitch slides tried to put forth a unified message at

surface level, deep down each executive might require details on aspects that are in

relation to their roles and responsibilities. For instance, VP Engineering will be more

concerned about the alignment of resources. CFO will be more concerned about payback

period and ROI, the strategic reasons to introduce the new product could be beyond the

grasp of CFO. VP Sales would like to know more on how the new product can go past

competition or possibility of new product cannibalizing older product(s). There are such

finer details that executives would seek clarification during the business review meeting

of the new product proposal. However, it would be tough to clarify and allay concerns of

each executive during a one-hour meeting.

Product Manager often presumes his/her idea is

great, everyone will buy the idea and it will be

cakewalk literally getting the approval for the

new product proposal. WAKE UP, the reality is

different. Just because Product Manager sees the

brilliance, do not ever assume that everyone

would look at the new product proposal in a

similar way

Page| 52

www.ProductGuy.in


Product Manager should not take more than an hour to present the business case to the

entire executive team. Firstly, identifying a slot that works for entire executive team is

time-consuming. Secondly, it is essential that there is a decision on new product plan

through consensus in either first or second meeting. It is tough to get the attention of the

entire executive team beyond second meeting and there is a possibility that executive

team will designate Product Manager as unprepared and incompetent. Conceiving the

new product idea and presenting it afresh to multiple executives without creating any

prior awareness about the new product idea and its corresponding business potential is

a catastrophe. All executives out of excitement or apprehension or over-enthusiasm

about the new product proposal will start firing multiples questions. Product Manager

will remain defenseless without sufficient time to respond to those questions and unable

to complete the entire presentation. The ideal approach is to lay the groundwork as

outlined below for a deterministic output on the day of reviewing new product proposal.

As Product Manager does the ground work, (s)he should have utmost clarity on the

possible outcome of reviewing new product proposal. After doing sufficient groundwork,

the review process should turn out more like a formality to get a ‘GO’ from the entire

executive team.

1:1 executive briefing

As much as Product Manager would have done lots of ground work trying to justify

reasons for new product development, (s)he would not have put efforts to identify

concerns of each executive. Identify who might be in favor of the new product proposal

and who might be dead against it. It is always good to do some groundwork to anticipate

the behavior of each executive while presenting the new product proposal for approval.

Ideally, Product Manager should start presenting business proposal individually to each

executive creating a familiar atmosphere about the proposal amongst them. Customize

at least few slides to explain each executive how the new product would be beneficial to

them. Understand concerns of each executive and explicitly try to address those concerns

by modifying business proposal accordingly. Doing so, Product Manager would have

allayed concerns of every executive. I did mention earlier that CFO might be more

interested to know about payback period, ROI and process followed to derive financial

numbers. If the ROI is well below Organization average and strategic reasons are a

motivation behind the new product, explicitly highlight it to the CFO. The objective of this

exercise is to ensure that concerns of each executive are appropriately addressed in a

Page| 53

www.ProductGuy.in


thorough and candid manner to get their buy-in. Emphasize to each executive that their

feedback is important and their participation is crucial for the realization of the new

product proposal.

Handle feedback positively

The purpose of presenting the new product proposal to each executive is not only to get

their buy-in but also to hear their feedback. In a proposal as big as introducing the new

product, it is always necessary to have multiple eyes on the business proposal to get

different perspectives on the entire proposal and scrutinize it thoroughly. Such initiative

would only strengthen the new product proposal. Therefore, Product Manager should not

take personally any feedback or comments even if they sound utterly stupid and gross.

Rather Product Manager should handle them with poise by responding candidly,

wherever possible supporting data should accompany the responses. The feedback could

be either ridiculous or it might question the very fundamentals on which the foundation

for the new product proposal was laid. Irrespective of the type of feedback, Product

Manager should never be petrified, (s)he should handle feedback elegantly by providing

a candid response. Doing so, Product Manager will only gain more confidence and can

have an unbiased view of the efficacy of the new product proposal.

Exude confidence

The owner of the new product proposal is Product Manager and there is no one out there

better than Product Manager who knows about the rationale behind the new product

proposal. The approval of the new product proposal does not merely hang on supporting

data provided in the slides, executives approval decision will also hang on confidence

exuded by Product Manager while presenting the proposal and while responding to

queries and concerns of various stakeholders. Product Manager is the sole entity involved

right from conceptualizing the new product idea to launching the new product. Unless

the Product Manager sounds confident, (s)he might falter in the execution even though

the product idea evokes WoW feeling. Confidence exuded by the Product Manager and

the panache with (s)he responds to the concerns of various stakeholders will be vital to

gain approval for the new product proposal.

Page| 54

www.ProductGuy.in


Refine.. Refine.. Refine

Our past experiences and coupled with the way we always work constraints us to think in

a certain direction and it is definitely not 360°, it might probably be close depending on

the brilliance of Product Manager but definitely not 360°. So identifying stakeholders

who can provide a holistic perspective to the overall plan further strengthening the

product proposal is critical. The stakeholders need not essentially be restricted to the

executive group who is responsible for approving the new product proposal. Product

Manager has to go beyond executive group to solicit feedback on the new product

proposal. Doing so, Product Manager will be more confident about the efficacy of the

overall proposal. Depending on the outcome of meeting with each stakeholder, Product

Manager should continuously refine the proposal and it should reach a stage that would

automatically call for consensus while finally presenting it to the entire executive team

seeking their approval for new product proposal.

Product Manages sometimes live in a shell dreaming about the product idea and the

excellent proposal that (s)he has put together. Often times, we need a critic who can be

honest and say to our face a spade is a spade. Often, it depends on the culture of

Organization to thrive on constructive criticism, shed inhibitions to fail and crush egos.

The Organization should foster a culture that should relish challenging each other

viewpoints. Even the highest paid person’s opinion (HiPPO) should not be an exception to

the rule. The Organization should foster a culture where every employee irrespective of

the pay grade and designation challenge others and simultaneously subject their

viewpoints for others to challenge. Doing so, Organization can be candid and self-critical

about what it is doing and be realistic in every attempt.

Identify influencer

In any initiative, we should always identify champions who can fight for our cause and

who could possibly influence the ultimate outcome positively. New product proposal is

no different. Product Manager has to identify executives who can be advocacies for new

product proposal. During 1:1 executive briefing, Product Manager has to identify the list

of executives who can possibly aid in securing approval for the new product proposal and

treat them as an ally. Allies not only help win wars but they can also help strategize to win

wars. Likewise, the executives who can be potential allies can help Product Manager to

shape the new product proposal so it could get an instant thumbs-up from the entire

executive team.

Page| 55

www.ProductGuy.in


Additionally, identify someone who can fight battles for you. If for some reasons, VP

Finance is not approving the new product because the projections were short of

expectations, convince your VP Product to fight the battles on behalf of you. As long as

you know why you are doing what you doing, never be ashamed to ask someone to fight

your battles. Asking help is not always signs of incompetence or weakness.

Don't be afraid to ask questions. Don't be

afraid to ask for help when you need it. I do

that every day. Asking for help isn't a sign of

weakness, it's a sign of strength. It shows you have the

courage to admit when you don't know something,

and then allows you to learn something new.”

- Barack Obama

Allies not only help win wars but they can also

help strategize to win wars, likewise the

executives who can be potential allies can help

Product Manager to shape the product proposal

so it could get an instant thumbs-up from entire

executive team

Page| 56

www.ProductGuy.in


What do you believe – Defines purpose

What does your Organization believe in – Is the new product built upon that foundation

of belief? New product built without any belief sans purpose. What the new product could

do and how it could do does not define the purpose. Those are transactional items

purpose is much bigger. Purpose underlined by a strong belief puts every stakeholder

involved with building the new product in a state of self-actualization where they are

inspired and motivated to do what they do. Purpose can also define the marketing

message that will drive customer preferences towards the new product. The difference

between good and great product lay in its ability to define why.

Organization beliefs

Conceptualization of the new product should happen upon a fundamental foundation

that characterizes the belief of the Organization. The belief that eventually dictates what

product should stand for, why does it exists and what it is intended to achieve. Food for

thought, what does great companies like Apple, Google, Facebook, Toyota, Honda etc.

believe in, are n’t their products direct reflection of what they believe. Therefore, every

new product built should embody the beliefs and the new product vision should be a

reflection of those beliefs.

What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great

Products’.

The difference between good and great product

lay in its ability to define why

Conceptualization of the new product should

happen upon a fundamental foundation that

characterizes the belief of the Organization. The

belief that eventually dictates what product

should stand for, why does it exists and what it is

intend to achieve

Page| 57

www.ProductGuy.in


In the words of Tim Cook15, following are the values that define Apple.

We believe that we’re on the face of the Earth to make great products.”

We believe in the simple, not the complex.”

We believe in saying no to thousands of products, so that we can really focus on the few

that are truly important and meaningful to us.”

Values are rather action words that are born out of beliefs and purposes. Are n’t the

above-stated values provide a foundation for how Apple build and evolve its products?

Therefore, any new product idea conceived in Apple should adhere to the above beliefs

1. Can the new product idea transition into a great product?

2. Does the new product idea epitomize the principle of simplicity?

3. Can the new product idea be transformational for the Organization? Can this idea

be the next big bet?

It is not about building unique products, but building products uniquely that no one else

dared to build so. There are limitless possibilities for building products uniquely, If

Organization believes in something unique and if it has the commitment and conviction

to stand for what it believes in. iPod is not a unique product, it entered the market after

the market was flooded with lots of music players. What makes iPod unique is in its

approach to building a simple and elegant music player that powerfully integrates the

device, software (iTunes) and music unlike any other device has done before or done

after. Apple did follow similar unique approach for iPhone too and I believe they will do

it repeatedly for any product that they will conceive in future.

15 Source: https://hbr.org/2012/04/its-not-what-you-sell-its-what

It is not about building unique products, but

building products uniquely that no one else dared

to build so

Page| 58

www.ProductGuy.in


Any new product that is ever conceived should pass the belief test, everything else that

we have seen (business review, business pitch, and new product approval) until now are

mere transactional. Product Manager had to take care of those transactional items as

well, but passing belief test will hold the key for the new product success as it will

transform the entire new product development from a transactional engagement into a

relational engagement. How does entering into a relational engagement makes any

difference?

Transactional vs relational engagement

Simon Sinek thoughts on ‘Start with WHY’ are very profound that it should find its place

in identifying the belief behind the new product. When Product Manager embarks on the

journey of building the new product – (s)he should start her journey with a belief that lays

the foundation for building the new product, a foundation that succinctly articulates why

are we building the new product both from the perspective of Organization and

customers. Product Manager should articulate the bigger purpose of building the new

product, through creating a vision of the world that does not exist yet. The vision that can

unambiguously communicate how the new product will transform lives of customers

thereby helping the Organization scale greater height.

https://www.youtube.com/watch?v=IPYeCltXpxw

Page| 59

www.ProductGuy.in


Figure 6 - Golden Circle

Simon Sinek has talked about 3 levels of engagement How? What? and Why? as part of

his Golden Circle concept that explains each level of engagement.

When the focus is only on WHAT the new product does? and How does it does? The

Organization is creating a transactional engagement among all stakeholders both

internally and externally sans any purpose.

When the focus is on WHY? The Organization can succinctly articulate its belief and the

purpose of its existence. The belief of Organization will lay the foundation for building all

new products, a foundation that defines why we are building the new product both from

the perspective of Organization and customers, and a foundation that can also define how

to build and market the new product. The belief imparts the purpose within each

stakeholder, so all stakeholders know why they are doing what they are doing. Revenue,

growth etc. will not define the belief or purpose. All those elements are by-products of

the belief or purpose.

Figure 7 - Transformational Engagement vs Relational Engagement

It is not what we make or sell. It is what we believe makes a lot of difference both

internally and externally. Belief is contagious and it would spread across to every

stakeholder involved with the new product - who sells it, who builds it, who markets it,

who supports it, who evangelizes it, who conceptualizes it etc. unifying everyone with a

How

What

Why

Transactional Engagement Relational Engagement

Page| 60

www.ProductGuy.in


common purpose and vision. There would be now absolute clarity on why we are doing

what we are doing. So everyday battles that all of us fight will be around identifying how

we can collectively realize the vision of the new product instead of being sceptical about

what we are doing. Everyone will be a guardian of the new product vision and struggle to

realize it. There will no more be voices that utter – are we doing the right thing. However,

voices will instantaneously raise when there is a deviation from the new product vision,

which eventually implies that there is a potential conflict with the belief and purpose as

well.

In a transactional engagement, employees know what they are doing albeit with little

clarity on why they are doing what they are doing. There is also little clarity on where they

are heading. They come, they work, and they go with lots of ambiguity in direction and

purpose. Under such circumstances, each employee is a mere foot soldier acting upon

certain instructions and when they had to make certain hard choices, they always falter,

because employees did not embrace any purpose or values.

On the contrary, in a relational engagement, the belief and purpose will define a set of

values (refer to Apple example provided earlier) and those values when imbibed into the

DNA of each employee will give them enough knowledge on how to react in any situation

by upholding those values. The decision-making will be flat and it does not always have

to traverse from top to bottom. Employees always have best knowledge and wisdom to

take a decision. Organizations make better products and survive longer if employees take

decisions. However, Organization should aid them with guidelines. Belief and purpose are

the only way to provide guiding principle or tenets for the decision-making process.

Look at Walt Disney’s purpose – ‘We create happiness’. Irrespective of their business,

they believe in creating happiness. When customers start believing in Walt Disney, start

believing in their ability to create happiness, they patronize their products irrespective of

movie or theme park. Even employees of Walt Disney will use the purpose and belief of

It is not what we make or sell. It is what we

believe makes a lot of difference both internally

and externally

Organizations make better products and survive

longer if employees take decisions

Page| 61

www.ProductGuy.in


creating happiness as the foundation for conceptualizing new products (movies or theme

parks) or evolving any of their existing products (probably theme parks).

Transactional vs relational engagement does not affect internal stakeholders alone. It

does influence the way customers perceive about the Organization, perceive about

products. It even influences the way customers’ interfaces with Organization and make a

buying decision.

Did you find your WHY?

When Organization finds its WHY? It is defining the future that the Organization is

attempting to create, it is leading the change, and it is envisioning a new world. The new

products are merely facilitating the future. When customers understand the WHY (i.e.

purpose), they do not see products they see the future. Doing so, Organization is not

selling the product it is selling the future. Customers get a palpable sense of the world

that does not exist yet. Finally, customers will find something promising. So please do not

wait, let us find WHY? to pave way for building a great product.

In a transactional engagement, the horizon is blurred. None has the bigger picture and

overall direction. Thereby interactions happen at a product level, at a feature level.

Interactions and discussions always happen relative to what others do. Competitors do it,

so we need to do it better. Customers require it, so we need to accomplish it. Multiple

conflicting priorities pull everyone in multiple directions without any unifying purpose and

direction. Choices of customers, competitors, partners etc. will influence our directions

and purpose. Finally, Product Manager will lose sight of what really differentiates the new

product.

When organization defines its WHY? It is defining

the future that the organization is attempting to

create, it is leading the change, and it is

envisioning a new world

When customers understand the WHY (i.e.

purpose), they do not see products they see the

future

Page| 62

www.ProductGuy.in


How often has a Product Manager noticed following comments when interacting with

customers - I see something missing in your product that is available in competitor

products, the product does not follow standards, I don’t know how it will add value to my

business, your product is too pricey – I get competitor products for cheaper price,

competitor is offering more etc. What those conversations mean to all of us, more

specifically to Product Manager, the engagement with customers is merely transactional.

In a transactional engagement, we will always be at the mercy of someone who can yield

influence with customers. If the new product should not go through those conversations

and if it should not be influenced by external stakeholders, then start with WHY? and

articulate to your customers, so they believe in what you believe.

Why do you think people buy Tesla? Do people buy Tesla because they believe in the

vision of Tesla to build powerful electric cars? Do they buy Tesla looking at the

specifications of Tesla models, convinced about the underlying technology and technically

impressed at the built of Tesla? I bet that majority of customers belong to the former

category. When customers start believing in what Organization believes in, they trust the

ability of the product to redefine future. Details of the product will not dominate any

conversations with customers. Customers do take pride in associating with such

Organizations and its products. They take pride in being part of the journey that

transforms the future.

Defining WHY? is essential but what is more important is the commitment and conviction

to deliver.

Commitment and conviction

Organizations should believe in something that is unique and they should have

commitment and conviction to deliver. Exploration is the first step in identifying a belief,

which is bold. Boldness in belief does not take us anywhere without a stronger

determination for execution. Any fundamental change affects three parameters (i)

people, (ii) process and (iii) business. All those three parameters should align with the

belief and aid in flawless execution. A candid introspection of the current state of the

Organization, what events or actions lead to this state, and where the Organization

intends to head can help identify what changes are required to the following three

parameters (i) people, (ii) process, and (ii) business. Any form of history always fascinates

me and it definitely offers some concrete knowledge on how to build our future based on

Page| 63

www.ProductGuy.in


our past actions. On those lines, I want to quote the words of Andy Grove – Author of

‘Only Paranoids Survive’ and Ex-CEO of Intel.

I have seen far too many people who upon

recognizing today’s gap try very hard to

determine what decision has to be made to close it.

But today’s gap represents a failure of planning

sometime in the past.”

To get the buy-in of everyone internally, Organization has to show the sense of urgency

on why we need to transform now. The urgency has to be articulated to employees,

shareholders etc. There is also need to articulate - What is in it for everyone - What is in

it for employees. It is not always about monetary benefits. Sometimes, there is a need to

articulate the bigger purpose. The inclusive approach will make employees feel that they

are bigger playing a bigger role in driving change. Shareholders should also understand

what is in it for the Organization. They need to understand the results of transformation

and why defining a belief would work. People embrace change only when they realize

what is in it for them.

Customers and employees do not instantly believe in what Organization believes in. It

takes time. Until then Organization should walk the talk and exemplify its belief through

its execution. Otherwise, it would be tough to gain the trust of both employees and

customers. Belief is contagious only when more advocacies believe in what Organization

believes in and who can radiate the belief to others on behalf of the Organization.

People embrace change only when they realize

what is in it for them

Page| 64

www.ProductGuy.in


Discovering needs – Drafting PRD

After the approval of new product development, Product Manager should embark on next

step to discover needs, convert needs into requirements and finally draft detailed product

requirements in the form of PRD (Product Requirements Document). PRD should start

with justification for the new product – So borrow relevant details from business case

Why customers need the new product?

What are the top customer needs addressed by the new product?

Why it is now the right time to build the new product?

In addition, it is very vital to elaborate on the below items in the PRD

How do customers’ needs evolve?

How do technologies evolve?

How do markets evolve?

Who are customers of tomorrow?

What are customer needs of tomorrow?

Responses to above queries would facilitate Product Manager to outline broader set of

requirements for the new product architecture. Product Manager should be aware of the

new product architecture and should play a key role in finalizing and approving the new

product architecture. While architect team would formulate product architecture,

Product Manager should act as a guiding force in formulating product architecture in

accordance with how technologies evolve, how markets evolve, and how customers’

needs or their behaviors evolve or new need emerges etc.

Purpose of the new product – The underlying belief

PRD apart from providing a justification for building the new product should clearly

articulate the purpose of the new product – what is the single most important purpose

both from the perspective of customers and Organization that the new product is

intending to accomplish. The PRD should outline the foundation that defines what the

new product stands for, purpose behind the new product and objectives of the new

product. The foundation should create a perimeter or a boundary that acts as an

overarching principle or tenet that governs how engineering team should build the new

product. Previous section of this eBook has articulated in detail the foundation that

defines the belief and purpose of the new product.

Very critical to laying

foundation for a flexible

product architecture or

platform

Page| 65

www.ProductGuy.in


Requirement vs Need

In the entire eBook, I had interchangeably used both the terms ‘requirement’ and ‘need’.

It is appropriate to differentiate a need from a requirement, so my readers can get a

better perspective when I refer to either ‘requirement’ or ‘need’.

Need – A need is any customer business challenge or pain point or desired business

outcome. Need is also referred to as job-to-be-done by customers. The need could be

untold (understood by Product Manager without being explicitly mentioned by

customers) or unmet (no product has addressed it) or underserved (existing product is

only addressing it partially) or overserved (existing product deliver more than what

customers need). A classic example of overserved product is Microsoft Office – most users

do not use 90% of the functionalities of office. Need is primarily defined from the

perspective of a customer. Typically, MRD captures a need.

The existence of a challenge or a pain point would be single most compelling reason for

customers to buy a product that addresses their pain point in a most optimal way while

delivering the best possible experience. Identifying and anticipating customer business

challenges or pain points is critical for building the new product. The business outcome

can be termed as a solution derived to address a business challenge or pain point. ISPs

(Internet Service Providers) are grappling with challenges of reduced or flat ARPU

(Average Revenue Per User) resulting in not so significant growth. Therefore, the desired

business outcome for ISPs is an opportunity to monetize their network and ISPs will rightly

embrace any product that can aid in such business outcome.

Requirement – A requirement is a need when translated into a form understandable by

an engineering team. While need outlines the WHY, requirement outlines the WHAT and

functional spec written by engineering to implement the need outlines the HOW. The PRD

mostly contain requirements, while it is worthy of mentioning need as a means to outline

the purpose behind the requirement. While the need will provide an indication of an ISP

customer looking forward to an opportunity to monetize their network, the requirement

will provide an indication of the exact list of features or solutions when added to the

product will facilitate customers to monetize their network.

Page| 66

www.ProductGuy.in


Discovering vs Understanding requirements

Terms ‘discovering requirements’ and ‘understanding requirements’ were

interchangeably used in this entire section. Discovering requirements refers to the

process of identifying needs that customers did not recognize yet. There are always needs

that customer do not recognize but Product Manager has the responsibility to spot those

needs while building the new product by observing customers in their natural habitat and

developing a thorough understanding of customer business environment. I refer to

identification process of those needs and translating those needs into requirements as

discovering requirements. On the other hand, understanding requirements is

identification of needs recognized by customer. Product Manager understand those

needs by explicitly talking with customers and the thumb rule that I follow for

understanding requirements is ‘Never ask customers what they need, always always

always ask why they need’.

Building the new product for needs of TODAY and TOMORROW

While drafting business review, I had focused on length on how the new product idea will

address needs of customers and how the new product idea will be desirable by customers

to address their needs. However, while developing the new product, the focus should be

on both needs of today and tomorrow. Unfortunately, Product Manager cannot predict

future, so Product Manager should anticipate needs and customers of tomorrow by

developing a thorough understanding of how markets evolve, how technologies evolve

and how customers’ behaviors or their challenges evolve. Accordingly ensure that the

new product can scale and adapt for needs of tomorrow and customers of tomorrow.

Product Manager do not predict future, instead

anticipates the needs and customers of

tomorrow by developing a thorough

understanding of how markets evolve, how

technologies evolve and how customers’

behaviors or their challenges evolve

Never ask customers what they need, always

always always ask why they need

Page| 67

www.ProductGuy.in


Customers might not be able to articulate what business challenges they might face in

future. Based on trends affecting the product and general understanding of customers’

business environment, Product Manager should anticipate customers’ requirements and

ensure that the new product will optimally address the requirements of tomorrow.

Product Manager can do so by looking outside the boundaries of existing customers and

trying to establish a generalized view of how market evolves because of changes in

external factors influencing technologies and customer behaviors. I have explicitly spoken

about discovering customer needs (needs of today) and market needs (needs of

tomorrow) in subsequent section.

Why look into future?

Before I go any further to talk about why Product Manager should understand customer

needs and anticipate how their needs can evolve in future or how new customers can

emerge in future. I need to make it very clear that version 1.0 of the new product will not

incorporate all future needs and focus would be on exclusively building a minimum

valuable product quickly for faster TTM. Minimum valuable product is a bare minimum

product that is sufficient to excite and attract customers towards the new product.

In the first release, the focus should only be on delivering the new product capable

enough of addressing most critical needs aka core needs. Addressing core needs should

provide compelling reasons for target segment to buy the new product. However, Product

Manager should precisely outline a vision for the future and it is advisable to extend the

horizon of the new product vision as much as possible to get a clarity of how the new

product would evolve.

Focusing on future needs and identifying those needs can help Product Manager

anticipate customers of tomorrow and needs of tomorrow. Accordingly, Product Manager

can conceptualize a product architecture that is scalable for future needs. Considering an

HW product lifetime could at least be for 5 years with a possible extension of support for

couple of years, anticipating how the future might affect the new product is crucial to

ensure that the new product is scalable for future needs. Furthermore, longer the

relevance of the product in the market, better the ROI, as the incremental cost of building

additional HW product is minimal. For SW products, the incremental cost of building

addition software is almost zero. So building scalable products that can sell more for a

longer duration is required for better revenues with higher margins.

Page| 68

www.ProductGuy.in


Yes

No

Ad

op

tio

n

The other factor that necessitates looking at future is to derive a threat matrix. What

newer technologies, economic policies, regulatory policies etc. can pose a threat in a near

future to the new product? Let me pick a familiar domain – technology. While I was

building the new product (HW appliance), I could anticipate two threats (1) the impact of

white labeled network products with entirely software driven architecture and (2) the

impact of virtualization. In addition, I also had an additional (3) threat from a regulatory

body on the issue of net neutrality. While building the new product, I had to identify all

possible threats and outline the probability of occurrence. Simultaneously identify what

factors can cause or mitigate those threats. The cause and effect relationship between

those factors and corresponding threats can help Product Manager consciously identify

the probability of occurrence is elaborated in detail later in this eBook.

Figure 8 - Threat matrix of virtualization in service provider network

I earlier indicated three possible threats for the new product. I did use one of them to

draw the above threat matrix to assess the impact of virtualization on the proposed new

product. There are two possible scenarios – ISP customers either adopt or do not adopt

virtualization in their network. Subsequent section of this eBook elaborates how to

Probability

High Low

Page| 69

www.ProductGuy.in


analyze factors that could contribute to various scenarios outlined in thread matrix. The

higher probability of customers not adopting virtualization does not pose any threat to

the new product while the higher probability of customers adopting virtualization pose a

serious threat to the commercial success of the new product. The remaining two

scenarios do not possess any immediate threat or relief.

How far to look into the future

Primarily, why should Product Manager anticipate, why not address the needs or target

new customers after they emerge. Whether to anticipate or just wait until the need

emerges fundamentally rests upon one factor – How long does it take to address a need?

If the duration is really longer, then Product Manager has the responsibility to anticipate

the need to get the 1st mover advantage and to excite customers before competitors do.

In case of automobile sector where the development cycles are BIG, Product Manager

cannot wait to understand the needs and aspirations of millennials until they start

purchasing cars. Therefore, how far to look into the future is merely the sum of time taken

to research, develop and validate the new product.

Another aspect of how far to look into the future will dependent on the two other factors

that I outlined for why to look into the future.

1. To build a product architecture and hardware that allows software to scale for

future needs

2. To conceive a threat matrix.

The above factors essentially means that we have to look through the entire perceived

lifetime of the new product. Otherwise, I would suggest looking for the estimated

duration of the new product to enter into profit zone. Essentially, Product Manager

should look until the estimated breakeven period. To ensure that we allay all possible

threats and the new product will safely land in safe zone of at least no losses. Product

Manager should identify all possible threats to the new product and anticipate all possible

needs of target customers. Since it would be tough to predict the future, Product Manager

could better anticipate possible outcomes of the future through scenario analysis and use

lean techniques of product development to build product increments to validate and

ascertain which outcome is most likely to occur.

Page| 70

www.ProductGuy.in


How to understand future?

Understanding future is tantamount to diligently anticipating the following:

How do customers’ needs evolve?





While I have spoken extensively on the above items in subsequent sections – What is

important is to understand the exhaustive list of factors that would influence how

customer needs evolves, technologies evolve and markets evolve. Understanding those

factors would help Product Manager determine the causal effect, meanwhile monitoring

those causal factors pro-actively would help Product Managers ascertain how future

might unfold.

Customer needs, technologies, and markets do not evolve overnight and they do evolve

at a linear pace. However, there are certain forces at play that culminate together to

suddenly push the evolution of customer needs, technologies and markets on trajectory

path reflecting a hockey stick. Especially for high-tech products, Clayton R Christensen has

clearly outlined that when the performance of new technology outpaces older

technology, it gains adoption. Similar to performance, Product Manager had to identify

several such factors that would result in the evolution of new markets, new needs and

thereby bringing in new normal completely replacing older way of doing things. The first

digital camera was invested in 1975, why did it gain acceptance only in later 1990’s and

early 2000’s, what caused the technology to replace the older film cameras 25 years after

its invention. It is always essential to look at those elements. Imagine someone building a

film-camera in late 1990’s. Even if built with awesome features, it would have been sure

recipe for disaster. History can be helpful to provoke our thoughts. Product Managers of

film camera products could have used the data to anticipate threat and take corrective

action. Product Managers of digital camera should have used the data to understand ways

of accelerating performance as to introduce the digital photography products faster to

markets.

Page| 71

www.ProductGuy.in


Let us pick another example that is more relevant for today’s world called AI. AI is a vast

area with wider levels of intelligence according to the use-cases that it intends to address.

At a broader sense, scientists and architects working on AI are contemplating to replicate

neural systems of the human brain to build intelligent systems that can learn and adapt

on its own just like humans do. However, to build such systems. We broadly need two

things

1. Huge processing power at an affordable cost

2. Availability of huge data and corresponding big data systems to retrieve, store,

model, process and act upon that data in a fraction of seconds.

The industry is making huge progress on both (1) and (2). However, whether they are

sufficient or not purely depends on the AI systems that we are building. When we are

building a new product that either embraces AI or discards it as a hype. We should have

a clear logic behind it instead of merely abiding by analyst reports or intuition. We have

to analyze the kind of progress (1) and (2) are making and what factors could further

accelerate or decelerate the progress that could eventually determine whether AI is really

a hype or reality. Such analysis can also throw light on the possible duration for AI to

become a reality. Accordingly, we can either determine the threats that AI could pose to

the new product if we are discarding it as a hype or determine when it is the right time to

build the new product embracing AI. Following three categories outline broader

classification of AI products.

(i) Artificial Narrow Intelligence (ANI) – Specializes in a specific task

(ii) Artificial General Intelligence (AGI) – Matches the capabilities of a human brain

(iii) Artificial Super Intelligence (ASI) – Exceeds the capabilities of a human brain. It

is getting tough to fathom the exact potential of ASI

Customer needs, technology and market does

not evolve overnight, they do evolve at a linear

pace. Product Manager has to look out for signs

of smaller bits of changes in each of those areas

(customer needs, technology and market) that

can one day combine together to take a bigger

form

Page| 72

www.ProductGuy.in


Figure 9 - Growth rate of computing systems16

Now that I have indicated various categories of AI and dependencies of those AI systems

on (1) processing power and (2) availability of data and ability to process and act upon

the data. Let us look at the above picture to understand the evolution of computing

systems. Clearly, computing systems that can mimic human brain at an affordable cost

will probably evolve around 2030. If we are looking at building AGI systems, then we know

when it is the right time to start building those systems. Simultaneously, we also

anticipate that there is no possible threat at least until 2030 from AGI systems to ANI

systems. However, after 2030 there could be intelligent systems that could do much

16 Source: http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-

1.html?utm_source=share&utm_medium=twitter&utm_campaign=sm_share

Page| 73

www.ProductGuy.in


beyond than just playing chess and driving cars. Simultaneously it is essential to undergo

similar analysis to understand when big data systems required for AGI systems will

actually evolve. Will it happen before 2030 or later?

While trying to understand the impact of technology either from a perspective of threat

or from a perspective of timing, it is essential to do some structured analysis as shown

above. Such analysis is clearly possible only if we could understand the dependencies that

underpin the evolution of various technologies. I have exclusively focused only on

technology. Nevertheless, Product Manager should focus on regulatory, customer

behaviors, purchasing power of customers etc. while anticipating how future unfolds and

determining how all those factors will influence the evolution and acceptance of the

technology. Many companies such as Kodak has gone into oblivion because they could

not anticipate the threat that digital photography can have on their products. Such

analysis should have provided Kodak clear analysis of when digital photography is ready

for mainstream market and what factors can aid its adoption. Accordingly, Kodak should

have switched gears to embrace to digital photography. We now knew that self-driving

cars would eventually become a reality. What about a decade ago while self-driving car

initiative was still very nascent. Was it possible to identify factors that could make self-

driving car a reality and anticipate duration for such possibility? Traditional companies

making cars should have done it to evaluate the threat matrix. Sometimes it helps to look

back at history to derive some meaningful insights that can help us connect with the past

in order to comprehend future.

The quantum of changes that will occur in future is much higher than what we have seen

in the past. Rightly, the changes that have transpired in the last decade is much higher

than the changes occurred in the last five decades. However, looking into past will

definitely help Product Manager to connect the dots to anticipate how smaller changes

can combine and what factors could bring those smaller changes to take a bigger form. In

today’s world, technology is one of the biggest drivers of changes. It has caused many

changes in customer behaviors, markets etc. No industry or product is immune to

technology advancements. One way of identifying future is to anticipate changes in

technology landscape and understand how it could impact existing markets or create new

markets, change customer behaviors or create new needs etc. Ideally identifying factors

related to technology would be a perfect start to understanding future.

Page| 74

www.ProductGuy.in


History offers meaningful insights about the past that can help us construct foresight

about the future. When some people are able to take decisions in split seconds, they are

able to do so because they are quickly reflecting with their past learnings, and they are

actively looking back at history. Here are some meaningful quotes on how connecting

with the past can help us comprehend the future.

Study the past if you would define the future.”

- Confucius

History is the past that illuminates the past,

and a key that unlocks the door to the future.”

- Runoko Rashidi

History is important because it teaches us

about the past and by learning about the past,

you come to understand the present, so that you make

educated decisions about the future.”

- Richard Mead

As outlined by thought leaders, history does offer many lessons to understand what led

to the present state and what could lead us to the future. To understand future, it is

always important to understand the present by explicitly connecting it back to the past.

Understanding causal-effect

Any transformation in customer behaviors, market or technology would cause a paradigm

shift. Understanding causal-effect is estimating the quantum of such shift by thoroughly

anticipating all causal factors and analyzing how those factors could cause the paradigm

shift and when. No change is independent. There is always a correlation of smaller

changes to coalesce into something bigger - X Y Z BIG CHANGE i.e. paradigm shift.

There are always some elements acting as a catalyst to combine smaller changes (‘X’, ‘Y’

and ‘Z’) into a bigger change. The smaller changes need not essentially combine linearly

or sequentially, it can sometimes be a complex tree structure. For simplification, I choose

a simple linear model of combining smaller changes. Along with identifying the smaller

Page| 75

www.ProductGuy.in


changes, Product Manager also had to identify the catalyst that can combine those

smaller changes to spur a bigger change. Evolution of technology, market and customer

needs will have so many connected pieces that Product Manager has to identify those

pieces and identify what connects those pieces together to anticipate bigger changes.

There are two ways to do it

1. Bottom up

Identify smaller changes and later anticipate what connects those smaller

changes to coalesce into something bigger

Product Manager has to be all ears and eyes to spot signs signifying smaller

changes and use scenario analysis to anticipate how those smaller changes

could culminate into something bigger

2. Top down

Anticipate a potential bigger change and work backward to identify what

smaller changes could sum up to cause those bigger changes

Analysts provide lots of information on possibility of bigger changes to trends

and their data can be a probable source of truth in this scenario

Nowadays analysts do a fantastic job of predicting how customer needs, technologies,

and markets evolve in future. Product Manager can rely on analyst information, but

instead of overtly relying on the analyst data Product Manager should try to understand

what could cause their prediction to come true. I did attempt to drop some thought

process on how virtual reality could enter the mainstream market by 2020.

Virtual reality is supposed to be a huge market by 2020. Firstly, let us understand why

virtual reality has not entered the mass market today.

Is the technology not affordable? Is the technology not mature?

Is there not a relevant and appropriate use of virtual reality technology?

Has the virtual reality ecosystem not evolved completely?

Understand what stops virtual reality from entering the mass market today and how the

gaps could be bridged propelling virtual reality to attain mainstream market in 2020.

How can someone ensure affordability of virtual reality technology?

How can the technology mature? Can affordability and maturity of the technology

be good enough factors for adoption of the technology in B2C space?

Page| 76

www.ProductGuy.in


What would be the appropriate use of virtual reality that can attract a mass

market?

In which segments, would there be demand for VR devices? Existences of what

business drivers would cause the demand for virtual reality products in those

market segments (particularly B2B)

I did a similar analysis for an earlier example that I picked to draw the threat matrix. We

analyzed what stops customers from adoption virtualization in service provider networks.

We did drew following observations that prevents adoption of virtualization in service

provider networks.

1. Lack of use-cases

2. Inability of virtualized products to meet performance requirements of customers

3. Lack of products to orchestrate, manage and load balance the traffic to virtualized

instances and

4. Lack of clear and tangible advantage over HW appliances

We later analyzed the presence of what factors would allow bridging of above gaps to

increase adoption of virtualization in service provider networks. We did analyze that (3)

cannot hold ground. When there are even remote signs of customers adopting virtualized

products, companies building products to perform (3) will automatically mushroom. The

primary aspect that was blocking adoption was performance. Without improvements in

performance, which will eventually lead to doing more processing on a single core of CPU,

it is tough to match performance requirements of customers. Conceptualizing use-cases

require a discovery process along with customers to understand their business

environments and challenges that virtualization can tackle. To do so, there is a need for a

tangible product. Without anything tangible, a mere whiteboard discussion will not yield

results. Therefore, we attempted to create an MVP version of virtual product. The

existence of a real product can help articulate value while allowing customers to

experiment with the product to derive real use-cases.

Let us look at another scenario – There is demand for luxury cars in China with higher

growth rate in next 5 years.

Why do we foresee an increase in demand for high-end cars in next 5 years?

Probably increase in per-capita income or emergence of new breed of customers

into higher income group

Page| 77

www.ProductGuy.in


Why do we foresee that the per-capita income will go higher? Probably change in

economic policies will spur growth and increase in high net worth individuals

Why do we foresee that the economic policies will spur growth? Probably new

policy change of government to create investments in infrastructure and increase

in exports through manufacturing

Even though analyst will outline when technologies such as Big Data, IoT, Self-Driving

Cars, Virtual Reality etc. would reach mainstream marketing, Product Manager should

independently assess how those technologies will attain mainstream and in which market

segments will they achieve mainstream. The idea is to assess what factors would make

the technology affordable and usable, which segments would contribute to demand of

those technologies. Accordingly, Product Managers can evolve their products to capture

majority of the predicted growth. Product Manager should always be inquisitive and

curious constantly asking ‘WHY?’ with insatiable quest to unravel the enigmatic future of

markets, technologies, and customers.

Discovery of customer focused needs

Product Manager should be all ears while talking with prospective customers of the new

product to grasp their business challenges and pain points. ‘Listen to your customers’ is

an age old adage that is followed by every business and I am not advocating doing

anything differently. I am just trying to emphasize that Product Manager should both

listen and understand customer needs, but (s)he does not let customers decide contents

of the new product. What I precisely meant is that Product Manager should not let

customers dictate what functionality to develop in version 1.0 or subsequent releases. I,

instead Product Manager will let customers focus on their business challenges (needs)

and Product Manager in collaboration with engineering team should derive an optimal

solution that would address business challenges of customers. Otherwise, customers do

not think twice to dump the product that contains exactly what they asked for in favor of

the product that optimally addresses their business challenges (needs). Even in the case

Product Manager should always be inquisitive

and curious constantly asking ‘WHY?’ with

insatiable quest to unravel the enigmatic future

of markets, technologies and customers

Page| 78

www.ProductGuy.in


of customers outlining the expected business outcome, Product Manager should

thoroughly analyze the reasons for customers proposing such outcomes.

On the related context, I want to quote the words of Henry Ford even though it is a cliché.

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 traveling quickly

from A B. So understanding customers untold and unmet needs along with explicit

needs is critical while building the new product. Yet does listening and understanding

customer needs alone would suffice? Before I go any further let me clarify my definition

of customer focus, “CUSTOMER FOCUS embodies everything that product attempts to

understand and address unmet, untold or underserved needs of either customers of an

existing product line or early adaptors of the new product”.

In short, customer focus is delivering what customers require instead of delivering what

they asked for. Sometimes the exclusive focus on customers might be a trap, it leaves

Product Manager to be very narrow and short term focused. While it is better to focus on

exclusive target segment ensuring that the new product addresses the needs of that

target segment. However, to attain long-term success Product Manager has to look

beyond the needs of the select group of customers.

Customer focus is about delivering what

customers require instead of delivering what

they asked for

Customers do not think twice to dump the

product that contains exactly what they asked

for in favor of the product that optimally

addresses their business challenges

Page| 79

www.ProductGuy.in


Discovery of market focused needs

In several of my blog posts (@ www.ProductGuy.in), I have repeatedly stressed that most

of the customer business challenges are short term. However, both short-term and long-

term business challenges and pain points of customers should be the focal point for new

product development. The pitfalls of listening to customers and acting accordingly is that

someone might suddenly pop-up disrupting the entire market with new technology or

new offering and customers might not think twice to switch sides. While it is required to

keep focused on prospective customers of the new product, it is also essential listening

to market to understand how it might evolve.

The market is no different from customers and indeed market is a generic representation

of a broader segment of customers. When I insist on market focus, I was looking forward

to expanding the horizon to construct a generic representation of the entire customer

segment and start assessing how their needs will evolve with changes occurring in

dependent macro factors. More often, there is inevitable necessity to go beyond the

boundaries of existing products and existing customers to identify or grasp what is

changing outside and build a mental map of how those changes might alter customers’

behaviors or create new needs.

There is inevitable necessity to go beyond the

boundaries of existing products and existing

customers to identify or grasp what is changing

outside and build a mental map of how those

changes might alter customers’ behaviors or

create new needs

The pitfalls of listening to customers and acting

accordingly is that someone might suddenly pop-

up disrupting the entire market with new

technology or new offering and customers might

not think twice to switch sides

Page| 80

www.ProductGuy.in


At a tactical level, it always augurs well to look at every individual customer needs to

ensure a steady flow of revenues. However, at a strategic level while Product Manager

has to envision how the product should evolve, (s)he has to create a mental map of how

the generic needs of the broader segment of customers evolve and how they will probably

respond to new technology innovations or any products in adjacency space that can

address the needs of customers. To be more precise, in case of market focus, I was rather

thinking strategically to fathom the long-term evolution of the market needs or long-term

relevance of the product due to changes in market/technology or customer behaviors

through explicitly pondering over the following

Attacking growth – If it is a growing market, there should be conscious effort to

identify who is contributing to the growth and lay plans to capture it?

Capitalizing white space (aka demand generation) – Probably same product but

new use-case and new target segment, Product Manager have to look out for such

possibility. Otherwise, Product Manager has to spot customers trying to use the

product differently from its intended use and should validate the possibility of

either building a variation of the existing product or enhance the existing product

to generate additional demand for the product.

Is there any product in the adjoining segment that has the potential to make the

new product irrelevant (what Mobiles did to Pager, what Smartphones did to

Camera and Navigation Devices) in near future? Is the new product a disruptor or

any other product(s) can potentially disrupt the new product? UBER leveraged

technology to deliver better taxi services in comparison with traditional players.

Identify or anticipate potential disruptors that have potential to displace the new

product from the market.

Who are customers of tomorrow – There was a wider perception that Internet

Service Providers (ISPs) were primary target segment of networking devices not

until Amazon, Google, Facebook, and Microsoft started buying more networking

hardware than ISPs. Not many vendors looked at the later as potential customers.

In the case of consumer products, Product Manager can build better products by

ascertaining the buying patterns or behaviors of Millennials, who might constitute

a significant portion of the target market. Their choices might not be the same as

existing customers. While building the new product, there should be conscious

effort to understand who customers of tomorrow are.

What are customer needs of tomorrow – Can Product Manager anticipate those

needs. Plan to build the new product not for customers of today but for customers

of tomorrow.

Page| 81

www.ProductGuy.in


Is there any new technology or trends that when not accommodated might cause

the new product to be irrelevant? For instance, the effect of virtualization

(Network Function Virtualization-NFV or Software Defined Networking-SDN) on

the physical appliances in networking industry or Impact of IoT on industrial

products. Is the new product negating all relevant trends? If so, Product Manager

is seriously jeopardizing the commercial viability of the new product.

Is the needs addressed by the new product could be addressed in a better and

efficient manner – iPod delivers the same functionality as other MP3 player but in

a much more efficient and effective way. Is the new product several notches above

the existing (competing) products in the market, can competition replicate the new

product? Is the new product really creating a competitive edge over both existing

and prospective competitor products? Is the new product truly 10X? Always try to

breach the self-limitations imposed around the new product.

Product Manager will not be able to consciously ponder over the above items unless (s)he

expands the horizon to go past the existing customers and existing products to

understand the characteristics of the entire segment and comprehend how it will either

react to external changes or impacted by external changes.

Anticipate emerging needs

Product Manager should conceive the new product to meet customer needs of not only

today but also of tomorrow. Unfortunately, there is no time machine to travel into the

future to identify the needs of tomorrow. Product Manager is not a clairvoyant for

randomly predicting the future. Instead, Product Manager should anticipate the needs of

tomorrow through systematically understanding the following:

a. How customers and their needs evolve

b. How technologies evolve and

c. How markets evolve

Being market focus is all about anticipating how customers will evolve or what new needs

will emerge with possible changes to dependent macro factors. Once Product Manager

understands the dependent macro factors (such as economic principles, regulatory

policies, internet trends, technology evolutions etc.) that can directly or indirectly impact

how customers evolve, how their needs evolve, how technologies evolve and how

markets evolve, there are 2 kinds of possibilities.

Page| 82

www.ProductGuy.in


1. Needs of tomorrow

With increased adoption of multiple devices (smartphones, tablets etc.) by

each user or family, will users start demanding new plans from ISPs?

With increased adoption of mobile devices in the rural segment and with the

possibility of a decrease in internet connectivity costs, could the following new

needs could emerge:

(i) Mobile banking. Similar to m-pesa model

(ii) Sharing latest farming techniques and knowledge.

(iii) Mobile commerce to sell directly to consumers – eliminate intermediary

agents.

With the advent of Internet of Things (IoT) and widespread adoption of IoT

technologies to create smarter homes, what will be the impact to ISPs that

provide pipes to carry data (specifically Machine-to-Machine - M2M)? How

could ISPs monetize the data? Will ISPs soon become utility provider?

2. Customers of tomorrow

With the potential increase in disposable income of millennials, can they be

probable target customers for real estate, luxury cars etc.? Product Manager

should ascertain whether their needs are same as existing customers.

What I have stressed so far is that certain needs will emerge and new customers will be

added to the target segment in future with changes to economy, technology trends,

regulatory policies etc., and it is the responsibility of Product Manager to anticipate both

emerging needs and emerging customers. Later, track them in PRD. Even after FCS of the

new product, such focused efforts can help Product Manager evaluate the relevance of

the product not only in near future but also in distant future as well. Such efforts can

ensure the longevity of the product without any possibility of premature decline.

Think Bold, Think Future

Product Manager does not have to innovate needs. Product Manager along with her team

just need to innovate solutions. Problems and needs are everywhere around us, only a

few recognizes them. Efficient discovery of needs will lead to an effective invention of the

new product. It is about not only consciously discovering a need but also about

understanding and anticipating how technology trends and advancements will further

alter both need and customer behaviors to ensure that the new product can address

Page| 83

www.ProductGuy.in


needs of tomorrow as well. There are two possible approaches to address future needs

or tomorrow’s needs. Product Manager can discover needs and understand how they

might evolve further with the evolution of technology, the evolution of customer

behaviors etc. Product Manager building a consumer product can understand the impact

of IoT, home automation on customer behaviors that will determine how customers will

embrace the new product. Otherwise, Product Manager can just think bold to conceive a

10x idea unconstrained by the evolution of customer behaviors and technologies and

unconstrained by existing benchmarks. In the former case, Product Manager is conscious

about technology trends and evolving customer behaviors, (s)he is diligently building the

product in alignment with those changes. In the latter case, Product Manager is at the

forefront of defining a trend and triggering a change in customer behaviors through his

10x product idea.

What great visionaries like those that Steve Jobs and Elon Musk did were the later. They

did think bold unconstrained by technology or customer behaviors. Apple started building

iPod after Steve Jobs identified the need to put 1,000 songs in a device. The idea of

stacking 1,000 songs in a device was definitely futuristic and bold thinking while Steve

Jobs conceptualized it. The new product built upon a foundation of the product idea that

is unconstrained by any limitation will define how technologies and customer behaviors

evolve. The new product built so will not be a by-product of how technologies or customer

behaviors evolve, the new product will rather steer the evolution of technology and

change in customer behaviors.

To build a great product, think ahead, think future. More importantly, think bold. If

Product Manager thinks bold, the needs or problems that (s)he intends to address will

neither be constrained by customer behaviors of today and technologies of today nor by

how customer behaviors and technologies evolve tomorrow. Doing so, new product ideas

become revolutionary shaping the evolution of technologies and customers’ needs and

disrupting the entire market creating a new normal. When Steve Jobs thought about the

problem of stacking 1,000 songs in a device, he was not 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. Elon Musk idea of building Solar City is

unconstrained by existing technologies. Rather his vision is driving the evolution of solar

Efficient discovery of needs will lead to an

effective invention of the new product

Page| 84

www.ProductGuy.in


technology and driving the changes in customer behaviors towards electric cars.

Visionaries such as Steve Jobs, Elon Musk defied every existing benchmark and analyst

prediction about the future to unfold the new vision of the world that does not exist yet.

End of the day, it is a choice that Product Manager has. Product Manager can either shape

the future or let the future take its own form and (s)he strive to be part of it. Our ability

to think bold determines our choices. Think bold to envisage the new product that shapes

the future.

Elaborate ‘Defining attributes’ of the new product

Product Manager has to elaborate in PRD about the defining attributes mentioned during

the business review. PRD will focus on two primary aspects

What are the key value propositions valued most by customers?

What are targeted vectors of differentiation?

The defining attributes of the new product should act as a guiding principle for the

engineering team and other stakeholders involved in the product development for any

decision making or trade-offs. While developing features, defining attributes (such as

simplicity, ease of use, reliability or higher performance) would determine how

engineering team should develop every feature. Defining attributes would also determine

the choice of components procured from vendors, so it is vital that every stakeholder

involved in new product development shares a common understanding of the defining

attributes.

The defining attributes of the new product should

act as a guiding principle for engineering team

and other stake holders involved in the product

development for any decision making or trade-

offs

To build a great product, think ahead, think

future. More importantly, think bold

Page| 85

www.ProductGuy.in


Drafting requirements and framing MVP list

Next level is to go deeper into specific capabilities of the new product. Focus on the

following, while drafting requirements in PRD.

‘WHAT’ product features are required, ‘WHY’ they are required?

Has every product requirement outlined in PRD is actionable?

Has Product Manager elaborated every product requirement in detail?

Has Product Manager tagged priorities for every product requirement?

Setting priorities for each product requirement will help in decision making while

determining trade-off among various elements like release timelines, product cost,

product attributes, product features etc. There will always be conflicting priorities such

as early TTM of product packed with lots of features. Here comes the topic of minimum

valuable product that could still fetch revenues forecasted in ROI calculations while

targeting early TTM. PRD should appropriately tag all features that constitute minimum

valuable product. Minimum viable product constitutes a minimal set of features essential

for early adapters to use the product. Product Managers use a minimum viable product

to validate the ability of the product to address customer needs and evaluate the

desirability of customers to use the product. I will elaborate about the minimum viable

product in product planning, but the ultimate idea is to evolve from minimum viable

product to minimum valuable product that customers readily embrace.

In case of building the new product to existing product line, I would insist on putting

emphasis on the following items as well

What set of functionalities of the existing product line will be inherited by the new

product?

What set of inherited functionalities will be altered to increase the scope, make it

simple, or make it better usable?

What are the drawbacks or inefficiencies of existing product line either eliminated

or improved in the new product?

What are the synergies between existing products and the new product within the

same product line?

Delivering synergies between old and new products

It is necessary to list down synergies between old and new product. If the new product is

an extension of an existing product line and even though built upon a new platform,

Page| 86

www.ProductGuy.in


Product Managers should outline if there is a need for any synergies between existing

products and new product within the same product line. Undeniably, majority of target

customers for the new product would be existing customers of older products and it is

crucial to take their inputs, requirements, and needs into consideration. All the existing

customers invariably will look for easy migration options from any existing product to the

new product with little or no switching costs. 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. Later during

product planning phase, the development team will clarify on their plans to deliver the

synergies between old and new product within the boundaries of requirements outlined

in the PRD.

Unlearn and relearn

New product need not just inherit awesome capabilities of earlier products, it can also

inherit processes related to product development and manufacturing, it can also inherit

distribution network and channels, it can also inherit partner network etc. However,

Product Manager should know when to reinvent the wheel and when to stop reinventing

the wheel. Faster execution and lack of resources alone should not be reasons to stop

reinventing the wheel, there should be reasons that are far more valuable. Older ways of

doing things do not essentially guarantee success, especially if the new product is trying

to break new grounds that require new pricing model, new development methodology,

new distribution channels, new target segments etc. Product Manager should know

where to draw a line between reinventing and not reinventing the wheel. Product

Manager has to ascertain which older ways of doing things would really aid in the success

of the new product, so every stakeholder associated with those older ways of doing things

should relearn those aspects and apply it to the new product. On the rest, where there is

a necessity to bring in new thinking to aid in the success of the new product, every

stakeholder involved had to unlearn what they had learned and learn again to ensure that

there are no traces of older ways of doing things.

Product Manager would not be actively associated or would not have complete authority

with many older ways of doing things. For instance, engineering determines right product

development methodology for the new product. Yet, Product Manager should still

understand the implications of sticking to older methodologies and advantages of moving

to newer methodologies. Which way of doing things does really help the new product or

Page| 87

www.ProductGuy.in


what decisions in the past have made the Organization bleed? Introspecting those details

can give a glimpse of what older ways of doing things should be adapted and where to

embrace newer ways of doing things. On some cases, older ways of doing things might

have brought success to the Organization in the past but it might not help with the success

of the new product. Waterfall model would have bought in success for earlier products

as there might be little less uncertainty while building those products. If the newer

product is addressing a new market where there is lots of uncertainty, then appropriate

model might be agile and there is a necessity for everyone to unlearn the older practices

and learn new development methodology. The channel to sell older products might have

worked earlier but if millennials are the target segment for the new product, then the

new product sales should happen through new channels that can attract millennials.

Unlearning and relearning are the crucial elements during new product development.

While unlearning can help challenge the status quo to break new grounds, relearning can

help optimize and refine existing way of doing things.

Hazy Market – Obscure product requirements

New products conceived in alignment with certain emerging trends or emerging

technologies such as Network Function Virtualization, IoT, Big Data etc. does not often

accompany with precise requirements. Most of such trends will be in a hype cycle,

associated technologies are just evolving and the market needs are not very clear.

Therefore, it is not viable to define a clear path for new products built along emerging

trends. The needs evolve, so do technologies. In such volatile environment, drafting a

detailed PRD might not be possible. Product Managers can at least provide minimalistic

requirements to build an MVP (minimum viable product) whose purpose is exclusive

validation of market, product and solution hypotheses. The requirements can further

evolve based on the outcome of MVP validation. Product Manager has to exclusively

focus on building the MVP version quickly, validate it quickly, fail quickly and learn quickly

to validate all assumptions. The hypotheses are not restricted to hazy markets alone, even

in the case of markets with absolute clarity of requirements there would still be certain

hypotheses that require validation. However, the number of hypotheses in both the cases

will vary in quantity and associated risks.

Page| 88

www.ProductGuy.in


Catch-up conundrum – Don’t blindly chase competition

‘Catch-up conundrum’ applies while conceptualizing a new product to counter incumbent

competitor. In an effort to counter competition to match abilities of an incumbent

product, Product Manager often decides to build the new product to bridge the parity

with competitor product(s) in its current state. Seldom does Product Manager realize that

while the development of the new product progresses to match the capabilities of

competition, competitors will also evolve their product not allowing any room to close

the gap.

If the gap between an existing product and the incumbent product is too wide, trying to

ape incumbent and following the incumbent will never let the new product to peak.

Instead, listen to the market, think ahead of time and try to imbibe new technology or

new offerings to jump ahead of the market leader. Nintendo WII is a classic example of

not following the path of competition. While Nintendo’s competitors were busy driving

the market towards expensive consoles and sophisticated graphics successfully, Nintendo

did not follow them instead build WII leveraging the new technology of gesture control

and targeted a new segment of casual gamers with less expensive consoles driving huge

margins. Customers sometimes embrace competitor products not because they love

those products but because there are no viable alternatives. While building the new

product, Product Manager has to ascertain the existence of such alternative space and

build the new product different from those of competitors.

The existence of incumbent competitor is always a good news. There would be a

precedent of what worked and what did not work. Therefore, Product Manager while

focusing on closing the parity with the incumbent product had to take advantage of the

experiences of the incumbent to focus on requirements valued most by customers and

should have a forward-looking perspective of what customers might value additionally.

While bridging the gap with competitors by developing parity features, Product Manager

should also look out for those unique capabilities embracing market and technology

trends that can set the new product miles apart from the competition. The PRD should

Customers sometimes embrace competitor

products not because they love those products

but because there are no viable alternatives

Page| 89

www.ProductGuy.in


outline such requirements that can facilitate the new product to leap competition. I

strongly believe in the principle – ‘Do not blindly chase competition’.

Not blindly chasing competition does not essentially indicate that Product Manager picks

everything that competition has not done. Product Manager should identify why

competitors have not done what they have not done. Sometimes, competitors miss to

address genuine customer needs because they either did not spot those needs or could

not address those needs. It is essential to identify those reasons to understand the risks

in addressing specific needs. Product Manager often look at competitors and get excited

that there is a potential gap to address without realizing the inherent risks. Alongside

those analyses, Product Manager should combine them with deeper customer insights to

understand the needs that customers desire but not addressed by any product.

Understanding competitors is only to identify the gaps and but to gain an understanding

of where they are heading, what needs they might address, what markets they might

chase. Such analysis when bundled with customer insights will provide splendid details

on which gaps to close, what new technology to embrace and which opportunities to

chase to leap competition. Doing so, can also help Product Manager identify gaps in

incumbent product making them vulnerable.

Netflix while competing with Blockbuster embraced Internet trend to allow users to rent

DVDs online, receive them by mail and return at any retail locations without any late fee.

Good news is that incumbents have their own vulnerabilities and one of the major

vulnerability is the lack of agility to adapt to changes in market or technology or customer

behaviors unless they cause those changes. In order to circumvent competition, Product

Manager has to identify such vulnerabilities of incumbent competitors and use it to their

advantage. There are vulnerabilities in every incumbent product.

I strongly believe in the principle – ‘Do not blindly

chase competition’

Product Managers should identify why

competitors have not done what they have not

done

Page| 90

www.ProductGuy.in


Every incumbent product is vulnerable

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.

Figure 10 - Sales of luxury vehicles in the USA

How many of us would have believed that there is a possibility for a new player to emerge

victorious in the luxury car market 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. 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

1st 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, they built amazing

navigation product preferred by lots of users over Google maps. I could not imagine

Page| 91

www.ProductGuy.in


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 huge gap of

unaddressed needs. Conventional wisdom of building products is accrued naturally

through precedents set by earlier successful products. Astronomical valuation of

Facebook even 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. 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.

Product/ Solution hypotheses

The business review contains a list of market hypotheses that outline assumptions related

to market and mechanisms to validate them. In the PRD, the focus is on an exhaustive list

of product and solution hypotheses. The hypotheses should be testable and PRD should

outline methodologies to validate hypotheses. The list of hypotheses will provide an

indication to Development Manager and Program Manager on two aspects. First, the set

of functionalities that engineering team will implement in the initial phases of the

development cycle to aid in validating hypotheses. Second, the set of functionalities that

engineering team will delay until validation of certain hypotheses. Delayed functionalities

will later be implemented depending upon pivot or preserve scenario in accordance with

the outcome of validating each hypothesis. PRD should outline dependencies between

delayed functionalities and its associated hypothesis. PRD has to list requirements that

Product Manager will evolve later based on the outcome of product and solution

hypotheses, thereby bringing in agility in drafting requirements. ‘Product Planning’

section of this eBook outlines more details on this topic.

Page| 92

www.ProductGuy.in


Finally, ‘Whole product approach’

The last section of the PRD should talk about ‘Whole product approach’. Whole product

approach focuses on elements (both tangible and intangible) enabling the new product

to sell better. The new product alone cannot influence a sale. The whole product

comprises of both tangible and intangible elements that can drive customer preferences

towards the new product. PRD should list high-level plans for the following elements of

the whole product.

Technical support

Partner training

Product documentation

Compliance requirements

Sales or distribution channel support etc.

Later, Product Manager should identify what elements apart from the actual product are

crucial for first release i.e. what elements would attract customers towards version 1.0 of

the new product. The list of tangible and intangible elements of the whole product that

can influence the buying decision of customers will vary in accordance with the category

for each customer. Product Manager has to align whole product approach with product

adoption cycle and not with specific SW release. Ideal mechanism would be to list down

all elements of ‘Whole Product’ in the form of the matrix as listed below. Against each of

those elements, Product Manager has to indicate in % values how much each category of

customers across product adoption cycle would value the core product and its various

add-ons relatively. Higher % value against any element indicates that it has higher

potential to positively influence a sale of the product and therefore should be focused as

the product traverses through respective categories of the adoption cycle.

Innovator Early

Adapters

Early

Majority

Late

Majority

Laggards

Core

Product

Technical

Support

Installation

Manuals

Page| 93

www.ProductGuy.in


Additional

SW for Ease

of Use

Location of

Stores

…

…

Table 1 - Whole product matrix

For product adoption cycle, I took the example of Geoffrey Moore as outlined in his book

‘Crossing the Chasm’. In fact, Product Manager can pick any other model like –

Product/Market Fit Phase, Growth Phase, Maturity Phase etc. The overall idea is to

emphasize that the buying decision of customers vary across product adoption lifecycle.

Therefore, it is critical to be aware of customer preferences at each phase of the product

adoption lifecycle and to be conscious about product transitions as it traverses through

various phases of the product adoption lifecycle.

Figure 11 - Product Adoption Life Cycle

Core product which could be termed as actual product that primarily focuses on

addressing critical needs of customers (aka top three needs outlined in the business

review and PRD) without any frills, interests more to ‘Innovators’ and ‘Early Adapters’.

They might care least for relative ease of using the product or documentation. For ‘Early

Page| 94

www.ProductGuy.in


Majority’, product documentation, ease of using the product and considerable customer

references in the form of case studies or testimonials might be essential for making a

buying decision. Therefore, Product Manager has to understand what elements of the

whole product will positively influence customers buying decision across various

categories (Innovators, Early Adapters, Early Majority, Later Majority, Laggards etc.) as

the new product traverses through the product adoption lifecycle. Accordingly, Product

Manager should plan to focus on those elements of the whole product.

I drafted an eBook on ‘Comprehending Customer Buying Process’. The downloadable

copy is available at www.ProductGuy.in/eBooks. The eBook is an attempt to reverse

engineer the buying process of customers. Product Manager should always start with an

end in mind (i.e. a successful sale) and work backward to understand what factors would

contribute to a successful sale of the product. Comprehending customer buying process

by Product Managers provide a unique opportunity to identify those factors that can

positively influence a sale. Whole product approach should comprise all those factors that

can influence a sale.

Ironically, ‘Whole Product Approach’ has the least importance in comparison with the

actual product. As part of the ‘Whole Product Approach’, Product Manager should also

consider ‘Product Ecosystem’. Product Ecosystem is a culmination of multiple external

factors contributing jointly to the success of the new product. However, the value

rendered by every player within the product ecosystem will not be identical. Product

ecosystem becomes crucial if the new product success is dependent on the network

effect.

From the perspective of ecosystem harnessing a network effect, products can fall under

two categories

i. Products that drive the ecosystem – Products that are at the center of the

ecosystem and being instrumental in creating the entire ecosystem.

For instance, smartphone OS (iOS, Android) that created an entire ecosystem

of apps, own the entire ecosystem and are primarily responsible for the success

of the ecosystem.

ii. Products that thrive on the ecosystem – They are at the periphery of the

ecosystem and significantly contribute to the strengthening of the ecosystem.

Even though apps thrive on the ecosystem, their existence strengthens the

ecosystem. The presence of producers, who develop apps for the ecosystems,



Page| 95

www.ProductGuy.in


will strengthen the ecosystem to attract another player in the ecosystem called

‘consumers’.

There is another dimension to product ecosystem called consumers. Presence of

consumers is essential to create a network effect. Social networking sites are another

strong example that requires a network effect for delivering better value.

If the new product belongs to category (i), then PRD should outline initiatives to create

an ecosystem that has the potential to harness a network effect. In the case of the new

product belonging to category (ii), Product Manager has to explicitly outline dependency

on product ecosystem in the PRD and outline the plan to monitor the evolution of product

ecosystem under ‘Monitor Plan’. PRD should also capture associated risks in the ‘Product

Planning Phase’. Subsequent sections elaborate both ‘Monitor Plan’ and ‘Product

Planning Phase’ in detail.

The earlier definition of product ecosystem augurs well if the new product creates either

a network effect or dependent on the network effect. Please note that not all new

products either require creating a network effect or dependent on the network effect.

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

i) What – Smartphone requires front camera

ii) Why – For selfie, video calls etc.

PRD would not define exact specifications for the camera. PRD would only define what a

camera should do and why it should do. However, ‘What’ and ‘Why’ would provide

enough ammunition for engineering team to derive the specifications for the camera –

what is size of the lens, what is length of optical zoom, what are different modes to be

supported etc. ‘What’ and ‘Why’ of each feature would set the scope and it should tickle

creative minds of engineers to formulate the ‘How’. Doing so, the product developed will

be in alignment with the exact purpose. Just as movie script enables actors to visualize

the movie, PRD should provide such visualization of the new product.

Page| 96

www.ProductGuy.in


I came across this article (http://www.actuationconsulting.com/actionable-product-

teams-requirements/) and was appalled to find that only ~15% of the Product Managers

provide the right level of details and actionable requirements. Providing right level of

details for all the product requirements is one of the single most important responsibility

of Product Manager. Unless requirements are actionable and unambiguous, the final

product might not be the same as the product envisioned during the business review.

PRD is not just about drafting requirements; it is also about communicating the bigger

vision and purpose. The purpose defines the reason behind building the new product.

PRD will also outline the value proposition that will drive customers towards the new

product. The value proposition will guide engineers on how to build the new product.

Yet, is PRD necessary? A million-dollar question for which I do not have a direct answer.

Many industry veterans in Silicon Valley have univocally expressed their opinions that PRD

is dead. I have already provided a hint that PRDs might not work for hazy markets with

lots of uncertainty around customer needs. The need for PRD depends on the nature of

the market along with the complexity of the product. Evolving market might not be the

focus of every new product. If the needs are clear and with a small share of unknowns or

assumptions and if the product is complex, I would suggest following the path of PRD.

Otherwise, please proceed with a minimal version of PRD (lean version) that outlines

requirements for MVP. MVP will validate assumptions around product-market fit,

customer needs and their behaviors and continuously evolve the product through a

feedback loop of build, measure and learn.

Discovering needs is a journey

Discovery of needs does not stop with building the new product it is a journey across the

entire lifecycle of the product. There should be exclusive focus on discovering and

understanding as many customer needs as possible independent of the product vision,

strategy and objectives. Product Manager is not a lone entity in the process of discovering

needs even though (s)he is exclusively responsible for discovering needs, corroborating

needs and sometimes synthesizing inputs from various disparate sources to formulate a

need. Product Manager should target for a collaborative discovery of needs along with

engineering team, sales team, support team, account team, and business development

managers to ensure that all possible needs are discovered. Collaborative discovery of

Page| 97

www.ProductGuy.in


needs will ensure that exhaustive set of customer needs are discovered and understood.

It might sound cliché, the truth is Product Manager does not have an authority to demand

that every stakeholder has to discover needs and Product Manager cannot set goals for

discovery of needs to each stakeholder. What I had mostly observed is that when Product

Manager walks that extra mile to facilitate Sales Manager close deals, help Account

Manager maintain better relations with their customers, and aid Engineering Manager

and his team accelerate development of better products, entire stakeholder will also walk

that extra mile in assisting Product Manager to build better products.

Well-orchestrated discovery of all possible needs through broader understanding and

anticipation of customer business challenges, pain points and business outcomes, later

converting those needs into product requirements is the ideal starting point. However,

the ultimate goal is to prioritize those product requirements through drafting a great

product roadmap in alignment with overall product vision, strategy and objectives. Unless

Product Manager discovers and understands the entire gamut of unmet, untold, latent,

overserved and underserved needs, translates them into product requirements, process

of prioritizing product requirements will not be effective. Product Manager can only

prioritize what (s)he has discovered, so it is ideal that Product Manager discover right set

of exhaustive needs through collaborating with other stakeholders. The foundation for

evolving a product readily embraced by target customers and which does not decline

prematurely rests on effectively formulating the product roadmap with right set of

requirements prioritized at right time intervals.

Role of great product roadmap - Translating strategy into action

Launching the new product successfully is a beginning phase in the overall lifecycle of the

product. Product Manager should immediately start evaluating product-market fit

through quantitative and qualitative methods, change strategies in alignment with

findings of those methodologies until the fit is determined. Upon reaching the product-

market fit for the new product, Product Manager should target to put the product on

growth trajectory. Later, whenever market changes, customer preference changes,

technology changes, Product Manager will change the overall direction of the product to

accommodate the new landscape. The foundation upon which the product is built seldom

changes, but what new needs to address, which markets to target, which customer

segments to go after, what technology to embrace will change depending on the new

landscape. Product Manager attempts to accommodate those dynamics through

Page| 98

www.ProductGuy.in


formulating product strategy, while product roadmap plays a crucial role in executing the

strategy.

Product roadmap is a plan that outlines a series of tactical steps in alignment with product

strategy to push the product ahead in the trajectory of planned direction. Every product

should have a vision that defines the purpose and reason for existence of the product and

where the product should be heading. Strategy would then define a path to get there by

drafting a plan of action detailing how to get there. The strategy involves aspects related

to both product and non-product (e.g. marketing campaigns, support, pricing etc.).

Product roadmap captures part of the strategy related to product. Product roadmap is a

plan of action that reflects product strategy.

Great product roadmap evolves from product vision and product strategy. Further, it acts

as one of the single most important document that provides a unified and consistent view

of where the product is heading to all the concerned stakeholders (Engineering Team,

Sales Team, Account Team, Business Development Team, Sr. Management, Customers

and Partners).

Product vision and strategy should provide a framework and guidance for preparation of

Great product roadmap, and it should be the overarching principle that governs the

process of preparing product roadmaps. Process to preparation of GREAT product

roadmap involves a series of linear and nonlinear activities planned and executed

meticulously by Product Manager. The process is also collaborative comprising of all the

stakeholders either directly or indirectly involved with the product. The process triggers

with discovery of needs through broader understanding and anticipation of customer

business challenges, pain points and desired business outcomes. Discovery of needs is a

never-ending activity and Product Manager periodically branches out a linear set of

activities from discovery of needs to perform the following

Convert needs into requirements

Draft requirements into PRD (Product Requirements Document)

Categorize requirements into tactical, strategic, and disruptor categories

Identify percentage split for each of those categories

Socialize requirements with engineering team,

Derive metrics for prioritization of requirements using scorecard methodology and

Ruthlessly prioritize requirements balancing both short-term and long-term

objectives in alignment with the product strategy.

Page| 99

www.ProductGuy.in


In addition, Product Manager should evaluate the efficacy of product roadmap and should

provide a mechanism to reinforce the feedback back into prioritization process for

effective and efficient prioritization of product requirements.

I have covered in details all the above topics in my eBook - ‘Translating Product Strategy

into Roadmap’. The downloadable copy is available at www.ProductGuy.in/eBooks.

Product Managers should truly demonstrate technical leadership

While drafting PRD, discussing requirements, finalizing product architecture or

formulating platform strategy, Product Manager has to demonstrate superior technical

leadership gaining the trust of the development team. In addition, Product Manager

should also display great depth of market insights and superior knowledge of the

competitive landscape. Otherwise, it is tough to gain the trust of all stakeholders. Without

trust, it is not possible to reach consensus on the vision of the new product and

development team might not buy into the vision of the new product. Even though it is a

cliché, I have to re-iterate that Product Manager has no real authority or power. So mutual

respect, trust, and admiration is the key to influence other stakeholders and sell the vision

of the new product. Position or authority does not gain us mutual respect, trust, and

admiration but actions, thoughts and deeds do. It might take some time to forge such

relationship but once built it will only fuel more product success stories.

Product Manager interacts with lots of entities – Sales Team, Account Managers, Analysts,

Business Development Managers, CEO/ CFO/ VP etc. Each entity speaks their own

language, so the onus is on Product Manager to be multi-lingual and converse with each

entity in their own language. The language of engineering team is laced with technical

jargons, while sales team with pipeline deals, revenues forecast, targets, estimates etc.,

account team with customer satisfaction index, executive team with vision etc. Product

Manager should be proficient in the language of each entity. The structure of Product

Management Organization should be like a hub and spoke model as outlined above,

where Product Managers are at the hub to gather and analyze data from multiple sources

Mutual respect, trust and admiration is not

formed by position or authority but by actions,

thoughts and deeds

https://www.slideshare.net/merragun/pragmatic-guide-for-preparing-great-product-roadmap

https://www.slideshare.net/merragun/pragmatic-guide-for-preparing-great-product-roadmap


Page| 100

www.ProductGuy.in


and disseminate information to every source that requires it. Product Manager will

disseminate information to various sources in a format that each source understands.

Figure 12 - Product Manager Relation Cycle

Technical leadership does not mandate Product Manager to take decisions on behalf of

the engineering team, engineering team drives technical decisions and they exclusively

own it. However, Product Manager should have the ability to grasp what and why behind

those decisions. Product Manger should be comfortable with technical jargons while

talking with engineers, engineering team should feel as if they are talking to one of their

own and not with any alien. Another aspect is that there is no expectation upon engineers

to understand business. They are entitled to own solution space while Product Manager

owns problem space. It is the responsibility of Product Manager to bridge those two

worlds by developing a thorough understanding of the technology, market, and

customers and understand whether the proposal of engineering team will address the

real problem. Product Manager should also assess the implications of any decision by

Product Manager

Sales

Engineering

Marketing

Account Managers

CEO/ CFO/ VP-Product

Analysts

Page| 101

www.ProductGuy.in


engineering team during product development phase to the overall vision of the new

product that defines what needs to address and how to address them.

Delivering awesomeness – Albeit selectively

Great products do not attempt doing everything right, they do extremely well on aspects

that fall under a zone called ‘SWEET SPOT’. The sweet spot is the intersection of critical

customer needs and corresponding product features that address those needs. Product

Manager has to ensure awesomeness of only finite set of product capabilities that fall

under sweet spot while ensuring that the remaining product capabilities meet standards.

It would be extremely unworthy to attempt absolute perfection of the entire new

product. The toughest part is not in delivering awesomeness, the toughest part is

probably in identifying the sweet spot. Product Manager has to strive to identify the exact

sweet spot that will attract customers towards the new product. Sweet spot need not

essentially be product functionalities. It can also be certain product attributes like brand

value, user experience etc. that drive customer preferences towards the new product.

The entire idea is to focus on some specific aspects of the new product that can influence

customers buying decision and accomplish utmost excellence in delivering them. Product

Manager should pick that one thing that drives customers’ preferences towards the new

product and should deliver it awesomely well that exceeds customer expectations way

ahead.

Apple is a classic case study to emulate for any new product development initiative. To

understand why we need to have this conversation and why it is relevant to the topic of

delivering selective awesomeness, let us look at the below comparison between Nokia

Product Manger should be comfortable with

technical jargons while talking with engineers,

engineering team should feel as if they are

talking to one of their own and not with any alien

Pick that one thing that drives customers’

preferences towards the new product and deliver

it awesomely well that exceed customer

expectations way ahead

Page| 102

www.ProductGuy.in


N97 and iPhone (1st generation). Nokia phone looks comparatively better on paper. Yet,

it lost the war and we all know why.

Nokia N97

Apple iPhone

Operating System Symbian S60 5th

edition

iPhone OS

Locked No Yes

SMS forwarding Yes No

MMS Yes No

Colors White and Dark Gray Black and White

Input Slide-out Keyboard On-screen Keyboard

File transfer Yes No

Camera 5MP with flash 2MP without flash

Video Recording Yes, DVD quality No

WiFi and GPS Yes, with electronic

compass

Yes

Removable Battery Yes No

Memory 32GB with microSD 8GB or 16GB only

Price $600 $700 (unlocked)

Table 2 - Product comparison chart of Nokia N97 and Apple iPhone17

17 Source: http://www.sizlopedia.com/2008/12/09/nokia-n97-iphone-comparison/

http://www.sizlopedia.com/2008/12/09/nokia-n97-iphone-comparison/

Page| 103

www.ProductGuy.in


Nokia N97 was released after Apple iPhone (1st generation), if the above matrix was

prepared by Nokia Product Manager and presented to the executive team of Nokia while

N97 was conceived, everyone would have assumed that Nokia has a winner on hand

because they have got every aspect of the product right. We all know what happened and

it is definitely worth looking at history and seriously ponder at our approach of building

new products.

Even when Apple released its 1st generation iPhone, iPhone was miles ahead of the

competition in only one aspect and it is user experience. However, other basic elements

like an irremovable battery, no MMS support, no file transfer, no support for

cut/copy/paste etc. were missing. Lack of those basic functionalities garnered many bad

reviews. However, those reviews did not affect iPhone sales. I guess everyone at Apple

would have believed that lack of those basic functionalities should not influence

customer-buying behavior. Apple apparently knew where to place their bets. Assume for

a moment, you are Product Manager of Apple, what would be your reaction over

releasing iPhone without lack of those basic functionalities. Most of us think of doing

everything right because we really do not know what influences customer behavior. Most

of us would prefer to place safe bets. Safe bets are not synonymous with building great

products. Likewise, doing everything under the sun and doing all of them perfectly is also

not synonymous with building great products.

If Organization had to take some serious bets during new product development, it is

important to abide by the following tenets

Never be scared to think big and fail, but fail too quickly and early.

Never shy away from conducting experiments to understand customers’ behaviors

and their needs.

Develop great insights about market, technologies and understand the potential

that they might offer

Never blindly chase competition

More importantly, never be scared to think bold and think future

Doing everything under the sun and doing all of

them perfectly is not synonymous with building

great products

Page| 104

www.ProductGuy.in


Adhering to the above tenets can help Product Manager identify SWEET SPOT to deliver

selective awesomeness. Product Manager should always know the one thing that the new

product should do awesomely well which in turn will drive customer preferences towards

the new product. Sweet spot could also be the unique value proposition that the new

product delivers and it should comfortably differentiate the new product from the crowd.

Final Word: Success of this phase lay in effective discovery and understanding of

customer/market requirements, adding them to PRD and prioritizing them

appropriately for 1st release. Product Manager should have absolute clarity on what

combination of features would facilitate the new product to make $$$ within the

framework of product beliefs and purpose.

Page| 105

www.ProductGuy.in


Drafting PRD Checklist

Foundation for the PRD

What is the purpose of the new product both from the perspective of customers

and Organization? Why Organization should build the new product?

Why customers need the new product?

How do customer needs evolve?





Defining attributes

What are the key value propositions valued most by target customers?

What are targeted vectors of differentiation?

Drafting requirements

‘WHAT’ product features are required, ‘WHY’ they are required?

Has every product requirement outlined in PRD is actionable?

Has Product Manager elaborated every product requirement in detail?

Has Product Manager tagged priorities for every product requirement?

In case of new product to the existing product line

What set of functionalities of existing product line will be inherited by the new

product?

What set of inherited functionalities will be altered to increase the scope, make

it simple, or make it better usable?

What are the drawbacks or inefficiencies of existing product line either

eliminated or improved in the new product?

What are the synergies between existing products and the new product within

the same product line?

Is there a need to bring-in any new functionality or new technology to align with

customer value proposition and differentiation?

Page| 106

www.ProductGuy.in


Whole product approach

What are the non-product attributes that would influence a sale?

What are the elements of product ecosystem?

o Is the new product driving an ecosystem or thriving on an ecosystem?

Page| 107

www.ProductGuy.in


Monitor plan

While conceptualizing the new product, Product Manager always makes assumptions

based on both quantitative and qualitative analysis of the following

Total addressable market and growth rate

Customer value proposition and differentiation

Competitive analysis

The purpose of monitoring plan is to constantly revisit the above items and ensure that

earlier findings are intact by explicitly trying to figure out the answers to the following

queries

Is it still a growing market – Any socio-economic, regulatory or any other macro

factors have stalled growth or have any possibility to stall growth?

Are customer preferences remain same?

o MVP can validate customer preferences, but the validation process would

be limited to the scope of what the new product delivers. Remember faster

horses, customers never really know what they want. Customers were

happy with Nokia and Blackberry at least until the launch of iPhone.

Customer preferences towards touch screen changed with the launch of

iPhone. In this section, the idea is to keep a tab on changes in customer

preferences because of external factors.

Is any competitor launching a better product(s) ahead of the proposed new

product launch or planning for a new product launch?

Market, product and solution hypotheses validate assumptions that directly affects

product development. PRD is already tracking those hypotheses. The focus of monitoring

plan is on the identification of external factors that affects the success of the new product.

It is hardly possible to relate those external factors directly to product development. In

this section, the focus is purely on factors that Product Manager do not control either

directly or indirectly but should be monitored and accordingly pivot or preserve new

product development.

Keep a tab on macro factors

Product development takes longer duration especially with HW products and it would be

insane on part of Product Manager to assume that none of the macro factors affecting

Page| 108

www.ProductGuy.in


the new product (either directly or indirectly) changes during the phase of product

development. So evaluating macro factors constantly is MUST. In a perfect academic

language, 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 effect that changes in macros

factors can have on the commercial success of the new product.

I reiterate that the focus is exclusively on monitoring factors that Product Manager does

not control either directly or indirectly but it affects the outcome of building the new

product and the outcome of how the market will embrace the new product. Therefore, it

only makes sense to keep watch on them and consciously be aware of the influence that

they can have on the new product development. Any changes require conscious effort to

relook at the entire new product development plan.

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

The success of this phase lays in the ability of Product Manager to take rational decisions

based on the outcome of monitoring phase analysis. Nevertheless, often Product

Managers’ emotional attachment to the new product make it tough for them to take

some extreme measures like killing the new product even before the launch. For instance,

a new regulation might make the new product unlikely to sell after a couple of years. In

such case, if the decision is to kill the new product because building the new product and

selling it for a couple of years is not viable financially, then Product Manager has to

promptly take a call and derive a product exit strategy. New product development is

always exciting, while Product Manager has to be passionate about building the new

product (s)he should not get emotionally attached to it.

Product planning phase will outline monitoring plan to track activities related to

development schedule and development costs etc. Those activities do not come under

the scope of the current phase. Program Manager own those items and (s)he will track

Product Manager has to be passionate about

building the new product but (s)he should not get

emotionally attached to it

Page| 109

www.ProductGuy.in


them diligently during product development phase. More details about product planning

phase in the subsequent section.

Product ecosystem – Is it ready?

From a timing perspective, Product Manager has to figure out whether product

ecosystem is conducive for the success of the new product. For instance, in the case of

first mobile payment product like m-pesa targeting rural population, the success really

depends on the density of mobile usage among the rural population and network

coverage in rural areas. SPOT (Smartwatch by Microsoft) is a classic example of a product,

released way ahead of its time. The product ecosystem had not been conducive to the

success of SPOT. The discussion brings us to back to the topic of product ecosystem

discussed during ideation. While timing the new product, Product Manager has to ensure

that the readiness of the product ecosystem is in alignment with the new product release.

I have elaborated more on this topic (especially about network-effect) earlier in ‘Detailed

requirements gathering – PRD’

Pipes vs Platforms

While talking about product ecosystem, it always worthwhile to identify whether the new

product belongs to pipes or network category18. In case of product belonging to network

category (classic example is app store), there are 3 players

1. Producer (App developers)

2. Consumer (Android Mobile Users) and

3. Platform facilitator (Google Play Store)

Identify what role the new product plays. If it is a producer, then success is dependent on

the vibrancy of the platform and Product Manager can hardly exercise any control on it.

Product Manager can only monitor the platform and accordingly should evolve product

development plans.

If the product is a platform facilitator, then the success of the product is dependent on

the strength of producers and consumers contributing to the platform. There should be

an explicit strategy to build a platform with sufficient producers and consumers. It is

18 Source: http://www.wired.com/insights/2013/10/why-business-models-fail-pipes-vs-platforms/

Page| 110

www.ProductGuy.in


typically a chicken-egg problem. Without producers, there would not be any consumers.

Without consumers, there would not be any producers. Without either of them, the

platform will never thrive. Product manager building a new product targeted to create a

network effect has to break the jinx to create a stronger ecosystem of producers and

consumers. One of the reasons for the failure of Nokia and Blackberry is that its app store

did not attract sufficient producers. A strong platform should also create barriers to entry

for any new player. Product Manager should have drafted the strategy to create a

network-effect in PRD. In monitoring plan, Product Manager should outline the plan to

monitor the progress.

Connect the dots

I did earlier talk about how small changes could coalesce together to create a much bigger

change. In that context, I did focus on identifying causal factors that when combined

together by known or unknown catalyst elements will result in bigger changes. As part of

the monitoring plan, Product Manager has to identify those causal factors, keep revisiting

the list as new factors emerge and old factors nullify. Product Manager through

consciously monitoring those factors can constantly strive to connect the dots to identify

how future might unfold and accordingly evolve the product continuously.

Final Word: Excitement of new product development should not steer Product

Manager away from ground realities and when macro factors does change there should

be conscious effort to introspect whether the new product will succeed.

Page| 111

www.ProductGuy.in


Monitor Plan Activity Checklist

Non-product assumptions

Is it still a growing market – Any socio-economic, regulatory or any other macro

factors have stalled growth or have any possibility to stall growth?

Are customer preferences still the same?

o Are customer preferences still in alignment with value propositions of the

new product?

Is any competitor launching better product(s) ahead of us or planning for new

product launch?

What macro factors determine commercial success of the new product?

o Have any of those factors changed during product development phase?

o Do those changes affect success of the new product?

Does the new product belong to pipes or platforms category?

Does the new product need an ecosystem to succeed?

Can we identify potential causal factors and catalyst elements that can combine

those factors to cause bigger changes?

o Can we connect the dots to identify how markets evolves, how

technologies evolve and how customers’ needs and their behaviors

evolve?

Macro factors can be socio, economic,

regulatory, technology etc. For instance,

regulatory changes might affect success of

the new product. In case of car, increase

in fuel prices might hit sales of cars

Validate all assumptions

periodically and perform

unbiased introspection to

assess the impact of changes

to the new product

Page| 112

www.ProductGuy.in


Product planning

Product planning phase is very critical phase in the entire product development for three

simple reasons

1. Product Manager will further refine business plan validating assumptions,

eliminating unknowns, mitigating risks and deriving precise details about

development costs, release timeline etc. So Product Manager could exhibit due

diligence in validating the financial viability of building the new product and

technical feasibility of building it right once again in this phase. In addition, Product

Manager could also validate whether the new product is addressing the real need

post the successful validation of marketing hypotheses while discovering and

gathering requirements.

2. Program Manager drafts a detailed and elaborate development plan to ensure that

the engineering team will build the new product as envisioned within the budgeted

cost and without any schedule slip.

3. Engineering team provides a firm commitment that they can build the new product

as envisioned during business review within stipulated time and cost.

Figure 13 - Product Planning Phase - Timeline

Planning phase lays the foundation for building the product right. While earlier phases

have exclusively focused on what to build and why to build i.e. building the right product,

Product Planning

T1 T0

Discovering Needs – Drafting PRD

Vendor Finalization

Validating Market Hypotheses Freeze Product Requirements

Business Review

Formulate Hypotheses

(Product/ Solution)

Discovering Needs – Drafting PRD

Page| 113

www.ProductGuy.in


product-planning phase lays the foundation for how to build the new product i.e. building

it right. Part of the product-planning phase related to validating hypotheses (most

importantly market hypotheses), evaluating the technical feasibility of building the new

product and identifying vendors or partners (both HW and SW) for various components

of the new product should have happened alongside discovering needs and drafting PRD.

Formulate hypotheses

There will be many unknowns while developing the new product. Even though I have

proposed to freeze the list of requirements rolled out in version 1.0 of the new product,

it is highly unlikely as there would not be absolute clarity on how some features might

affect customers or how engineering team should develop those features. It is essential

to obtain absolute clarity even before those features are developed. There should be

certain mechanisms to differentiate requirements with absolute clarity from

requirements with little or no clarity. The list of unknowns and hypotheses to validate

those unknowns are broadly categorized into three types

Market hypothesis – Is the product addressing the right market? Is the need real?

Solution hypothesis – Is the product addressing the right need?

Product hypothesis – Is the product desirable by customers?

At every step of new product development, ask yourself whether you are building the

right product for the right market to address the right need. How do you know whether

you are correct? Do your claims based on some set of invalidated assumptions or are they

backed by some strong quantitative and qualitative data to reinforce your beliefs.

Introspect candidly and never be afraid to go wrong. If there are any doubts lingering in

your mind and if the claims are based on a set of invalidated assumptions, identify what

assumptions to validate and how to validate – start constructing a hypothesis. Imbibe the

aforementioned methodology into every aspect of new product development to

formulate an exhaustive list of hypotheses.

At every step of new product development, ask

yourself whether you are building the right

product for the right market to address the right

need

Page| 114

www.ProductGuy.in


During the planning phase, Product Manager has to pick the most critical hypotheses that

will be a blocker for developing the new product and validate them even before product

development commences. For instance, Product Manager has to validate the existence

of a need or reality of a need even before attempting to build the new product. Whereas

validation of solution hypotheses and product hypotheses can happen during product

development in a rigorous cycle of build, measure and learn as outlined by Eric Reis in his

book – ‘The Lean Startup’. Doing so, Product Manager is ensuring that the new product is

addressing the right need and as desired by customers.

During the planning phase, for each hypothesis Product Manager has to outline what to

learn, accordingly (s)he will structure what to measure and how to measure. How to

measure will lay the foundation for what to build. As new product development phase

passes through each cycle of build, measure and learn, the number of unknowns should

gradually decline and there should be absolute clarity on what to build, how to build, why

to build and for whom to build. If the unknown list is staying either intact or growing even

after successive cycles of build, measure and learn then there is something fundamentally

wrong in estimating what to learn and formulating the steps for how to learn. Eventually,

everything else will slowly fall apart and the entire efforts to eliminate unknowns will be

a colossal waste.

Effective validation of each hypothesis lays in formulating a testable hypothesis and

precisely outlining the objectives of validating each hypothesis. The outcome of each

hypothesis validation should be binary and it should cause the new product development

cycle to either pivot or preserve.

Vendor/partner selection

It is not possible to build the entire new product in-house. To reduce TTM or to leverage

the expertise of outsiders, we pick vendors or partners who can be part of new product

As new product development phase passes

through each cycle of build, measure and learn

all of the unknowns should gradually decline and

there should be absolute clarity on what to build,

how to build, why to build and for whom to build

Page| 115

www.ProductGuy.in


development. Vendors provide HW or SW components for the new product and

relationship with such vendors should ideally exist for entire lifetime of the new product.

Partners can co-exist to help develop the new product. For instance, we can bring in

experts for UI/UX design and development. Partners do play a role for stipulated period

during the lifetime of the product to extend their unparalleled expertise. Partners can

also exist to integrate the new product with their products for delivering better value to

customers, in this phase we do not exclusively focus on such kind of partnership. Product

Manager can actively scout for such partners (if required) in the later phase of new

product development. Vendor or partner selection is a process involving Product

Manager, engineering team (both SW and HW), HW manufacturing team (if HW is

involved), marketing, finance and legal team.

Request for proposal (RFP)

The process starts with identifying the list of new product components that has to be

outsourced. It could be either HW or SW components or expertise to help build

specific elements of the new product. While engineering team will list down all

functional requirements in RFP, Product Manager will list down all non-functional

requirements. The assistance of legal team is required to validate that the RFP is legally

binding with all necessary disclaimers. RFP should minimally comply with the following

Outline all functional requirements that should be complied by prospective

vendors or partners.

Outline all non-functional requirements (customer references, financial

statements, compliance certificates etc.), to validate partners or vendors position

in the market and their ability to honor commitments.

Outline all requirements pertaining to support and precisely indicate all SLAs

(Service Level Agreements).

For expertise, outline what expertise is required and outline what nature of work

partners will accomplish. Ask for references of their prior work in similar domain.

Outline explicitly, if any product samples are required. Put explicit disclaimers that

obtaining product samples does not amount to selection of vendors or partners.

Identify prospective vendors/partners

Identify the list of vendors/partners and extend an invitation to participate in RFP.

Procurement team can provide the exhaustive list of pre-approved vendors and

partners

STEP

2

STEP

1

Page| 116

www.ProductGuy.in


Validate responses

The engineering team has to validate functional responses obtained from all

partners/vendors. If partners/vendors have sent product samples upon request,

then engineering team has to complete validation of those samples as well.

The engineering team has to formally present the outcome of their analysis and

outline their choice of partners/vendors based on the evaluation of functional

responses and validation of product samples.

Product Manager has to identify whether all partners/vendors comply with non-

functional requirements. Procurement team can help assess the responses to non-

functional requirements and ascertain the veracity of each partner/vendor to

honor their commitment.

Manufacturing team should be involved when Product Manager releases an RFP

to procure an HW component.

Selection of vendors/partners

Selection of vendors/partners is a little-complicated process, as we do not select

them purely based on the recommendation of the engineering team.

‘Known devil is better than unknown angel’ statement holds good especially with

the selection of vendors/partners. Procurement team inputs do highly matter

during the selection of vendors/partners. Product Manager might mostly lean

towards the choice of procurement team provided the recommended

vendor/partner is at least close to satisfying the functional requirements. May be

the response from other vendors/partners could be used to negotiate with most

prospective vendor/partner to get a better deal. At least in the case of vendor

selection where the relationship is entitled to an entire lifetime of the product, it

is always better to choose a vendor who can honor commitments. Chosen vendor

should also maintain amicable relationship with the Organization. Procurement

team always play a vital role in identifying such an amicable partners/vendors,

while Product Manager will take help of engineering team to identify who among

those amicable partners/vendors will be ideal fit in accordance with their

compliance of functional requirements.

Product Manager finalizes the list of vendors/partners after deliberation with lots

of stakeholders. Finally, Product Manager should work with legal and finance team

to formally sign an agreement with chosen vendor/partner.

STEP

4

STEP

3

Page| 117

www.ProductGuy.in


Freeze product requirements

The most important task during ‘Product planning’ phase is to freeze the list of features

that should constitute version 1.0 of the new product. PRD contains an exhaustive list of

requirements. Considering TTM (Time to Market) and constraints of engineering

resources, not all features could make it to the final list. Even though PRD might provide

some details on what features are not important for version 1.0 by clearly marking the

priority of each feature, the task is not as simple as it might sound. It involves many tough

decisions, negotiations, trade-offs. In the case of B2B products, it takes time to gain

adoption and peak revenues. So more often quicker TTM would be preferable, so trade-

off need not necessarily be feature1 vs feature2 but between later TTM (with feature1

and feature2) vs early TTM (without feature1 and 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 features that

contribute to those defining attributes. Instead, Product Manager could compromise on

other aspects like higher performance in version 1.0 and support them in a later release.

The final list of features has to be ultimately approved by Product Manager and (s)he has

to be sure that the frozen list of features along with defining attributes would provide

compelling reasons for customers to buy the new product. Negotiations or persuasion

skills are need of the hour for Product Manager to ensure that the right set of features

make it to the final list.

I have earlier spoken about delivering awesomeness. Product Manager should clearly

articulate what aspects of the new product should engineering team build exceptionally

well. PRD should capture those details. During product planning phase, both Product

Manager and engineering team should mutually agree upon what elements of the new

product should reflect awesomeness while maintaining standards on the remaining

elements.

Meticulous planning

During the planning phase, program manager has to involve all stakeholders and draft a

detailed plan not only for the development of the new product but also for other allied

activities such as documentation, compliance, royalty, intellectual property (if any),

supply chain, vendor finalization, GTM, pricing etc. The Program Manager has to derive a

meticulous plan for the development of the new product, so (s)he can catch any

deviations or surprises much earlier in the product development cycle. Another critical

Page| 118

www.ProductGuy.in


aspect of the planning phase is to identify all possible risks (budgeting, vendor

management, product performance, compliance etc.) and assumptions. Program

Manager has to outline the deadline to eliminate unknowns, mitigate risks and validate

assumptions. However, the deadline has to be early in the product development cycle so

in the event of any major surprises there will be sufficient time to implement mitigation

plans.

Vendor/partner selection process is time consuming and to ensure that the list of

vendors/partners are finalized before the actual start of new product development, the

process of selecting vendors/partners should happen simultaneously alongside

discovering needs and drafting requirements in the PRD.

Metrics, metrics, and metrics

Program Manager has to live and breathe metrics during the entire course of new product

development. Unless we measure, we cannot improve. Therefore, metrics are crucial

during product development. What metrics to define should depend on what to measure

and improve. From my perspective, I would suggest identifying all possible metrics that

could help engineering team understand whether they are building the new product right.

Moreover, how effectively and efficiently are they building the new product?

Has the team optimally utilized the resource for building the new product?

Has the team used the right amount of resources required to build the new

product?

Has Product Manager been prudent enough in providing absolute clarity on each

requirement?

How often does Product Manager change requirements abruptly? What is the

resulting impact on new product development? Has any SLoC (Source Lines of

Code) has been altered or removed?

How often has engineering team removed or modified source code because of lack

of coordination among them? How many lines of source code do engineering team

has removed or modified?

How often has engineering team deviated from specifications and built something

entirely different? The focus is not on the entire product but on the individual

features that constitute the new product.

Has the engineering team has to ever wait on Product Manager for clarity of

requirements? For how long?

Page| 119

www.ProductGuy.in


How often engineering team missed deadlines to commit source code?

How many issues seen per KLoC (Thousand Lines of Code) during new product

development? Is it within an acceptable range?

Has the engineering team has to ever wait to get product samples from

manufacturing for validating the new product?

Above questions might sound like a checklist but to affirmatively respond ‘YES’ or ‘NO’ to

some of them, Program Manager has to still collect a vast amount of quantitative data.

The above list is purely for illustration purpose. Program Manager has to prepare an

exhaustive list to measure holistically the efficacy of new product development. The list

would then determine the quantitative metrics to be collected during new product

development.

During new product development, Program Manager might be able to identify some

fallacies. Nevertheless, Program Manager might not be able to take corrective action in

entirety. The reason for collecting metrics and performing soul-searching for the above

questions will let Program Manager do a candid introspection of the entire new product

development and use the learnings to improve overall new product development process

to ensure high levels of efficiency standards while building subsequent new products.

Metrics defined by Program Manager do not necessarily engage in a feedback loop for

taking corrective actions during new product development. However, some of the metrics

collected by Product Manager especially related to the aspect of whether the team is

building the right product should engage in an active feedback to pivot or preserve new

product development. MVP to verify whether we are building the right product for the

right market and whether the new product is desirable to target customers is a classic

example of such metrics. MVP by itself is not a metric. Product Manager has to measure

the effectiveness of validating product, solution and market hypotheses. Product

Manager can do so by measuring the efficacy of both formulating and validating

hypotheses. Results of product hypotheses determines pivot or preserve scenario of

corresponding product requirements during new product development. Results of

product hypotheses should eventually eliminate all unknowns, validate all assumptions

and mitigate all risks. Otherwise, there is no efficacy in formulating and validating

hypotheses. Product Manager should also identify metrics to measure the efficacy of two

other primary activities (1) GTM – How effectively the message is reaching the target

audience? (2) Pricing – How effectively has the product been priced? Product Manager

Page| 120

www.ProductGuy.in


measures those metrics and act upon it continuously throughout entire product life cycle

of the new product.

Product acceptance criteria

Product acceptance criteria define a set of conditions or metrics that has to be satisfied

by the new product to qualify for an official launch and subsequently be eligible for

shipment to customers. Product Manager in coordination with Program Manager,

manufacturing team, engineering team, documentation team, compliance team and

other relevant stakeholders should define the acceptance criteria for the new product to

ensure that the new product meet every possible criterion that determines its commercial

success before it walks out of the gates.

Set of conditions outlined as part of acceptance criteria should be measurable objectively.

The conditions could be either KPIs (Key Performance Indicators) with an acceptance

value or range (for instance tolerance range of open issues with new product under

various severity levels) or it could be completion of a task (has pricing of the new product

completed and approved by finance? and has the new product met all required

compliances? etc.). The completion of tasks should be objectively qualified with a simple

‘YES’ or ‘NO’.

Product feasibility validation

I spoke about ‘RISKS’ in an earlier section under ‘Meticulous planning of new product

development’, the biggest risk is the inability to build the new product as envisioned

initially. In such case, Product Manager should ruthlessly kill the new product that does

not meet customer requirements instead of building and later selling it. The focus is on

how quickly Product Manager could decide to KILL the new product without consuming

too many resources in case of inability to build the new product as conceived. During

ideation process, Product Manager would have validated whether the new product can

meet customer requirements and whether a sizable amount of customers would buy the

new product to make sufficient margins. Product Manager also has to evaluate whether

development team could build the new product as conceived initially. During the business

review, the development team will do a high-level feasibility analysis and provide some

amount of confidence that they can build the new product as envisioned or

conceptualized. However, product development is invariably prone to surprises. Several

Page| 121

www.ProductGuy.in


Organizations abandon new products because of the realization mid-way through product

development that is it not feasible for the new product to address the real need. It

happens mostly in case of adapting new technology or building new product distinct from

traditional competencies of the Organization. In such cases chances of failure is high, but

what I am insisting here is that the Program Manager has to draft plans to quickly validate

the technical feasibility and validate the ability to build the new product as envisioned.

Accordingly, Product Manager has to decide whether to abandon new product

development before burning too much money. Suppose if AIRBUS is conceptualizing to

build a flight that can travel longer distance non-stop. It would not be wise for the

development team to assert that they will never know how long the flight can fly non-

stop until it the completion of building the entire flight. The development team has to

build some simulation tools that can help them estimate scale metrics without building

the actual product. Program Manager along with development team has to figure out

such tools to minimize the amount of money and time required to validate the technical

feasibility and to validate the ability to build the new product as desired by customers.

Evolve the business plan

During the business review, Product Manager in collaboration with other stakeholders

would have derived a high-level ballpark estimate (typically a bird’s view) of new product

development. Only during product planning phase, Program Manager will outline the

detailed plan and alert if there are any major deviations from the business plan derived

during the business review. For instance, if the timeline or total project cost or total

resources estimated during product planning phase drastically varies from business plan

derived during the business review. The objective of the business review is to provide an

approximation of whether it is worthy to pursue the new product idea after evaluating it

over three fundamental parameters (1) desirability (2) viability and (3) feasibility.

Honestly, what Product Manager attempts during business review is to construct a 1,000

feet level view of the entire new product idea and very less would have been discussed

and contemplated about the nuts and bolts of actual product development and other

associated tasks such as pricing, GTM, documentation, compliance, manufacturing,

supply chain etc. During the business review, a lean team constructs a 1,000 feet level

view of new product idea. As we progress through requirements gathering and product

planning phase, team expands to include more stakeholders to perform lots of

groundwork required to zoom-in to obtain a ground level view of every aspect of new

product development.

Page| 122

www.ProductGuy.in


Product planning phase adds better perspective to new product development plans. The

new product development plan is no more restricted to slides, everyone involved in the

journey starts adding some form and shape to that plan bringing in lot more clarity. From

1,000 feet level view during business review phase, Product Manager can narrow down

to ground level view during product planning phase. Therefore, it is rightly appropriate

for Program Manager to evolve the business plan to provide granular and precise

information on following critical items drafted at a high level during the business review:


What are the product development plan and its associated dependencies?

What features constitute version 1.0 of the new product?

The list of partners and vendors finalized for building the new product.

Are there any risks associated with new product development?

What are the plans to validate remaining product and solution hypotheses?

When can customers get an early trial version (Minimum Viable Product) of the

new product for validation in their environments?

What is the exact release date for the new product?

o In case of multiple products, the focus should purely be on the 1st product to

be developed

o In case of multiple products, the focus should be predominantly on how either

existing platform or new platform will be leveraged to build the subsequent

product(s) with lesser cost and quicker TTM

What are the GTM plans to communicate the value of the new product?

What are the pricing methodologies to capture the value of the new product?

What is the revised ROI?

I faithfully believe in the motto ‘Always prepare for the WORST and hope for the BEST’.

There is no better phase than product planning for religiously practicing it.

Finally, business review

The objective of the planning phase is not just to build the right product but also to build

it right. Formulating Hypotheses and validating them can corroborate whether we are

building the right product for the right market to address the right need. While rest of the

I faithfully believe in the motto ‘Always prepare

for the WORST and hope for the BEST’.

Page| 123

www.ProductGuy.in


elements of product planning phase like vendor/partner selection, product requirements

finalization, meticulous planning, metrics and product acceptance criteria can guarantee

building the product right.

During this phase, we try to obtain more clarity on items related to new product

development. Therefore, it would be wise to perform the business review once again to

ensure that new product development is justifiable absolutely on three fundamental

parameters (i) desirability, (ii) viability and (iii) feasibility. During the business review in

product planning phase, Program Manager has to outline with utmost clarity and

precision the following items:

Possible risks and corresponding mitigation plans,

Possible assumptions and corresponding plans to validate them,

Potential delays and their suspected causes,

Development costs (inclusive of development resource cost, cost to procure

HW/SW components required to develop the new product),

List of vendors/partners, release date, and timelines to validate MVP in a recursive

cycle of build, measure and learn.

Intermediate milestone dates to validate progress of new product development and to

conduct intermediate demos of the new product as it is developed to internal

stakeholders (at least primarily to Product Manager) should also be listed during the

review. In addition, Program Manager should engage with every entity responsible for

tasks associated with new product development such as manufacturing, supply chain,

documentation, GTM, pricing & ROI, compliance etc. to provide precise plans for each of

those activities during the business 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 new product

development and thereby triggering flawless execution of new product development

without major deviations.

The objective of planning phase is not just to

build the right product but also to build it right.

Page| 124

www.ProductGuy.in


Product Planning Checklist

Freeze Product Requirements

Has Product Manager froze the final list of product requirements for version 1.0

of the new product without any ambiguity?

Does development team have a complete understanding of every product

requirement that made to the final list?

o Does development team have a complete understanding of why those

features are required?

o Does development team have an absolute clarity on the defining

attributes of the new product?

Does the final list of product requirements provide enough compelling reasons

for target customers to buy the new product?

Can the new product still meet the revenue projections with planned set of

product requirements in version 1.0?

Product Planning

Have hypotheses to validate market, product and solution was outlined,

including methodologies to validate them?

Has detailed product development plan derived meticulously?

Have risks associated with building the new product identified?

o In the event of occurrence of those risks, has mitigation plans been

identified?

Have the assumptions associated with building the new product identified?

o Were there plans to validate those assumptions? If so, when and how?

The assumptions are in relationship with the product and not

associated with any non-product attributes. Non-product assumptions

are tracked under monitoring plan. Product assumptions are those

assumptions related to product capabilities and functionalities. For

instance, there could be an assumption that integration with specific

technology would achieve desired performance

Page| 125

www.ProductGuy.in


Has metrics to measure the efficacy of new product development identified and

defined?

Have product acceptance criteria to qualify the new product for customer

shipment defined?

Vendor/ Partner Selection

Has Product Manager and Program Manager together identified the list of new

product components outsourced to partners/vendors?

Has Product Manager and Program Manager together identified the list of

prospective vendors or partners who should receive RFP?

Floating RFP

Does RFP includes following contents?

o List of functional requirements

o List of non-functional requirements

o Nature of support required and list of precise SLAs

When RFP is released seeking expertise, does it outline exact expertise and exact

nature of work? Does it also seek references of prior work in similar domain?

Has RFP asked for product samples (if required)?

Is RFP legally binding?

Validating RFP Responses

Has engineering team validated functional responses of all partners of vendors?

If product samples were obtained? Has engineering team validate those product

samples?

Has engineering provided the results of their analysis?

Vendor Selection

Has product manager validated non-functional requirements in tandem with

procurement team?

Has the vendors and partners finalized based on the combination of their

responses to functional requirements and their prior history of working

relationship with the Organization?

Has a legal agreement finalized with chosen vendor or partner? Was finance

team involved in cost negotiation?

Page| 126

www.ProductGuy.in


Product development

The role of Program Manager is important during new product development and (s)he

plays a crucial role. especially during actual product development. However, it does not

negate the role of Product Manager and there are various activities exclusively performed

by Product Manager in parallel to product development for the success of the new

product. Most have an opinion that the role of a Product Manager during new product

development is at the start (i.e. the business review) and at the end (i.e. GTM, launch

etc.). However, majority of the works starts at the middle (i.e. product development) and

it is crucial to stay energetic during this phase. One of the key activities of Product

Manager during this phase is to coordinate with Program Manager to ensure that new

product development is on track without any delays. In the case of any delays caused by

delay in development or delay in supply of HW or SW components by any vendor etc.,

Program Manager will outline the possibility of schedule slip. Product Manager has to

figure out the risk due to delay in releasing the new product and immediately draft a

mitigation plan. Do Product Manager only have to keep track of product development

progress? If there is a proficient Program Manager and in any case, I believe, there should

be one, otherwise the development work is not streamlined. Program Manager could

alert Product Manager on possibility of potential delay or occurrence of major deviations

in the planned activities, and then Product Manager can act in accordance with the

situation.

So does Product Manager really have the luxury of holding back and waiting for alerts to

react? Definitely not, Product Manager has to hit the ground along with other

stakeholders to have a ground zero view of entire activities surrounding the new product

development instead of being content with bird’s eye view. Product Manager has to run

simultaneously along with engineering, manufacturing, legal, and finance or rather run

ahead of them to anticipate what problems they could probably hit, accordingly help

them pivot during new product development. Hitting the ground aids Product Manager

in faster decision making and guiding entire stakeholders involved in product

development appropriately by being aware of the ground realities.

Product Manager has to hit the ground along

with other stakeholders to have a ground zero

view of the entire activities surrounding the new

product development instead of being content

with bird’s eye view

Page| 127

www.ProductGuy.in


Hit the ground

Product Manager has to hit the ground to stay aligned with ground realities otherwise

(s)he does not know what elements are going wrong during the new product

development, why are they going wrong and how they should be rectified or mitigated to

minimize the impact. Program Manager while alerting Product Manager on certain

elements like potential delay in supply of HW or SW components can outline the impact

to the overall new product development. Program Manager will also be proficient to

outline multiple options within the purview of the new product development to mitigate

the delay. Nevertheless, program manager focusses on only one pillar of the new product

development i.e. ‘Creating Value’. Whereas Product Manager has unique responsibility to

connect the dots to create a mental map of how various options proposed by Program

Manager will impact the other 3 pillars of new product development i.e. ‘Communicating

Value’, ‘Delivering Value’ and ‘Capturing Value’. Another important aspect of hitting the

ground is that it provides the ability for Product Manager to start focusing on little things.

Product Manager chase new customers, track money flow, build pipeline etc., but seldom

focus on what makes customers unhappy with product, why product is not being evolved

at a pace it has to evolve, why customers are facing so many issues in spite of healthy test

results exhibited internally. What if the new product is excellent, but ordering sucks and

sales team lack the ability to communicate the value. If we do dig further into smaller

items, does the new product shipment contains all the required accessories and

instructions necessary to power-on and install the new product? The first shipment of

new product will obviously have software version 1.0. Often there would not be any

alignment between engineering and manufacturing, so even after few years of FCS,

manufacturing team might still ship the product with version 1.0, which is not practically

viable for customers to retain the software shipped with the product. Product Manager

has to take care of such nuances both during product development and even after FCS of

the new product. Focusing on little things will indirectly help Product Manager accomplish

desired results of higher rate of customer retention, higher rate of acquiring new

customers, increase revenues and market share etc.

As Ben Horowitz – author of ‘Hard things about hard things’ and Co-founder and partner

at Andreessen Horowitz VC firm, rightly said

Focus on the little things and the big things will take care of themselves.”

Page| 128

www.ProductGuy.in


Activity checklist

Product Manager either tracks or performs many activities outside the scope of product

development to ensure timely release of the new product. Jeopardizing a release because

Product Manger missing the deadline because of not completing at least one of those

activities is extremely catastrophic. Therefore, preparing a checklist and periodically

reviewing the progress is necessary. The checklist should predominantly contain the list

of items driven exclusively by Product Manager. I have listed down the basic set of

activities common for any new product development, especially HW product.

Product pricing

Support cost

Ordering

Creating part numbers

GTM plans

o Marketing collateral

o Datasheet

….

The above listed activities might not be exhaustive and the idea is to ensure that Product

Manager drafts an exhaustive list of activities in the form of a checklist, so (s)he does not

miss any activity. Product acceptance criteria could also indirectly provide the list of

activities Product Manager should either complete or comply to qualify the new product

for customer shipment. I would not shy away 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 Product Manager and Program

Manager do not duplicate the efforts of tracking activities. At least from my experience,

Product Manager would exclusively focus on the above listed activities while Program

Manager would focus on product development, supply chain, documentation,

compliance, vendor finalization etc.

Product Manager has to focus on the little things

and the big things will automatically take care of

themselves

Page| 129

www.ProductGuy.in


Each activity varies in complexity and duration taken to complete it. Product Manager not

only identifies the exhaustive list of activities targeted for FCS (First Customer Shipment)

but also drafts a plan to execute those activities to ensure all of them reach the finish line

simultaneously on the day of launching the new product.

Know the process

Every Organization has their own processes to complete aforementioned activities.

Product Manager should have a complete understanding of those processes including the

duration required to complete the activities that (s)he own exclusively. 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 first 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 Product Manager

should complete the activity 4 weeks before the first release, then essentially Product

Manager should target to start the activity 14 weeks before the first release date (4 + 8 +

25% of 8). Also, try to understand the dependencies between each activity and plan

accordingly. For instance, creating part numbers, deriving product cost and turning-on

ordering are mostly inter-related items of ordering tool. It is not possible to record

product cost without part number. While it is not possible to turn-on ordering, without

adding product cost and adding part number to ordering tool.

It might sound simple, but there is a higher probability for Product Manager failing to

ascertain the time taken to complete each activity and it happens primarily because of

lack of knowledge about internal processes. New product development is not an everyday

activity, so it is necessary for any Product Manager to undergo quick training on the list

of processes involved in new product planning and development.

Pricing

The most important aspect of pricing is appropriately monetizing the new product

without leaving any money on the table in an effective and efficient way. There are

various kinds of pricing (cost-based, value-based etc.). 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

Page| 130

www.ProductGuy.in


could justify the price. In the case of new product added to a new category, the price of

perceived alternative products could be pricing reference point.

In cost-based pricing model, the price of components used in the new product will come

down after reaching certain volumes or after a specific 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 breakeven period and duration of product

life cycle that will determine the product price as well. Another aspect to note in the

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 ideal to price

the product higher and later provide deeper discounts

In value pricing model, 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 xAAS pricing 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 a

mechanism to track licenses purchased by customers and validate whether the customers

are 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 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

The most important aspect of the new product

pricing is to ensure that Product Manager does

not leave any money on the table

Page| 131

www.ProductGuy.in


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 do not

change in the completely built product. For instance, the price of a hard disk is directly

proportional to its storage capacity and RW speeds etc. Seldom Product Manager does

not get the pricing right in the 1st attempt, it is better having some mechanisms to

evaluate the efficacy of the new product pricing and allow room for any changes even

after the product is released.

GTM activities

If you build the product, will customers come rushing to you? No, not without right GTM

strategy. Putting aside the range of GTM activities, Product Manager should realize the

primary purpose of GTM. The primary purpose of GTM is to have various channels

effectively communicating why the product does what it does and how effectively does it

does.

WHY? - focuses on customer problems or needs that necessitate the need for the

new product.

WHAT? - focuses on solution delivered by the new product to address the

customer problems or needs

HOW? - focuses on the value proposition. How effectively and efficiently does the

new product addresses customer problems or needs

Product Manager has to bring the new product closer to customers by appropriately

communicating its value. The primary intention of communicating product value is to

make customers believe in the product, believe in what it delivers. Communicating the

‘Why’, ‘What’ and ‘How’ of the new product is not about creating a booklet but about the

The primary purpose of GTM is to have various

channels effectively communicating why the

product does what it does and how effectively

does it does

Page| 132

www.ProductGuy.in


ability to succinctly tweet the message effectively or to deliver an elevator speech to grab

the attention of target audience. Any product essentially does lot many things and it is

not wise to dump all the information to customers during initial messaging. ‘Why’ and

‘What’ is all about picking the top three problems that the new product originally

intended to address and differently does it address them. Business review highlights top

three problems. Product defining attributes outlined during product requirement phase

would come handy to communicate ‘How’. The ‘How’ messaging should definitely strike

a chord with the target audience raising 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 new

product is at huge stake.

Next step is to identify the list of mediums (social media, events, blogs or traditional

methodologies such as print or TV) to communicate the value proposition to target

customers. In order to determine which methodology is more effective, identify the cost

and penetration rate i.e. what % of the target audience could be reached and at what

cost. Later, rank each methodology based on their effectiveness to reach the target

audience. 80:20 rule is an effective and efficient way to communicate new product value

proposition under budget constraints. 80:20 rule can create awareness about the new

product among 80% of the target audience using 20% of the budget. The ranking

methodology can help Product Manager choose right set of mediums for effective

communication of new product value proposition.

Final activity is to decide the timeframe to start communicating the value proposition of

the new product. The timeframe purely depends on right marketing strategy to create

sufficient momentum and interest among target customers for the new product. In

certain cases, there is a need for suspense factor and the details about the new product

remain secret until few weeks before the launch (e.g. iPhone). In other cases (mostly B2B

products), the suspense factor will be counter-productive and therefore the information

should be let out in bits and pieces pretty earlier to create a curiosity factor. I said ‘bits

The primary intention of communicating product

value is to make customers believe in the new

product, believe in what it delivers

Page| 133

www.ProductGuy.in


and pieces’ because if the communication is started during new product development

and most probably some of the details related to the new product 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 completely

analyzing the feasibility of building the new product with targeted benchmark

performance. Therefore, Product Manager will start messaging that the new plane will

travel longer distance non-stop while consuming less fuel, initial messaging will not shed

any more information on exact distance and fuel savings. The precise motivation is to

create enough buzz about the new product while effectively communicating the value

proposition.

All those messaging activities through various mediums should finally converge in a big

launch event for the new product inviting press, customers, and other stakeholders.

Probably the number of events would depend on the budget and geographic spread of

target audience.

I consider messaging to be primary constituent of the GTM activities, but there is also a

bunch of other activities including product training to channel partners, sales team etc.,

distribution network, product pages, support document, product images, field trials

launch plans etc. Product Manager alone would not be able to drive all of them, but he

has to draft a plan outlining activities and who will be in-charge for those activities and

timeline to start and completion of each of those activities.

Sales enablement

Sales enablement is a misguided topic in most Organizations. The focus of sales

enablement is often what to sell and how to sell. Traditionally, sales enablement is about

educating sales team on product capabilities. However, sales enablement has evolved

over years from merely focusing on educating sales team on product capabilities to

educating sales team on potential problems or use-cases that the product addresses. The

focus was later shifted to training sales team on the list of jobs customers could

accomplish using the product. Later, we moved a step further to understand what are

customers’ real needs and appropriately position the product exactly at the intersection

of problem and solution space. Therefore, customers exactly know how the product can

address their pain points. In certain cases, Product Manager did go a step further to

Page| 134

www.ProductGuy.in


facilitate sales team to demonstrate the exact product capabilities that can help address

customer pain points to gain customer confidence or to get involved in a PoC (Proof of

Concept) at customer site (especially in B2B segment).

However, all those efforts of sales team are in perfect alignment with making a better

sale. Nevertheless, there is another factor called competition. Competitive analysis is

objective with details on comparison of product capabilities. However, those details will

not help. Those details look good on paper but they do not provide real substance. It is

just a comparison of some tangible parameters. Competitors focus on what the product

does not do and build their defenses using those elements. Only Product Manager is

aware of why the product does not do what it does not do. Either those elements will not

help customer or they are not very critical for addressing in the first release. In any case,

Product Manager should anticipate how competitors will build their defenses against the

new product and should instill empower sales team with necessary knowledge and

acumen to break those defenses. Therefore, sales enablement is not just about

communicating what the product does and why, but it is also about communicating what

the product does not do and why.

As part of sales enablement, Product Manager should not just focus on what the product

does, why it does, what kind of jobs customers can accomplish using the product, and

how to demonstrate product capabilities etc. Product Manager should educate sales

team on why behind certain key decisions – why key capabilities were not included in first

release, why there is any deviation from standards. In my case, I had to educate sales

team on why we decided to build the new product on x86 platform as I was expecting

competitors to use it against the new product. Let us assume that the new product is

deviating from standards. It does not merely suffice if sales team is telling how well the

product can address customer needs in spite of deviation from standards. Yet, the

thought that the product is deviating from standards always linger on customers’ minds.

Sales team should be able to defend the decision, should articulate the WHY behind the

decision so customers can believe in us. Product Manager should provide enough

ammunition to sales team to thwart competition by breaking their defenses.

Whole product approach

Product Manager should look at the entire sale process and understand the factors that

might influence customers buying decision. Product capabilities alone would not

Page| 135

www.ProductGuy.in


influence a 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 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 (described by Geoffrey

Moore). The decision making process of 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 new product.

Considering that only 25% of new products complete product development phase,

Product Manager has to exhibit attention to details of little things and meticulous plan

during this phase. Otherwise, product development might go terribly wrong. The words

of Ben Horowitz ‘Take care of little things and the big things will take care of

themselves’ should strongly resonate with Product Manager during this phase.

Page| 136

www.ProductGuy.in


Product Development Checklist

Product development tracking

Is Product Manager periodically reviewing product development progress with

Program Manager? Is Product Manager ensuring that the new product

development is progressing as per initial schedule without any deviations?

o In case of schedule slip or occurrence of any risk, is the Product Manager

well equipped to take well-informed decisions (any trade-offs, mitigation

plans etc.) based on the information available with him?

Is product manager periodically reviewing the interim progress of developing the

new product and sharing the feedback without waiting until the completion of

final product?

o Is the product being built is in accordance with new product vision?

Product Manager Activities

Has Product Manager derived the list of activities targeted for completion before

FCS?

Does Product Manager have complete awareness of the timeline required to

complete each activity and stakeholders involved in the approval process of each

of those activities?

Has Product Manager identified dependencies between those activities?

o Has Product Manager identified start date for each activity in the light of

dependencies between activities?

I meant whether the new product

is complying with product

specifications, functionalities and

capabilities envisaged initially

Page| 137

www.ProductGuy.in


Pricing

What is the pricing model and business model?

Is the currently proposed pricing model different from earlier models? If so, does

the Organization have sufficient capability and infrastructure to implement the

new model?

Has the Product Manager priced the new product optimally without leaving any

money on the table?

What is the reference point (pricing of competitive product or pricing of

perceived alternate product) to compare pricing of the new product?

What are the margins, NPV, break-even period etc.?

Is there any mechanism to validate the efficacy of product pricing post the

product release?

GTM

What is the value proposition? Can we communicate the value proposition

effectively through a TWEET?

Who are target customers? What are the available mediums to communicate

value proposition to those target customers?

o What is the efficiency of each medium to reach target customers (cost vs

penetration)?

What is the budget estimated and what is the budget allocated?

If budget allocated is less than estimated, apply 80:20 rule.

Page| 138

www.ProductGuy.in


My experiences - What did we do differently

I would not categorically state that I did something unique. Rather what I did during the

entire course of new product development is sticking to basics of building the new

product. I never got overwhelmed by the entire process of building the new product, I

stayed calm, diligently did take care of all smaller details, planned meticulously. Most

importantly, I did ensure that I am in complete control of what I was trying to do.

Complete control not from the perspective of being authoritative but from the

perspective of being aware of everything that is happening around new product

development.

Amongst everything that I had listed, I should honestly pick ‘diligent attention to smaller

details’. Critical stakeholders involved with building the new product including

engineering team, architect team, and Program Manager paid lots of attention to smaller

details that paved way for a bigger success without too much of a roller coaster ride. If I

look back, clinical planning helped us eliminate risks, validate assumptions as early as

possible, and build the new product in a smoother way. Entire team knew all along that

we are building what we had intended to build and we will be delivering it without any

schedule slip.

Most importantly, nothing succeeds without a good team. I should say I had an

‘AWESOME TEAM’ that really complemented efforts of every individual involved with the

task of building the new product. Some of what I did during the course of new product

development are the ideas that I got inspired by various people from engineering,

program management etc. I want to drop them their due credit by appropriately calling

this section as ‘What did we do differently’ instead of ‘What did I do differently’.

Conceptual view

No matter whether I am building a new product or managing an existing product, the first

thing that I ever do is to ask for a conceptual view of the entire product. How various

components (physically separable or logically separable) of the product interoperate and

how various elements within a component interoperate.

In many cases, we might not sell a single standalone product. Consider a smart parking

solution, we sell an entire solution comprising of sensors, mobile apps, back-end

Page| 139

www.ProductGuy.in


databases etc. The conceptual view will let everyone know how various elements

interoperate to deliver the solution.

Figure 14 - Conceptual view of Smart Parking Solution

I did once attend an Innovation talk where I got hold of the below conceptual view. Quite

obviously, it belongs to a ‘Projector’. The below conceptual view talks about how various

elements within a product interoperate to deliver the desired functionality.

Figure 15 - Conceptual view of Projector

Page| 140

www.ProductGuy.in


What I am trying to advocate is that it is essential to have the overall view of the solution.

Such an approach is synonymous with holistic view or conceptual view. Rather, we could

also call it as ‘System Thinking’. I am strong advocacy of imbibing ‘System Thinking’ into

the thought process of every engineer. Why it is crucial – Majority of engineering teams

work in silos without getting a bigger picture or context of the overall solution and it

definitely hampers innovation. Without the bigger picture, engineers could hardly grasp

nuances around why customers are using the product, which segment of customers are

using the product and for what purposes do customers use the product. Those

fundamentals trigger inquisitiveness among engineers.

The engineering team building a sensor will be interested to know what information is

required by a central server and in which format central server requires the information.

There would not be any effort to comprehend why central server requires the information

and how central server will utilize it. Without the grasp of conceptual view, engineers

working on either central server or sensors will hardly have any idea on how innovating

the respective components will improve the overall solution.

The importance of the conceptual view is more evident during new product development.

The primary task of Product Manager during the entire phase of new product

development is to ensure everyone involved with building the new product (even junior

engineers in the team) should be aware of the purpose and objective behind building the

new product. Lack of conceptual thinking will hamper the ability of every individual do

gain a broader understanding of the purpose and objective behind building the new

product. The conceptual view can also provide tremendous knowledge on how changes

to some elements of the product will affect other elements. No product is an island and

everything is interconnected, conceptual outlines those interconnections.

One initiative that really helped to imbibe conceptual view of the existing product line to

my engineering team was through building posters and sticking them across the entire

workspace. The posters were highlighting the following details of the existing product

line.

Conceptual view of the solution. We do sell a combination of products, so I will safely refer it as a solution.

Major customer segments targeted by the solution

Top use-cases of the solution

Top customer needs that are addressed by the solution

Page| 141

www.ProductGuy.in


Typically, all those details will not only help obtain a conceptual view of the solution but

also to grasp details about who is using the solution, why are they using the solution and

what are they intending to achieve using the solution.

New product addition, especially to an existing product portfolio, is an opportunity to

overcome shortcomings of existing products. New product development starts with a

clean slate, so there is an immense opportunity to undo what we should have done with

earlier products. Instead of just blindly inheriting older product(s) architecture and adding

a few layers to build the new product, the conceptual view provides us an opportunity to

identify merits and demerits of various components in the existing product or solution. A

majority of discussions among various stakeholders even before I started drafting the PRD

was to leverage the conceptual view of the existing product line to look back into history

to identify what we could have improved and what we could have retained in existing

product. The engineering team has given a thought to whether it is possible to eliminate

any of the existing components or it is possible to optimize interactions between existing

components. I took those findings to construct requirements for the new product.

Look into the future

I have always maintained that the new product is just not for today’s needs and

customers, but also for tomorrow’s needs and customers. Rightly so, ever since a lean

team was formed to formulate architecture for the new product and to identify an HW

platform that can be leveraged to build the new product, we started focusing on

identifying how customer needs would evolve in future. Among everything that we did to

anticipate how customer needs will unfold in future and how product architecture should

be extensible to address those needs, I will probably highlight one scenario.

Our product line was falling behind competition and revenues are declining. Therefore,

the new product (a hardware-based appliance) attempts to bridge the gap with

competition and increase the bottom-line. I strongly opine that catch-up effect will help

us regain some of the lost ground but will definitely not help us go past the competition

to claim the leadership position. The ideal way to overcome competition is to embrace

new trends much earlier than competitors do, so I was consciously focusing on new trends

that can catapult the product ahead of competitors. Network function virtualization (NFV)

was one of the technological trends and I knew that we had to embrace it early before

anyone does by building a virtualized version of proposed new hardware appliance

Page| 142

www.ProductGuy.in


product. On the other hand, focusing exclusively on trends will not fetch us revenues in

immediate future and management will decline approvals for such initiatives considering

that revenues are already declining.

However, we had a blessing in disguise through our choice of hardware for building the

new product. While architect team was evaluating HW options to build the new product,

one of the options thrown before marketing team was an x86 based compute platform.

Among all the options, we chose compute platform with pure SW based architecture

without any ASICs (Application Specific Integrated Circuits) and FPGA (Field

Programmable Gateway Arrays) as it would help us easily foray into virtualization at no

additional cost. Quite obviously, we never had any trouble getting the approval to build

the virtual product. While the trade-offs that I was making because of choosing the

compute platform is bare minimal. I am grateful to my architect team for their quick

turnaround in providing all the required data in terms of performance, the cost of goods,

pros and cons of each HW option. Those details helped us to make an informed choice

much faster.

Irrespective of all the right intentions, Product Managers will always be constrained by

processes and (s)he will be constrained to play the game within those limitations. What I

had precisely done is to be aware of all those constraints. Even though we are aware that

entering virtualization space is critical, budgets were limited. Slump in existing revenues

because of product line lagging behind the competition, made it even more difficult to

secure budget to build two consecutive products: (i) an HW appliance product and (ii) an

SW based virtual product.

However, the choice of compute platform helped us strike two birds with one stone.

Voila, we embarked on the journey of building two new products (virtual and hardware

appliance) more or else at the cost of building a hardware product. What is even more

fantastic is that my engineering team did a fabulous job of delivering virtual product along

with HW product without consuming any additional time. While one product helped us

close the gap with competitors, the other product helped us highlight to our customers

that we are thinking ahead and we are poised to address their future needs. Our new

virtual product helped us shed the tag of being a follower consistently for the last few

years and we gained the enormous attention of our customers.

Page| 143

www.ProductGuy.in


Though we made a wise decision to foray into virtualization during 2013 while the new

product is still under development and if I look back, I am completely convinced that we

made right choices. However, at that point when the market for virtualization was

nascent at least in non-data center markets, we did consciously focus on what will be the

impact of virtualization on appliance product. We tried to comprehend when customers

would possibly prefer virtualization of their network elements, what would cause

customers to lean towards virtualization. What kind of progress (increase in performance,

reduced TCO etc.) should happen in the world of virtualization that can possibly trigger

customers to throw away appliance products and migrate towards virtualization? When

is the realistic possibility of such occurrence? Accordingly, we decided how much to invest

on virtualized product at various stages.

In addition, there were also many other thoughts that were flowing into minds of each of

us with regard to whether there will be a constant demand for the new product. It is just

not about the product but about the entire category, would existing target customers still

see a value in the product category or is there any necessity and possibility for us to foray

into new market segments. Customers have various needs and each need has a priority

in alignment with their business environment. Product Manager should consciously

identify whether the need addressed by the new product is at top of customers’ priority

list. If the need addressed by the product category is not at the top of priority list, then

the market for the product will only shrink. Product Manager has to anticipate whether

there is a possibility for the need addressed by the product category will drop down in

the priority list. I will quote an example. Enterprise customers use WAN (Wide Area

Network) optimization products that can help them reduce WAN bandwidth

consumption, as WAN bandwidth is costly. What If there is a significant reduction in the

cost of WAN bandwidth so much that the value rendered by WAN optimization products

is not substantial. Product Managers has to foresee the possibility of such scenarios that

will diminish the value rendered by the product.

Begin with an end in mind

All stakeholder commenced every activity during new product development with an end

in mind. What is the end? Consider it as four pillars

Creating value – The actual product – What is the value delivered by the new

product to its target customers.

Page| 144

www.ProductGuy.in


Communicating value – The marketing message – What is the USP of the new

product, what attributes does customer value most?

Delivering value – Where and how the new product is sold?

Capturing value – The pricing – How do we plan to monetize the product?

Every stakeholder involved with building the new product had a firm understanding of

what is the end. Yet, it was a primary responsibility of Product Manager at every phase of

new product development to check:

Is the team is building the new product as envisioned initially?

Is the team is building the new product to retain its unique differentiators? Are

those unique differentiators still in alignment product messaging? Whether we are

building the new product with all those essential attributes, whose existence will

influence customers to buy the new product?

Is the team is building the new product that could facilitate us to sell where we

intend to sell and how we intend to sell?

Is the team is building the new product in accordance with proposed pricing

model?

Any changes happened during the journey of new product development were in

alignment with the objectives of creating, communicating, delivering and capturing value

and any changes in those objectives triggered corresponding changes to the journey of

new product development.

I have earlier mentioned about how we narrowed down the choice of HW for the new

product to an x86 based compute platform. Key problem was that our earlier products in

the product line were marketed as built with specialized HW that delivers far better

performance than that of competitor products. With the choice of compute platform, I

had to change the value proposition statement of existing products too in the product

line not to emphasize too much on specialized HW. However, with the choice of compute

platform for the new product, I am contradicting that the specialized HW is actually not

required for better performance and it is actually not a differentiator.

Therefore, I reworked the entire strategy of appropriately communicating the value of

the new product to highlight the benefits of x86 based compute platform. I further

emphasized how we are not losing advantages that we got on our earlier products built

using specialized HW. In addition, I did sales enablement to educate sales team on why

Page| 145

www.ProductGuy.in


we choose compute platform, what advances in merchant silicon has now made it feasible

to build a product that delivers performance on par with purpose built HW and why it was

not possible to build products earlier on x86 platforms.

In another instance, I was at the crossroads of making a crucial decision. One of the critical

requirement is to deliver higher throughput while maintaining reduced latency. Architect

team came with two proposals (1) delivers higher throughput than I asked for but at the

cost of a marginal increase in latency (2) marginal reduction in throughput and a

significant reduction in latency. I had a detailed discussion on why the trade-off why we

cannot design a product that perfectly balances both. After lots of discussions and hearing

through lots of other possible solutions, I finally narrowed down to (1) because the pricing

of the new product is in relation to its throughput. Therefore, it indirectly provides an

advantage to sell the product at a higher cost. The other factor that worked in favor of (1)

is that the architecture can process a constant number of IP packets in the range of

millions per second irrespective of the size of the IP packet. With the same amount of

resources, the throughput will go higher as the size of the IP packet goes higher.

With IPv6 adoption, the average size of the packet is poised go higher and we proved to

our customers using the data from their own networks that the average packet size is

raising. As packet size increases, the overall throughput delivered by the new product will

overshoot the target throughput, so customers eventually get more than what they have

paid for. Since virtualized product follows similar architecture as well, it worked better

because in virtualized scenario throughput per vCPU is the benchmark for performance.

With the choice of proposal (1), I could clearly articulate the benefits of x86 based

compute platform in terms of higher throughput with higher packet sizes that was not

the case with earlier products.

When I advocated that we should always begin with an end in mind, we can do so only

when the destination is known. There need not be clarity on the path to the destination,

but there should be absolute clarity on where we are heading. If we are changing the end,

then as I said earlier we need to relook at our approach to end or any changes in the

approach we should relook whether it will trace to the end. During our new product

development, we did fix certain elements of ‘End’ related to what product to deliver to

our customers, which segment to target for the new product, when to deliver the new

product and how to deliver the new product. We did ensure that there is absolute clarity

on aspects of the new product that is unmodifiable, as it would affect commercial success

Page| 146

www.ProductGuy.in


post its launch. The vision of the new product was engraved into minds of everyone.

Therefore, each of us was unequivocally focusing on how do we get there and what it

would take us get there. Never in our journey of new product development, have we

thought ‘can we get there?’ Probably those positive vibes had helped us unearth answers

for most of the tough questions that we faced during new product development.

Data-driven

When I did indicate that, certain elements of ‘End’ related to what kind of product to

deliver, whom to deliver and when to deliver were fixed. Those elements were fixed after

thorough quantitative and qualitative analysis of ascertaining that we are indeed building

the right product for right customers to address the right needs. Quantitative data was

the basis for all our decisions related to value hypothesis and growth hypothesis (but not

limited to). Wherever there is a lack of quantitative data, we employed qualitative

analysis.

In spite of sufficient data that the new product development is heading on a wrong path,

there are situations where teams hardly pivot. Such teams do not dare to fail and persist

in spite of clear writing on the wall. For data-driven decision to be successful, it requires

a mindset change, a mindset that does not try too hard to be correct. Otherwise, there is

a high chance for some form of product failure to haunt us in immediate future. What did

we do differently to evade those product failures? We clearly shed our inhibitions to fail,

we crushed our egos and we did subject our actions to scrutiny. Doing so, we abstained

each of us to remain in a state of prolonged perseverance to hold onto one’s viewpoints

without any rationality.

`

The vision of the new product was engraved into

minds of everyone. Therefore, each of us were

unequivocally focusing on how do we get there

and what it would take us get there. Never in our

journey of new product development, have we

thought ‘can we get there?’

For data-driven decision to be successful, it

requires a mindset change, a mindset that does

not try too hard to be correct

Page| 147

www.ProductGuy.in


Engineering team never threw product architecture proposal or any other technical

proposal and they never expected marketing team to acknowledge their proposals

blindly. Wherever possible, they provided options with lots of accompanying data that

precisely outlined pros and cons of each option. Such a methodical data-driven approach

has helped us narrow down the ideal option, which eventually paved for building the right

product. We followed a similar approach to narrow our choice to x86 based compute

platform. Even while selecting an architecture approach that can let the product deliver

more throughput for higher sized packets, we did pull out lots of data from customer

support cases to identify the trend of increasing average packet size on the internet. In

order to eliminate geographical bias and discrepancies, we pulled the data from

customers across the globe and we consistently concluded that the average packet is

increasing and the minimum average packet size that we have noticed in our customer

networks is around 640 bytes.

When I prioritized certain features that already existed in the current product line, we did

use plenty of data to identify whether they are indeed adding value to customers and

customers are actually using them. There are cases, where engineering team confronted

me during product requirements review discussions to question my decision of

prioritizing certain features that are favored less by existing customers. The initial decision

to include certain features were based on an explicit request made by some key

customers. Then I had to optimize our entire development efforts by eliminating features

that add value only to a handful of customers. Therefore, I did engage with customers

requesting those features to offer them something alternative and went ahead with

incorporating only features that add value not just to a handful of customers but also to

the vast majority of the target segment.

Marketing team analyzed RFPs to identify how customer requirements will evolve in

future. Network devices have a larger shelf life and customers would be cautious to buy

We clearly shed our inhibitions to fail, we crushed

our egos and we did subject our actions to

scrutiny. Doing so, we abstain each of us to

remain in a state of prolonged perseverance to

hold onto one’s viewpoints without any

rationality

Page| 148

www.ProductGuy.in


products that suit their future needs. For those reasons, RFP would outline future needs

as well. Marketing team identified a common set of future needs and corresponding

features to address those future needs from analyzing RFPs. I later added those features

to the list of product requirements.

The fundamental premise of demand for the new product is that the customer networks

will grow to handle more traffic and thereby the network elements should be capable

enough of managing higher traffic growth. Internet traffic explosion is a universal truth,

but we had to identify which of our existing customers’ network is growing. Even if

network traffic is growing, we had to determine how customer networks are designed as

it would determine the demand for a product to handle higher traffic. I am emphasizing

too much on existing customers as our focus was to sell the new product to existing

customers to show immediate revenue and with existing customers, buying cycles are

always short. Again, support cases offered many insights on the traffic consumption in

customer networks. We did not get the data for an entire network but with whatever

little data we managed to pull we did reach customers directly to understand which parts

of their network is growing, how their networks are designed and what will be the

possible demand for the new product. We did analyze the demand but this approach

begets another question, would existing customer buy the new product only from us

when the demand arises. Based on the data that we had segregated, we identified a list

of existing customers who can be potential buyers of the new product. The biggest

advantage of B2B customer segment is that the customer size is manageable and it is

possible to have undivided attention with every customer. We worked pro-actively with

prospective customers of the new product, to understand what they need and ensured

the new product will address their needs. The biggest advantage of data-driven approach

is that we never left anything for chance.

For a data drive approach, building the new product for an existing product line was a

blessing in disguise as we had all the required data. We just had to use it appropriately to

make informed choices. With the virtual product, we never had such extensive data

available, as it is the first product of its kind within our product portfolio. Therefore, we

built the minimum viable product without any optimization. The only optimization that

we did target for the virtual product is to handle more bandwidth for each unit of CPU

The biggest advantage of data-driven approach

is that we never left anything for chance

Page| 149

www.ProductGuy.in


core, as it is the benchmark to measure the performance of any virtual product. Our

approach for the virtual product was entirely different, we did plan to validate the new

product in the customer network and evolve it further based on the feedback. We were

not overly ambitious to make the virtual product utmost perfect.

Engineering Intimacy

During new product development, engineering intimacy is crucial for building the right

product and more importantly for building it right. No matter, how detailed the PRD is

written. No matter how lucidly Product Manager communicates the desired attributes of

the new product. No matter how effectively Product Manager communicates the vision

of the new product. No matter how effectively and thoroughly the entire new product

requirements are reviewed, discussed, debated and converged, there will always be little

things that would either get noticed or go wrong only during product development phase.

In order to ensure that there is a diligent focus on those little things and engineering team

takes care of them promptly in a timely manner with the collaboration of Product

Manager and engineering team, it is essential to have engineering intimacy.

I am not trying to blame anyone here for not noticing those little things until later into

new product development phase. Maybe it is law of the universe. As per Murphy’s Law,

anything that can go wrong will go wrong. What I am trying to advocate is that there is

definitive possibility for things to go wrong in spite of meticulous planning and diligent

attention to various details of new product development. Therefore, it is essential to have

No matter, how detailed the PRD is written, no

matter how lucidly Product Manager communicates

the desired attributes of the new product. No

matter how effectively Product Manager

communicates the vision of the new product. No

matter how effectively and thoroughly the entire

new product requirements are reviewed, discussed,

debated and converged there will always be little

things that would either be noticed or go wrong only

during development phase

Page| 150

www.ProductGuy.in


engineering intimacy during the entire course of new product development for promptly

capturing all those little things that can go wrong and address them attentively.

Even though my coexisting with engineering team helped me to build the engineering

intimacy, it was limited to some key players. I had to thank my ‘Head of Engineering’ for

facilitating engineering intimacy to a completely new level by ensuring that at least 1/3rd

of the engineering team spread across both product development and product testing are

part of product requirements discussions. During the review process of requirements

drafted in the PRD, 25 people from engineering team filled the entire room. I vaguely

remember it as 80-member engineering team working on both development and testing

of the new product. Unlike in most cases where only the development team is involved,

my engineering team followed a unique process to have both development and test

teams participate in review discussions, so both teams get first-hand information on all

new product requirements. Such a process is commendable, both development and test

teams have a unified view of what is the new product, why they should build it and how

they should build it. More importantly, nothing gets lost in translation while development

team had to share details about new product features with test teams.

The objective of review meeting was not only to discuss requirements of the new product

but also to make engineering team familiar with the new product proposal of why we

need to build. Engineering team should be aware of the ultimate purpose and objective

behind the new product. A big boardroom was booked to accommodate almost 20-30

engineers and the review process prolonged subsequently for 2-3 days. Such a review

process facilitated the following.

1. Discuss requirements with a majority of engineering team implementing the new

product, so nothing is lost in translation.

2. Interface directly face-to-face with majority of engineering team implementing the

new product

3. Avoid discussing requirements in silos. We did discuss entire requirements of the new

product holistically so engineering team had a grasp of what is happening beyond

their module or component and how they are interrelated.

The review process indirectly ensured that every engineer gets the conceptual view of

the new product. Even though the initial draft of PRD had the inputs of the engineering

team, review process provided an opportunity to refine the PRD further. The review

process is not just me directing what we should build. It is a collaborative effort to identify

Page| 151

www.ProductGuy.in


what we need to build. Product Manager and engineering team should engage in a

partnership mode, the role of engineering team during the review process is highly

valuable. During the review process, we discuss, we debate, we confront, and we concur

but we always ensured that what we concur is aligned with the purpose and objective of

building the new product. ‘WHY’ was an overarching principle that governed the review

process. At times, Product Manager has to stick to his guns to ensure that (s)he gets what

(s)he wants without leaving too much room for compromise and not being too

democratic.

Post the detailed and exhaustive review process of new product requirements, I got

familiar with the entire engineering team and had complete awareness of specific module

or component developed or tested by each engineer. I can walk to them or they can walk

to me to clarify on finer nuances of certain requirements that PRD failed to clarify. When

such discussions uncover certain issues (remember the little things noticed only during

development) or gaps with existing requirements, I always spread the message out to all

the affected teams. Therefore, the conversation was never a private affair. At least from

the perspective of engineering team, they can walk to me for any clarifications without

dropping emails and wait until I respond back. It helped in

1) Saving engineering team from the trouble of drafting an email and waiting for my

response

2) Seeking clarifications in-person without delaying their work unless I could not clarify

them immediately

3) Ensuring that other affected engineering team members are informed of the findings

or changes in requirements identified and finalized during impromptu discussions.

Thumb rule that I did assert to engineering team during the review process is not to

assume anything related to new product development. Assumption is definitely a sin

during new product development. PRD is a bible for new product development. If PRD is

either not complete for certain requirements or if any requirement is not actionable or

unambiguous I did request the team to walk to me, so I did naturally encourage

impromptu discussions in the corridors or over coffee or at our respective offices. Of

course, it also did help me to overcome the flaws of not articulating any specific

requirement clearly in the PRD. However, I am only talking about few exceptional cases

and I generally prefer to provide detailed requirements that are actionable and

unambiguous in the PRD.

Page| 152

www.ProductGuy.in


Plan my day – Took control of my time

I almost end my day with following thought – ‘Am I clear in how I will be utilizing 80% of

my time tomorrow’ – If the answer is emphatic YES, then I am sure I will be utilizing my

next day effectively. Otherwise, I will wake up figuring out what to do. I will be waiting for

someone to direct me. During new product development, Product Manager could not

afford to have such days. Even though I plan my day leaving 80% of my time for planned

activities and 20% of my time for unplanned activities, I had to introspect whether it is

going as per the plan. Is 80:20 split working or do unplanned activities taking more than

20% of my time. I sometimes notice Product Managers whine that they had to spend long

hours because their CEO or VP suddenly asks for certain data or they were obliged to

provide an update on the new product in the last minute. If Product Manager had been

long enough in an Organization, (s)he should anticipate possible tasks and ensure that

unplanned activities are brought down to 20% of the overall time.

I did initially try to split my week focusing on specific activities on each day of the week

(1) Engineering (2) Customer Engagements (3) GTM/Collateral (4) Sales/Field Enablement

(5) Pricing/Forecast. Nevertheless, such model seldom worked for me, so instead of

allocating an entire day, I did manage to dedicate few hours of a week for each of those

activities. I called those few hours as ‘Me Time’. During ‘Me Time’, the exclusive focus was

on delivering my charted activities that I own exclusively. During office hours, multiples

team pull me into lots of discussions. Therefore, ‘Me Time’ was definitely out of the 10-5

schedule. Doing so, I did ensure that I am giving equal attention to all the required tasks I

I almost end my day with following thought –

‘Am I clear in how I will be utilizing 80% of my

time tomorrow’ – If the answer is emphatic YES,

then I am sure I will be utilizing my next day

effectively. Otherwise, I will wake up figuring out

what to do. I will be waiting for someone to direct

me.

Assumption is definitely a sin during new product

development

Page| 153

www.ProductGuy.in


outlined in the activity checklist. I spent most of my time during initial days of the new

product development with the engineering team. As we progressed through product

development and as we started validating all assumptions, eliminating all unknowns and

mitigating all known risks, I slowly switched my time onto other activities that are

exclusively owned by me (1) Customer Engagement (2) Sales/Field Enablement (3)

Collateral (4) Pricing (5) Ordering (6) Launch plans etc.

It is the sole responsibility of Product Manager on how (s)he manages his/her time to

deliver all the required tasks, Product Manager can hardly whine about the lack of time.

Like various plots of movie converge during the climax, all tasks related to new product

development should perfectly hit the finish line exactly on the day of releasing the new

product. Even though pricing, collateral preparation, ordering would have been

completed earlier. Exactly on the day of new product launch, ordering has to be turned-

on, web-portal containing information about the new product should go live

simultaneously.

Act and think like a customer

Technical expertise of engineers makes them vulnerable to commit mistakes by assuming

customer behaviors. While developing products, engineers’ think customers will use the

product exactly as they are supposed to use. However, not all customers are aware of

how exactly to use the product and customers might tend to wrong with the usage of the

product. The first basic principle of design is not to ever assume customer would use the

product exactly as they are supposed to use. Engineers should be conscious of the fact

that customers might use the product in a wrong way. The entire concept of design is to

ensure that there are sufficient indicators to signal when the users wrongly use the

product rather than bringing the product down and blaming it on the inefficiency of the

user.

Product Managers observe customers in their ‘natural habitat’ and such knowledge

should facilitate them to think and act like a customer during the course of new product

development to review the product as it developed from the perspective of customers.

The 1st basic principle of design is don’t ever

assume customer would use the product exactly

as they are supposed to use

Page| 154

www.ProductGuy.in


As the product is developed, Product Manager could review whether engineering team is

building the right product that is in alignment with expectations of customers. For

instance, Product Manager can review the boot process of the new product to check how

long it takes, what messages the new product throws and what prompt the product

displays after completion of instantiation of the device. It might not often possible to seek

customer feedback on every facet of new product development, so Product Manager

should fill the role until MVP is developed and customers validate it in their environment.

We did follow this approach diligently for every subset of the new product whose

behavior differs from the existing product in its family.

The product development and the role of Product Manager should be synonymous with

the role of a chief chef who overlooks the entire process of cooking a recipe. The chef just

does not provide the recipe and walks off until the food is prepared. He oversees every

step of preparation of the recipe constantly monitoring whether preparation is on-track

to have a delicious food.

It is just not me alone participating in the review process of new product development.

We had every stakeholder who can even remotely represent a customer, review various

facets of new product development. While I did review new product development

primarily from the functionality perspective, we also had customer escalation team to

review troubleshooting and debugging capabilities of the new product. The team that

helps customers install the new product did review the documentation and usability of

the new product to validate whether the new product requires an additional learning

curve.

While we graciously accepted that the new product could malfunction sometimes, we did

try to ensure that the new product has sufficient mechanisms in place to identify the root

cause of malfunctioning. Escalation team did troubleshoot product failures reported by

test team during new product development. Doing so, we did confirm that the new

Product Managers observe customers in their

‘natural habitat’ and such knowledge should

facilitate them to think and act like a customer

during the course of new product development to

review the product as it developed from the

perspective of customers

Page| 155

www.ProductGuy.in


product has sufficient capabilities to troubleshoot any failure with ease. Even while

drafting the requirements for the new product, I was not very efficient in providing

requirements to enhance debugging capabilities of the new product. In PRD, I did only

add a generic statement that the debugging capabilities should simplify troubleshooting

any issues found in the new product. Escalation team complemented my inputs to provide

guidelines for debugging and troubleshooting requirements. Escalation team also pointed

out most commonly anticipated issues in existing products and the new product was

equipped to safeguard from misbehaving while hitting those common issues.

Product documentation was provided to prospective users of the product to get their

inputs. Every stakeholder who can even remotely represent what customer desires

holistically reviewed the entire aspect of new product development from the perspective

of customers.

`

Cross-pollination of agile and waterfall

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.

Every stakeholder who can even remotely

represent what customer desires holistically

reviewed the entire aspect of new product

development from perspective of customers

There should always be a fit between the product

and its development methodology, alike product-

market fit

Page| 156

www.ProductGuy.in


We 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 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. 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

change to product architecture. 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. A strong customer research along with identification of

factors that can influence the evolution of technology, the evolution of the market, the

evolution of customer needs is required. 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.

Page| 157

www.ProductGuy.in


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

Table 3 - Hypotheses of Product Architecture

Hypotheses of Product Functionality

Hypotheses Associated Requirements Dependent Requirements

H6 R6 R14

H7 R7 NA

H8 R8 R15

H9 R9 R16

H10 R10 NA

Table 4 - Hypotheses of Product Functionality

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 in validating hypotheses. Second, the set of

Page| 158

www.ProductGuy.in


functionalities or requirements (R11…R16) that engineering team should delay until

validation of certain hypotheses. 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 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 upfront unlike in agile before going in a loop containing requirements,

design, and development. 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 facilitate incremental additions for 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

Page| 159

www.ProductGuy.in


new product development. Always find the right fit between the product and its

corresponding methodology.

Lean (‘Tag on’) marketing

‘Tag on’ marketing is a concept that I adapted to market the new product especially when

there was hardly any budget left for marketing of new products. Between two products

that we are building, I used the concept of ‘tag on’ marketing for the virtual product. The

virtual product is an SW appliance capable of running entirely within a virtualized

environment. The virtual product is the first of its kind within its category that we have

introduced in our Organization. It was an experimental product with a clear motivation of

identifying product-market fit. We just cannot restrict virtual product to the same target

segment as HW appliance. Therefore, there is a necessity to provide widespread

awareness of the virtual product and understand for which additional customer segments

the virtual product will be an ideal fit.

Lack of budget did not help our cause to plan roadshows or events to spread the

awareness about the new product. Until we do so, we cannot gauge the interest of

customers and subsequently push the sales of the product to additional customer

segments. It is more like a chicken and egg problem, without actual sales I will not get

budgets and without budgets for marketing, it is difficult to gain additional sales of the

new product. In order to break the cycle, I contemplated ‘tag on’ marketing.

‘Tag on’ marketing allows the new product to tag on to the marketing initiatives of related

products or categories and it is an opportunity to market the new product at zero cost.

Under the concept of ‘Tag On’ marketing, my new product might not be the protagonist

of marketing campaign. Nevertheless, it gets required attention.

Virtualization was still at its nascent stage while building the new product and many other

teams were building first virtual products in different categories (virtual firewall, virtual

router, virtual DPI etc.). All those products act as VNF (Virtualized Network Function)

Under the concept of ‘Tag On’ marketing, my

new product might not be the protagonist of

marketing campaign nevertheless it gets

required attention

Page| 160

www.ProductGuy.in


elements in NFV environment but to instantiate VNF elements and to manage them

another team was building a MANO (Management and Orchestration) software too.

There is a necessity to familiarize prospective and existing customers about the transition

towards virtualization. Therefore, Organization was organizing events to spread the word

about MANO and about the arrival of virtual products in different categories. I am

especially glad that some of those Organization-wide marketing plans for virtualized

products were in alignment with our release plans of my new product and I am happy to

tag on.

We also discussed with another team to conceptualize solutions around the new product

(virtual version) in a combination of MANO and other virtual products. Positioning

solutions to address specific customers’ problems is more attractive rather than

positioning individual products and later asking customers to integrate those individual

pieces to address their problems. We did our best to insert our virtual product in one of

the solution initiatives after elaborating the value rendered by my virtual product to the

overall solution. Obviously, any efforts to market the solution has indirectly marketed the

individual pieces of the solutions and it includes my new virtual product too. Another

happy conclusion. Soon the word started spreading out about the impending launch of

the virtual product.

While ‘Tag On’ marketing helped us create awareness about the virtual product at no

additional cost, we did follow a more traditional approach for marketing of HW appliance.

There is nothing innovative about the approach. It is definitely low-cost but proven

effective. The biggest advantage of B2B marketing is that the target audience are smaller

and they are far more rational than B2C buyers are. Therefore, we started approaching

our existing customers directly more like a door-to-door marketing. Instead of knocking

on their doors, we knocked on their video conference. We are a team of three Product

Managers each of us owned different products and we had a geographical responsibility.

Even though we own specific products, each of us responsible for marketing the entire

product line in the geo that we own. By virtue of such responsibility, I did market the new

product only for customers in EMEAR, while my colleagues did market the new product

in rest of the world (Americas, LATAM, and APJC). Three of us shared a great camaraderie

and we coordinated and strategized to market the new product in a similar way across

the entire globe. Lack of budgets did put some pressure to show immediate results and

we went after existing customers.

Page| 161

www.ProductGuy.in


Targeting existing customers helped us on two fronts (1) selling cycles are shorter, there

might not be any need for RFP process, so we can show immediate gains for the new

product and (2) validation of the new product in an actual customer environment. All

three of us worked in tandem to reach all existing customers in our respective regions

and at least 2 customers were secured from each region to help us validate the new

product. We also identified potential customers who can immediately place orders for

the new product. In fact, we did validate the new product with customers who have a

higher chance of ordering the new product as soon as it is available.

Path to building a great product

In my attempt to build the new product, I did fell short of building a great product. I

reflected upon my experiences and learned that I missed few additional aspects required

to build a great product. I learned it the hard way. We often learn a lot from failures than

successes. I tried to delve into those specific elements that are required to build a great

product and I tried to interlace them while sharing my experiences of building the new

product in earlier sections of the eBook. To summarize, following are the critical elements

that are required for building a great product in addition to earlier outlined elements of

building the new product.

Start defining the WHY – Strong product vision that outlines the purpose and belief

behind the new product

Pick an audacious problem to address that no one has addressed it earlier or either

addressed in a way that you are addressing it. Ensure that target customers really

care for the addressing their problem and they definitely pay a premium for

addressing it. For doing so, Product Manager should have extensive knowledge

about customers and their needs.

Think bold, think future unconstrained by any limitations - 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 needs of today, your focus should be

on extending the solution to address needs of tomorrow. While addressing a

problem or a need, never be constrained with existing technologies or existing

benchmarks (What Musk did to electric cars). Probably, new product idea or

solution to address the need or problem should pave for new technology evolution

or trigger change in customer behaviors.

Simplicity - This is one principle that is essential for every product. No matter how

complex problem the product is trying to address, there should be simplicity

Page| 162

www.ProductGuy.in


written all over the product on how customers will use the product to address their

problem or needs

Do one thing right - Be focused on just doing one thing right. The new product

could not be everything to everyone. Even if the new product has to do multiple

things, just focus on delivering awesomeness on specific elements of the product

that will drive customers’ preference towards the new product, instead of doing

everything right.

Impeccable execution in building the product – Nothing beats execution. Even a

mediocre idea with perfect execution will win over an awesome idea with poor

execution.

We did really well on strategy in choosing to build a virtual product and our execution was

just flawless. Our vision was also good, but I fell short of taking some bold moves. The

target market of the new product were three primary ISP market segments (1) mobile, (2)

broadband and (3) cable. Mobile was growing segment while remaining markets were

saturated. I should have probably taken some bold moves in aggressively going after a

specific market instead of trying to address every possible market and doing everything

right.

Final Word: No matter how well we do something, there is always a room for

improvement, and there is always ifs and buts. Let us all reflect on those learnings to

continue building awesome products.

Page| 163

www.ProductGuy.in


Essential traits of Product Manager for success of NPD

In the concluding section, I want to focus on the essential traits of a Product Manager

required for building the new product. At least my take on building the new product is

that Product Manager should imbibe all the below-mentioned qualities for a successful

new product development. The below qualities are in general required for a Product

Manager but the existence of those skills are indispensable during new product

development.

1. Technology Awareness, Market Awareness, and Customer Awareness

2. Embrace Tough Decisions

3. Meticulous Planning

4. Attention to Details

5. Guide

6. Facilitator

7. Knowing Constraints

8. Self-Starter

Please note that the listing of above qualities does not follow any specific order of

importance.

Is Product Manager crucial for successfully building a new product? There is a saying that

without development team, it is not possible to build the product, without a sales team,

it is not possible to sell the product, without a marketing team, it is not possible to market

the product. What does a Product Manager do? In a larger scheme of things, Product

Manager role is intrinsically tied to how the product is built, marketed and sold.

To build a great product, it is inevitable to have a great team from various disciplines. But

it is even more inevitable to have a Product Manager ensure that there is a coordination

among multi-disciplinary teams and to facilitate proper communication among them and

to constantly remind them about customers for whom the product is being built and why

it is being built, what need it has to address and how it should address. New product

development does not require any ordinary Product Manager, it requires a rockstar

Product Manager who personifies below qualities to envisage and execute the vision of

the new product.

Page| 164

www.ProductGuy.in


Technology awareness, Market awareness, and Customer awareness

Product Managers should have a stronger understanding of all three elements

(technology, market, and customers) and I believe it is the fundamental necessity for

being a Product Manager. I split customer and market because it makes sense in the case

of B2B product. Product Managers should have complete knowledge about the

characteristics of their target segment - what their needs are and how they are using the

product. Market awareness is little about competition awareness (how competition is

currently positioned and how they are evolving?) and trends awareness (how new

technology trends would affect the evolution of the product?). Market awareness should

also help Product Manager go past the immediate needs of customers and understand

how the product should evolve to align with evolving customer behaviors, technologies

etc. Market and customers are probably two sides of the same coin. While customers will

help Product Managers gain a short-term view of how the product should evolve, the

market will provide a long-term view.

Product Managers need not have a diploma in Computer Science but they should hold

necessary acumen to grasp technology aspects related to the new product to understand

the relative benefits of one technology over another. When it comes to technology

awareness, the expectation is Product Managers are more of generalists than specialists

are. Let me illustrate those three pillars using the concept of IoT.

Technology Awareness: Awareness of IoT technology to succinctly communicate

what it is and how it will impact the way customers use the devices when they are

connected

To build a great product, it is inevitable to have a

great team from various disciplines. But it is even

more inevitable to have a Product Manager

ensure that there is a coordination among multi-

disciplinary teams and to facilitate proper

communication among them and to constantly

remind them about customers for whom the

product is being built and why it is being built,

what need it has to address and how it should

address.

Page| 165

www.ProductGuy.in


Customer Awareness: Awareness of critical customer needs and ability to map how

interconnection of IoT enabled devices could possibly communicate to render new

value proposition to address critical customer needs.

Market Awareness: Awareness of what could cause the widespread adoption of

IoT devices, what is the overall IoT ecosystem, who are the key players etc.

Among million things that could be done as part of the new product, if Product Manager

has to pick a finite set in alignment with resource spread of engineering team and what

customers exactly require, (s)he should have precise understanding of how every feature

added to version 1.0 of the new product would add value to customers. Without complete

awareness of technology, customer, and market, Product Manager cannot comprehend

how the evolution of technology, customers’ needs and their behaviors, and the market

will affect new product development. Such a scenario would either hamper or slow down

the decision-making capabilities of Product Manager. It could even push Product Manager

to delegate decision making to engineering team and other stakeholders. New product

built so is never in alignment with its original objectives.

Unless Product Manager embraces market, customer, and technology awareness, I do not

foresee how a Product Manager could effectively build and articulate the new product

vision to all the stakeholders. In addition, Product Manager should also facilitate

consensus among all stakeholders on the new product vision.

Embrace tough decisions

New product development will invariably have surprises and surprises sprung from all

corners. Trust me it happens too often during the new product development. Meticulous

planning can only minimize those surprises and but not eliminated. Few surprises might

be in the form of:

Among million things that could be done as part

of the new product, if Product Manager has to

pick a finite set in alignment with resource spread

of engineering team and what customers exactly

require, (s)he should have precise understanding

of how every feature added to version 1.0 of the

new product would add value to customers

Page| 166

www.ProductGuy.in


Vendors’ inability to deliver their components as promised,

Vendors’ inability to support components for the perceived lifetime of the product,

Cost escalation of developing new product,

New technology not performing as expected,

Reduction in marketing budget,

Inability of the product to meet certain regulatory standards,

Churn of critical resources in development team and

Competition launching or announcing a superior product.

When Product Manager is confronted with above situations, (s)he should be geared to

take some quick decision and make some tough trade-offs as and when needed. Product

Manager can whine, shout at top of his voice, feel unlucky, feel let down but nothing takes

away his/her responsibility to make some quick decisions and tough trade-offs. To do so,

Product Manager should have terrible knowledge about the market, technology, and

customer. Such awareness can help product manager to take quick and informed

decisions. For instance, Product Manager has to eliminate certain features to launch the

new product on time, yet retaining the value proposition and appeal of the new product.

Does a decision need to happen based on intuition or based on data? I would always

prefer a data-driven decision. However, Product Manager might not always have

sufficient data and (s)he would fall back on intuition. Decision based on intuition is

definitely not random, Malcolm Gladwell has highlighted in his book ‘Blink’ through a

wide range of examples that a spontaneous decision based on intuition is often better

than a well thought out decision. Yet, Product Manager should be data driven and

intuition only succeeds with acquiring better experience. Product Manager does not

venture out to gather data only when the situation demands to make a quick and well-

informed decision, indeed data collection should be a regular activity and it should be

appropriately used when need arises. Data collection should never be on-demand. While

Product Manager consciously focusses on customer, market, and technology (s)he

periodically collates lots of data on those three aspects which can later be used as

situation demands.

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

Page| 167

www.ProductGuy.in


labelling, packaging etc. While submitting the business or pricing proposal for the 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 to build the new product. PRD would contain information on what product to

build and purpose behind building the new product, but it will not have any details on

how to build it. PRD will utmost provide only guidelines for how. During the development,

Product Manager has to keep a tab on engineering team is building the new product,

periodically review the product characteristics (color, shape, design etc.) and product

features, and intermittently share the feedback without waiting until the final product is

built. Great products are built through relentless attention to details and zero-tolerance

to mediocrity.

Product Manager has to focus on bigger things like ideation, revenue generation, strategy

etc. Like most of us put it – Focus on forest and not on trees. Nevertheless, there might

be scenarios where Product Manager might have to focus on trees (i.e. lay attention to

details). When Product Manager do has to focus on trees? I would say focus on trees

when there is no Deja-vu feeling that either Product Manager or any stakeholder has done

that before and not dare to say oneself ‘Been there, done that’. In those situations, start

focusing on trees.

In the case of new product development, if engineering team is doing something unique

to create a new user experience. Start paying attention to every detail. Some examples I

could quote – Shipping 1st SaaS product

1) Should pay attention to every detail including various modes of payments

2) License tracking and

3) Delivery of product (should I rather say service)

Great products are built through relentless

attention to details and zero-tolerance to

mediocrity

Focus on trees when there is no Deja-vu feeling

that either Product Manager or any stakeholder

has done that before, and not dare to say oneself

‘Been there, done that’

Page| 168

www.ProductGuy.in


Finally, how all of them interoperate to deliver a best possible experience to customers

of the new product – An online store shipping garments for the 1st time, need to focus on

details as simple as packaging. I remember the movie scene from ‘The Intern’ movie

where Anne Hathaway explains to her warehouse employees on how packing a dress

diligently will deliver better experience for their customers. Product Manager should

exhibit such attention to details.

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.

Guide

At every stage of product development play the role of the customer to quickly validate

the new product and provide feedback. Guide the engineering team during development

to make any technical trade-off, help them make right decisions. During product

development, we always reach certain crossroads where a decision to preserve or pivot

is necessary. Product Manager has to anticipate all such crossroads and be equipped with

all necessary data to take a prompt decision to avoid any delay in product development.

Customers cannot validate every single feature added to version 1.0 of the new product.

Invariably Product Manager has to play the role of a customer for reviewing every feature

introduced into the new product and provide feedback from the perspective of

prospective customers. Product Manager should continuously provide such feedback

during the entire course of new development product and definitely not wait until the

completion of new product development. Product Manager by virtue of observing

customers in their natural habitat are natural choice to impersonate them during new

Page| 169

www.ProductGuy.in


product development for providing feedback and review about the new product until the

start of product validation by customers through an MVP.

Facilitator

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 has to work as if there are no real boundaries to their role. In simple words,

Product Managers has to do whatever it takes to help engineering team build better

products even if it means ordering food for them while Product Manager does not lose

focus on his own set of responsibilities. For instance, Product Manager should never ask

the development team to cross the bridge for understanding the requirements of

customers. Instead, Product Manager performs the job and let development team focus

on new product development. Product Manager while being unreasonable and ruthless

in demanding more from the development team, (s)he also needs to provide a shield or

protective cover to the team from unnecessary deviations.

Embracing constraints

Everywhere resources are limited and even the flagship product of any Organization

would only get a finite set of resources. ‘Resource limitation’ is a universal fact, every

Product Manager has to confront this reality and still ensure how (s)he could take

advantage of available resources (time, headcount, or $ budget etc.) to create a vision of

the new product and realize that vision. So it does not suffice if Product Manager could

create a vision of the new product, (s)he has to be aware of all constraints and should

Product Manager has to work as if there are no

real boundaries to their role. In simple words,

Product Managers has to do whatever it takes to

help engineering team build better products even

if it means ordering food for them

Product Manager by virtue of observing

customers in their natural habitat are natural

choice to impersonate customers during new

product development

Page| 170

www.ProductGuy.in


have a clear understanding of how to execute the new product vision within the

boundaries of those prevailing constraints. Product Manager should never whine about

constraints instead should embrace them.

Self-Starter and Perseverance

Self-starter attitude should be a primary quality of Product Manager. Product Manager

by virtue of owning the product, having a broader understanding of the market in which

the product operates and with absolute awareness of which customers use the product,

why they use it and how they use it will have the ability to connect dots for identification

of opportunities to grow the product. Even after the launch of the new product, self-

starter quality alone will trigger Product Manager to generate demand, identify white

spaces etc. to expand revenue opportunities of the new product. While self-starter quality

could act as a catalyst for lots of product initiatives, perseverance 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 perseverance are two qualities that

should always go hand-in-hand. Perseverance sometimes facilitates Product Manager to

stick to a decision even though there is a feeling that it is wrong until it gets too late.

Perseverance is an essential quality, but it should abstain Product Manager from hanging

on to his/her views and beliefs indefinitely even though writing on the wall is clear. It is

worthy to have perseverance combined with good judgmental attitude of the prevailing

situation.

Finally, building the new product is a rigorous activity

and time is a very critical factor. One trait that every

stakeholder of new product development is to imbibe is

“DO IT RIGHT THE FIRST TIME”.

Product Manager has to be aware of all

constraints and should have a clear

understanding of how to execute the new

product vision within the boundaries of those

prevailing constraints

Product Manager should never whine about

constraints instead should embrace them

Page| 171

www.ProductGuy.in


Final Word: Product Manager is the face of the new 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 the new product is inevitable, yet Product

Managers has to realize that the team is building the new product and he has to let the

team take credit for the success of the new product.

Page| 172

www.ProductGuy.in


Concluding Thoughts

New product development involves conceptualizing value (Ideation), creating value

(Product Development), communicating value (GTM) and capturing value (Product Pricing

and Business Models). The eBook has focused in detail on all of them and tried to provide

a comprehensive framework on how to execute new product development successfully.

Product Manager has a critical role to play in each of them and his/her contribution to

the overall success of the new product is undisputable. We could state that without a

developer, the new product could not be built and without a sales engineer, the new

product could not be sold. Yet, the contribution of Product Manager is intrinsically tied to

how the product is conceptualized, built and evolved. It would be tough to downplay the

role of the Product Manager in the success of the new product. Product Managers being

termed as ‘CEO of the Product’ is not mere rhetoric.

I hope the eBook has provided deeper insights into building the new product and I would

appreciate your efforts to drop your comments about this eBook. Whatever

methodologies I have pointed out in this eBook are not hard and fast, they are best used

as a reference. Product Manager should override conventional wisdom around building

new products. It is essential to break new grounds through experimenting new

methodologies around pricing, business models, delivery, GTM, business review,

development methodologies etc. for building awesome products. Most assume the

responsibility of Product Manager ends with the creation of the new Product. It, in fact,

starts with rolling out the new Product.

Lastly, I dedicate this eBook to my wonderful and talented team who played a

tremendous role in building and launching two amazing products together in July 2014.

Happy Building GREAT Products

Page| 173

www.ProductGuy.in


Annexure A

B2B – Business-to-Business. Business-to-business (B2B) refers to a situation where one

business makes a commercial transaction with another. This typically occurs when:

I. A business is sourcing materials for their production process, e.g. a food

manufacturer purchasing salt

II. A business needs the services of another for operational reasons, e.g. a food

manufacturer employing an accountancy firm to audit their finances

III. A business re-sells goods and services produced by others, e.g. a retailer buying

the end product from the food manufacturer

HW/ SW – HW is the abbreviation for ‘hardware’ and SW is the abbreviation for ‘software’

IOT – Internet of Things. The Internet of Things (IoT, sometimes Internet of Everything) is

the network of physical objects or "things" embedded with electronics, software, sensors

and connectivity to enable it to achieve greater value and service by exchanging data with

the manufacturer, operator and/or other connected devices based on the infrastructure

of International Telecommunication Union's Global Standards Initiative. Internet of

Things connect physically and remotely by individuals, for both public sector and private

sector, in the sense of a computer network grid, of a created electrical device that is in

place, with economic benefit and potential usefulness. Each thing is uniquely identifiable

through its embedded computing system but is able to interoperate within the existing

Internet infrastructure. Experts estimate that the IoT will consist of almost 50 billion

objects by 2020.

B2C (Business to Consumer). The final customer is the consumer with a B2C business.

Housecleaning services, restaurants and retail stores are examples of B2C companies.

Websites that offer consumer products are B2C. The B2C sales cycle is shorter.

MVP – Minimum Viable Product. Minimum viable product (MVP) is a product with just

enough features to gather validated learning about the product and its continued

development. Gathering insights from an MVP is often less expensive than developing a

product with more features, which increase costs and risk if the product fails, for example,

due to incorrect assumptions. The term was coined and defined by Frank Robinson, and

popularized by Steve Blank, and Eric Ries. It may also involve carrying out market analysis

beforehand.

https://en.wikipedia.org/wiki/Steve_Blank

https://en.wikipedia.org/wiki/Eric_Ries

Page| 174

www.ProductGuy.in


First Customer Shipment (FCS) – The term First Customer Shipment (FCS) means the

first date on which a product is actually shipped to a customer.

The Unique Selling Proposition (USP) or Unique Selling Point is a marketing concept first

proposed as a theory to explain a pattern in successful advertising campaigns of the early

1940s. The USP states that such campaigns made unique propositions to customers that

convinced them to switch brands. The term was developed by television

advertising pioneer Rosser Reeves of Ted Bates & Company. Theodore Levitt, a professor

at Harvard Business School, suggested that, "Differentiation is one of the most important

strategic and tactical activities in which companies must constantly engage."

Return on investment (ROI) is the benefit to an investor resulting from an investment of

some resource. A high ROI means the investment gains compare favorably to investment

cost. As a performance measure, ROI is used to evaluate the efficiency of an investment

or to compare the efficiency of a number of different investments. In purely economic

terms, it is one way of considering profits in relation to capital invested.

Time to Market (TTM) is the length of time it takes from a product being conceived until

its being available for sale. TTM is important in industries where products are outmoded

quickly. A common assumption is that TTM matters most for first-of-a-kind products, but

actually the leader often has the luxury of time, while the clock is clearly running for the

followers

Cost of goods sold (COGS) are the direct costs attributable to the production of the goods

sold by a company. This amount includes the cost of the materials used in creating the

good along with the direct labor costs used to produce the good. It excludes indirect

expenses such as distribution costs and sales force costs.

Net Present Value (NPV) is a measurement of the profitability of an undertaking that is

calculated by subtracting the present values (PV) of cash outflows (including initial cost)

from the present values of cash inflows over a period of time. Incoming and outgoing

cash flows can also be described as benefit and cost cash flows, respectively.

Go-to Market (GTM) is the plan of an Organization, utilizing their inside and outside

resources (e.g. sales force and distributors), to deliver their unique value proposition to

customers and achieve competitive advantage. The end goal of a go-to-market strategy

https://en.wikipedia.org/wiki/Marketing

https://en.wikipedia.org/wiki/Television_advertising

https://en.wikipedia.org/wiki/Television_advertising

https://en.wikipedia.org/wiki/Rosser_Reeves

https://en.wikipedia.org/wiki/Ted_Bates_(advertising_firm)

https://en.wikipedia.org/wiki/Theodore_Levitt

https://en.wikipedia.org/wiki/Harvard_Business_School

https://en.wikipedia.org/wiki/Investment

https://en.wikipedia.org/wiki/Capital_(economics)

http://www.investopedia.com/terms/d/directcost.asp

https://en.wikipedia.org/wiki/Present_value

https://en.wikipedia.org/wiki/Time_series

https://en.wikipedia.org/wiki/Value_proposition

https://en.wikipedia.org/wiki/Competitive_advantage

Page| 175

www.ProductGuy.in


is to enhance the overall customer experience taking into account various aspects of the

value proposition such as the quality of the product and pricing.

ARPU - Average revenue per user (sometimes known as average revenue per unit) is a

measure used primarily by consumer communications and networking companies,

defined as the total revenue divided by the number of subscribers

PRD – Product Requirement Document. A Product Requirements Document (PRD) is a

document containing all the requirements to a certain product. It is written to allow

people to understand what a product should do. A PRD should, however, generally avoid

anticipating or defining how the product will do it in order to later allow interface

designers and engineers to use their expertise to provide the optimal solution to the

requirements.

ISPs – Internet Service Providers. An Internet service provider (ISP) is an Organization

that provides services for accessing, using, or participating in the Internet. Internet service

providers may be organized in various forms, such as commercial, community-owned,

non-profit, or otherwise privately owned.

Network functions virtualization (NFV) is a network architecture concept that proposes

using IT virtualization related technologies to virtualize entire classes of network node

functions into building blocks that may be connected, or chained, to create

communication services.

M2M – Machine-to-Machine. Machine to Machine (M2M) refers to technologies that

allow both wireless and wired systems to communicate with other devices of the same

type. M2M is a broad term as it does not pinpoint specific wireless or wired networking,

information and communications technology. This broad term is particularly used by

business executives. M2M is considered an integral part of the Internet of Things (IoT)

and brings several benefits to industry and business in general as it has a wide range of

applications such as industrial automation, logistics, Smart Grid, Smart Cities, health,

defense etc. mostly for monitoring but also for control purposes.

ASIC – Application Specific Integrated Circuit. An application-specific integrated circuit is

an integrated circuit (IC) customized for a particular use, rather than intended for general-

https://en.wikipedia.org/wiki/Integrated_circuit

Page| 176

www.ProductGuy.in


purpose use. For example, a chip designed to run in a digital voice recorder or a high-

efficiency Bitcoin miner is an ASIC.

FPGA – Field Programmable Gate Array. A field-programmable gate array (FPGA) is

an integrated circuit designed to be configured by a customer or a designer after

manufacturing – hence "field-programmable". The FPGA configuration is generally

specified using a hardware description language (HDL), similar to that used for

an application-specific integrated circuit (ASIC).

SLA – Service Level Agreement. A service-level agreement (SLA) is a part of a service

contract where a service is formally defined. Particular aspects of the service - scope,

quality, responsibilities - are agreed between the service provider and the service user. A

common feature of a SLA is a contracted delivery time (of the service or performance).

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used

to measure the size of a computer program by counting the number of lines in the text of

the program's source code. SLOC is typically used to predict the amount of effort that will

be required to develop a program, as well as to estimate programming productivity or

maintainability once the software is produced.

KLOC refers to thousand lines of code.

Key Performance Indicators (KPIs) evaluate the success of an Organization or of a

particular activity in which it engages. Often success is simply the repeated, periodic

achievement of some levels of operational goal (e.g. zero defects, 10/10 customer

satisfaction, etc.), and sometimes success is defined in terms of making progress toward

strategic goals.

WAN – Wide Area Network. A wide area network (WAN) is a telecommunications

network or computer network that extends over a large geographical distance. Wide area

networks are often established with leased telecommunication circuits.

Merchant Silicon is a marketing term used to describe the use of “off the shelf” chip

components to create a networking product and commonly used by company that design

their own silicon chips when explaining that their process is better and more efficient

https://en.wikipedia.org/wiki/Digital_voice_recorder

https://en.wikipedia.org/wiki/Bitcoin_mining#Bitcoin_mining

https://en.wikipedia.org/wiki/Integrated_circuit

https://en.wikipedia.org/wiki/Field-programmable

https://en.wikipedia.org/wiki/Hardware_description_language

https://en.wikipedia.org/wiki/Application-specific_integrated_circuit

https://en.wikipedia.org/wiki/Software_metric

https://en.wikipedia.org/wiki/Computer_program

https://en.wikipedia.org/wiki/Source_code

https://en.wikipedia.org/wiki/Programming_productivity

https://en.wikipedia.org/wiki/Maintainability

Page| 177

www.ProductGuy.in


Virtualized Network Function19 - Network functions virtualization (NFV) has needed to

be managed properly from its early stages – that’s what NFV MANO is for. With NFV

management and organization (MANO), management of NFV is now addressed by the

MANO stream. NFV MANO is a working group (WG) of the European Telecommunications

Standards Institute Industry Specification Group (ETSI ISG NFV). It is the ETSI-defined

framework for the management and orchestration of all resources in the cloud data

center. This includes computing, networking, storage, and virtual machine (VM)

resources. The main focus of NFV MANO is to allow flexible on-boarding and sidestep the

chaos that can be associated with rapid spin up of network components.

MANO (Management and Orchestration)20 - Network functions virtualization (NFV) has

to be managed properly from its early stages – that’s what NFV MANO is for. With NFV

management and organization (MANO), management of NFV is now addressed by the

MANO stream. NFV MANO is a working group (WG) of the European Telecommunications

Standards Institute Industry Specification Group (ETSI ISG NFV). It is the ETSI-defined

framework for the management and orchestration of all resources in the cloud data

center. This includes computing, networking, storage, and virtual machine (VM)

resources. The main focus of NFV MANO is to allow flexible on-boarding and sidestep the

chaos that can be associated with rapid spin up of network components.

Proof of concept (POC) is a realization of a certain method or idea in order to

demonstrate its feasibility, or a demonstration in principle with the aim of verifying that

some concept or theory has practical potential. A proof of concept is usually small and

may or may not be complete.

The definition provided for the above acronyms are directly picked from WIKI.

19 Source: http://www.webopedia.com/TERM/V/virtualized-network-function.html

20 Source: https://www.sdxcentral.com/nfv/definitions/nfv-mano/

https://www.sdxcentral.com/nfv/definitions/whats-network-functions-virtualization-nfv/

https://www.sdxcentral.com/nfv/definitions/etsi-isg-nfv/


https://www.sdxcentral.com/listings/etsi/

https://www.sdxcentral.com/nfv/definitions/whats-network-functions-virtualization-nfv/



https://www.sdxcentral.com/listings/etsi/

https://en.wikipedia.org/wiki/Feasibility_study

Building New Product - Experiences of a Product Manager

Business

Transcript of Building New Product - Experiences of a Product Manager