Building Enterprise Product - For Moving Targets of Customer Needs and Outcomes

2017
(4th Edition)
Murali Erraguntala
www.ProductGuy.in

Page| 1
www.ProductGuy.in
Building New Product – My Experiences
Table of Contents
PREFACE................................................................................................................................ 6
CUSTOMER NEEDS AND PROBLEMS ARE MOVING TARGETS ........................................................................ 6
MY EXPERIENCES.............................................................................................................................. 9
BUILDING ENTERPRISE PRODUCTS – MY EXPERIENCES......................................................... 11
PROBLEM DISCOVERY TO IDEA VALIDATION ........................................................................ 14
MEASURE DESPERATION INDEX ......................................................................................................... 15
IDEA VALIDATION ........................................................................................................................... 18
TIMING NEW PRODUCT – WHY NOW?................................................................................................ 19
OUTCOME THINKING....................................................................................................................... 22
PRODUCT-MARKET FIT - DESIRABILITY................................................................................................ 25
PRODUCT FEASIBILITY...................................................................................................................... 36
ESTIMATING MARKET SIZE ................................................................................................................ 36
PROFITABILITY – VIABILITY ............................................................................................................... 37
ORGANIZATION FIT ......................................................................................................................... 38
IDEA VALIDATION PHASE CHECKLIST.................................................................................... 39
BUSINESS REVIEW ............................................................................................................... 41
MARKET ANALYSIS.......................................................................................................................... 42
PRODUCT ANALYSIS ........................................................................................................................ 45
COMPETITIVE ANALYSIS ................................................................................................................... 50
FINANCIAL ANALYSIS ....................................................................................................................... 51
BUSINESS PLAN DILEMMA ................................................................................................................ 53
BUSINESS REVIEW CHECKLIST .............................................................................................. 54
BUSINESS PITCH .................................................................................................................. 56
LAYOUT OF SLIDES .......................................................................................................................... 56
LEAN CANVAS – SUMMARIZE THE PLAN............................................................................................... 57
NEW PRODUCT APPROVAL .................................................................................................. 59
1:1 EXECUTIVE BRIEFING.................................................................................................................. 60
HANDLE FEEDBACK POSITIVELY.......................................................................................................... 61
EXUDE CONFIDENCE........................................................................................................................ 61
REFINE.. REFINE.. REFINE ................................................................................................................ 62
IDENTIFY INFLUENCER...................................................................................................................... 62
WHAT DO YOU BELIEVE – DEFINES PURPOSE ....................................................................... 64
ORGANIZATION BELIEFS ................................................................................................................... 64

Page| 2
www.ProductGuy.in
TRANSACTIONAL VS RELATIONAL ENGAGEMENT.................................................................................... 66
DID YOU FIND YOUR WHY? ............................................................................................................. 69
COMMITMENT AND CONVICTION....................................................................................................... 71
BUILDING THE NEW PRODUCT FOR FUTURE......................................................................... 73
WHY LOOK INTO FUTURE? ............................................................................................................... 74
HOW FAR TO LOOK INTO THE FUTURE ................................................................................................. 76
HOW TO UNDERSTAND FUTURE?....................................................................................................... 78
UNDERSTANDING CAUSAL-EFFECT...................................................................................................... 82
DISCOVERING NEEDS – DRAFTING PRD ................................................................................ 86
PURPOSE OF THE NEW PRODUCT – THE UNDERLYING BELIEF.................................................................... 86
REQUIREMENT VS NEED .................................................................................................................. 87
DISCOVERING VS UNDERSTANDING REQUIREMENTS .............................................................................. 88
DISCOVERY OF CUSTOMER FOCUSED NEEDS ......................................................................................... 88
DISCOVERY OF MARKET FOCUSED NEEDS ............................................................................................. 89
THINK BOLD, THINK FUTURE ............................................................................................................ 93
ELABORATE ‘DEFINING ATTRIBUTES’ OF THE NEW PRODUCT .................................................................... 95
DRAFTING REQUIREMENTS AND FRAMING MVP LIST............................................................................. 95
DELIVERING SYNERGIES BETWEEN OLD AND NEW PRODUCTS ................................................................... 96
UNLEARN AND RELEARN .................................................................................................................. 97
HAZY MARKET – OBSCURE PRODUCT REQUIREMENTS............................................................................ 98
CATCH-UP CONUNDRUM – DON’T BLINDLY CHASE COMPETITION............................................................. 98
EVERY INCUMBENT PRODUCT IS VULNERABLE – DEFY CONVENTIONAL WISDOM......................................... 100
PRODUCT/ SOLUTION HYPOTHESES.................................................................................................. 102
FINALLY, ‘WHOLE PRODUCT APPROACH’........................................................................................... 103
IMPORTANCE OF PRD................................................................................................................... 106
DISCOVERING NEEDS IS A JOURNEY................................................................................................... 107
ROLE OF GREAT PRODUCT ROADMAP - TRANSLATING STRATEGY INTO ACTION........................................... 108
PRODUCT MANAGERS SHOULD TRULY DEMONSTRATE TECHNICAL LEADERSHIP .......................................... 110
DELIVERING AWESOMENESS – ALBEIT SELECTIVELY.............................................................................. 112
DRAFTING PRD CHECKLIST................................................................................................. 116
MONITOR PLAN................................................................................................................. 118
KEEP A TAB ON MACRO FACTORS ..................................................................................................... 118
OH…. PRODUCT MANAGERS GET EMOTIONALLY ATTACHED TO THE NEW PRODUCT, CAN THEY?................... 119
PRODUCT ECOSYSTEM – IS IT READY?............................................................................................... 120
PIPES VS PLATFORMS .................................................................................................................... 120
CONNECT THE DOTS...................................................................................................................... 121
MONITOR PLAN ACTIVITY CHECKLIST................................................................................. 122
PRODUCT PLANNING......................................................................................................... 123

Page| 3
www.ProductGuy.in
FORMULATE HYPOTHESES .............................................................................................................. 124
IS MVP A TRAP?.......................................................................................................................... 126
VENDOR/PARTNER SELECTION ........................................................................................................ 130
FREEZE PRODUCT REQUIREMENTS.................................................................................................... 132
PRODUCT VS SOLUTION................................................................................................................. 134
METICULOUS PLANNING ................................................................................................................ 136
METRICS, METRICS, AND METRICS ................................................................................................... 137
PRODUCT ACCEPTANCE CRITERIA ..................................................................................................... 139
PRODUCT FEASIBILITY VALIDATION ................................................................................................... 139
EVOLVE THE BUSINESS PLAN ........................................................................................................... 140
FINALLY, BUSINESS REVIEW............................................................................................................. 141
PRODUCT PLANNING CHECKLIST........................................................................................ 143
PRODUCT DEVELOPMENT.................................................................................................. 145
HIT THE GROUND ......................................................................................................................... 146
ACTIVITY CHECKLIST ...................................................................................................................... 147
KNOW THE PROCESS ..................................................................................................................... 148
PRICING ..................................................................................................................................... 148
GTM (GO-TO-MARKET) ACTIVITIES ................................................................................................ 162
WHOLE PRODUCT APPROACH ......................................................................................................... 167
PRODUCT DEVELOPMENT CHECKLIST................................................................................. 169
MY EXPERIENCES - WHAT DID WE DO DIFFERENTLY........................................................... 171
CONCEPTUAL VIEW....................................................................................................................... 171
LOOK INTO THE FUTURE................................................................................................................. 174
BEGIN WITH AN END IN MIND ......................................................................................................... 176
DATA-DRIVEN.............................................................................................................................. 179
ENGINEERING INTIMACY ................................................................................................................ 182
PLAN MY DAY – TOOK CONTROL OF MY TIME ..................................................................................... 185
ACT AND THINK LIKE A CUSTOMER.................................................................................................... 186
CROSS-POLLINATION OF AGILE AND WATERFALL.................................................................................. 188
LEAN (‘TAG ON’) MARKETING......................................................................................................... 192
PATH TO BUILDING A GREAT PRODUCT .............................................................................................. 195
ESSENTIAL TRAITS OF PRODUCT MANAGER FOR SUCCESS OF NPD ..................................... 197
TECHNOLOGY AWARENESS, MARKET AWARENESS, AND CUSTOMER AWARENESS ...................................... 198
EMBRACE TOUGH DECISIONS .......................................................................................................... 199
ATTENTION TO DETAILS ................................................................................................................. 200
METICULOUS PLANNING ................................................................................................................ 202
GUIDE........................................................................................................................................ 202
FACILITATOR ............................................................................................................................... 203
EMBRACING CONSTRAINTS ............................................................................................................. 203

Page| 4
www.ProductGuy.in
SELF-STARTER AND PERSEVERANCE.................................................................................................. 204
CONCLUDING THOUGHTS .................................................................................................. 206
REFERENCES...................................................................................................................... 207
ANNEXURE A .................................................................................................................................208

Page| 5
www.ProductGuy.in
Table of Figures
Figure 1 - Problem-Solution Fit...................................................................................27
Figure 2 - Product-Market Fit .....................................................................................28
Figure 3 - Addressable Market vs Serviceable Market vs Target Buyers ......................37
Figure 4 - Hierarchy of Needs .....................................................................................17
Figure 5 - Lean Canvas................................................................................................58
Figure 6 - Golden Circle..............................................................................................67
Figure 7 - Transformational Engagement vs Relational Engagement...........................68
Figure 8 - Threat matrix of virtualization in service provider network.........................76
Figure 9 - Growth rate of computing systems.............................................................80
Figure 10 - Sales of luxury vehicles in the USA..........................................................101
Figure 11 - Product Adoption Life Cycle....................................................................104
Figure 12 - Product Manager Relation Cycle .............................................................111
Figure 13 - Product Planning Phase - Timeline..........................................................123
Figure 14 - Internet User Growth vs Usage Growth ..................................................152
Figure 15 - Conceptual view of Smart Parking Solution.............................................172
Figure 16 - Conceptual view of Projector..................................................................172

Page| 6
www.ProductGuy.in
Preface
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 products 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 loses ground somewhere during the course of building an enterprise product.
Customer needs and problems are becoming moving targets
Why do most enterprise products fail?
The primary emphasis for building a great product is to discover a right problem and
getting married to it. However, customers’ needs and problems are increasingly becoming
moving targets. The needs and problems evolve, so do the solutions to address them (i.e.
the outcome too evolves) triggering an uncertainty of which needs or problems to address
and what outcomes to deliver. The biggest mistake that Product Managers commit while
building new product is to freeze needs and problems at a specific point in time and start
building products for those static needs. Nevertheless, Enterprise products address hard
problems and building such products consume around 12 – 24 months. With technology
evolving much faster than ever, market dynamics changing too fast, and human race
undergoing more changes than before, new needs or problems emerge, prevalent needs
or problems extinct, and solutions embracing technology advancements to address needs
or problems come in various shapes and forms. Primarily, Product Manager cannot taste
success building a product for static needs. Product Manager should learn to hit a moving
target anticipating how needs or problems change as a function of time in future. Agile
methodologies and MVP (Minimum Viable Product) address those fallacies by reducing
development cycles and incrementally validating whether the product is addressing right
1
Source: http://www.stage-gate.com/resources_stage-gate_latestresearch.php

Page| 7
www.ProductGuy.in
needs or right problems and delivering right outcomes. However, MVP seldom works for
enterprise products.
Why MVP and agile methodologies could not address those problems of dynamic
needs?
Enterprise products affect real businesses of customers, they might either help customers
increase revenues, manage costs or streamline operations. The fundamental truth is
enterprise products affect business in some form and hence they should be robust and
resilient with zero-tolerance for failures while addressing a real business problem that is
at the top of customers’ priority list. Therefore, delivering something quick, validating it
and incrementally evolving the product does not augur well for enterprise products.
Enterprise customers seek a complete solution. There is also a necessity for shrouding
development efforts of certain enterprise products in secrecy to introduce an element of
surprise and euphoria during launch. Then, how do Product Managers validate enterprise
products causing minimal interruption to its targeted customers? Through maintaining a
subtle balance between using MVP and relying on customer insights and experiments.
Product Manager shall use MVP at the initial stages of product development to validate
whether there is a real problem, whether the new product is addressing the real problem,
and whether the new product is targeting the right customer segment. The problem with
that approach is MVP does not consider time as one of its parameters. While constructing
a hypothesis and validating assumptions using MVP, Product Manager has to validate
assumptions across time-space ensuring whether needs or problems persist across the
duration of the product lifecycle and identify how they evolve. The appropriate approach
is to understand the causal effect between needs, problems and corresponding factors
that cause them. MVP framework for such analysis is:
I believe <target customers> experience < needs or problems> because
<trigger for needs or problems>
The fundamental premise is to understand what is causing the need while validating the
existence of a real problem or need and bundle the findings with customer insights to
understand how the need or problem manifests in future. MVP cannot be an excuse for
lack of customer insights. Building customer insights are one of the key foundational
pieces for building great products that enterprise customers want and it requires Product
EffectCause

Page| 8
www.ProductGuy.in
Managers to have a thorough understanding of customers, their business environment,
and business drivers that are causing needs or problems, which in turn can help
conceptualize solutions delivering the best possible outcome. There is a dire need for
restoring the lost art of gathering customer insights. MVP bundled with customer insights
and experiments are required for validating any assumptions related to the new product
and building a visual map of how customers’ needs or problems evolve and what new
outcomes they might desire. Product Manager should learn to hit a moving target
anticipating how needs or problems change as a function of time in future. How do you
hit a moving target with an arrow, we notice the rate at which the target is moving, how
long does it take for an arrow to hit the target and accordingly predict the possible
position of the target when the arrow is released. Product Manager should do something
similar not just to understand needs and problems of today but also to predict the needs
and problems while the new product hits the market. Doing so, the new product will hit
the bull’s eye when it hits the market.
Figure 1 - Customer needs as moving targets
Why does moving targets of needs and problems affect enterprise segment alone?
A unique challenge that Product Managers encounter with enterprise products alone and
it is not applicable for consumer products is that enterprise customers’ are resistant to
frequent product upgrades because of CAPEX (Capital Expense) and OPEX (Operating
Expense), they tend to use a product for a longer period of 3-5 years (especially on-

Page| 9
www.ProductGuy.in
premise products). On the contrary, business models of most consumer products rely on
frequent product upgrades. There is no benefit in stacking all the value in a single product
and making customers stick to a consumer product for 3-5 years. The duration for moving
target of needs or problems of enterprise customers just shifts from product launch to
eclipse the entire duration of the product lifecycle.
Product Manager should anticipate customers’ needs or problems as a function of time
across the entire duration of the product lifecycle. Customer insights combined with
extensive knowledge of how markets evolve, how technologies evolve, and how
customers’ behaviors change should provide an estimation of how customers’ needs or
problems change as a function of time and what new outcomes are possible. For certain
enterprise products, addressing customers’ needs or problems as they evolve is not
entirely possible without building a product architecture or a platform that can scale. I
was once managing an HW product used by ISPs (Internet Service Providers) for defining
policies of their internet users. During the launch of the product, internet speeds offered
to each user was low. However, the internet speeds offered to each user raised
exponentially in few years and the product could not meet the new requirement resulting
in the early retirement of the product (or rather the product has to retire prematurely).
In the enterprise segment, we tend to face a similar problem with complex SW products
as well and refactoring the architecture can help but it will be costlier. Even so, refactoring
the entire HW or product architecture takes time and there is a risk of not being able to
address evolving needs or problems in a timely manner. When the only thing that is
certain about future is uncertainty, a question that stares at every Product Manager is
how much to scale and when? The eBook captures my experiences for addressing those
challenges and providing structured guidelines for building great enterprise products that
can scale for future needs.
My experiences
We often learn by doing. Every journey or endeavor teach us back something, they part
us with some memories and experiences to ponder because perfection and flawlessness
are elusive. The eBook is a reflection of my experiences and learnings learned through
hard way of building the new product and introspecting upon failures and experiences
encountered during new product development. Through elaborating my experiences of
building the new product in this eBook, I have structured actionable plans across various
phases of product development for successfully building great products that are:

Page| 10
www.ProductGuy.in
1. Built on a foundation of strong product vision that defines the purpose and
objective behind the new product.
2. Built to address real needs of real customers and as desired by those real
customers.
3. Built not just for needs of today but also for needs of tomorrow and in alignment
with the evolution of technology trends, market trends, and changing customer
needs and their behaviors.
4. Built with all essential attributes that will drive customer preferences towards the
new product.
5. Built through meticulous planning, impeccable execution, relentless attention to
details, and zero-tolerance to mediocrity.
The actionable insights presented throughout this entire eBook will reinforce the above
five key tenets for building great products. The eBook talks about new product
development from the perspective of a Product Manager. Therefore, I consciously
focused on activities exclusively performed by Product Manager during various stages of
new product development. This is not a book about product development methodologies
and therefore there is no focus on any specific methodology (including agile). 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 adopted 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 in a
separate section called ‘What did we do differently’. I also attempted to intertwine those
experiences throughout this eBook.
I want this eBook to remain as a guiding force in providing actionable insights for building
enterprise products. 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. If you like the eBook,
please help spread the word about this eBook.

Page| 11
www.ProductGuy.in
A copy of the eBook is downloadable from www.ProductGuy.in/eBooks/
Happy Reading!!!
Murali Erraguntala
LinkedIn| Slideshare| Twitter| Blog| Email
The eBook is still WIP (Work In Progress) attempting to prepare some better framework
on how to identify evolving needs or problems and ascertain how technology
advancements can lead to new outcomes. If you have any thoughts or if this subjects
interests you, please reach me for further collaboration.

Page| 12
www.ProductGuy.in
Building enterprise products – My experiences
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 while strictly adhering to the five tenets of
building great products that I had mentioned earlier. In addition, I have also focused on
an additional stage called monitoring plan, which is mostly a forgotten item in new
product development. Monitor plan is to assess what business drivers and external
factors cause customer needs or problems to evolve. Later, monitor how they could
possibly alter the landscape of customers’ needs or problems during the entire duration
of product lifecycle. With advancements in technology, outcomes to address evolving
needs or problems too vary and monitor plan will capture the probability of how
outcomes could change, accordingly ensure that the new product is ready for delivering
those outcomes. Building a new product falls into two categories (i) building a new
product belonging to a new category and (ii) building a new product belonging to an
existing category. The major difference is that in the latter 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. In the former scenario, Product Manager should extensively validate the new
product idea. 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
margin?
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

Page| 13
www.ProductGuy.in
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
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. A strong foundation
of understanding the needs or problems of customers, their business environment and
drivers triggering needs as of today will help Product Managers expand their horizon into
future. The initial phases of product development focus on building that strong
foundation. Otherwise, subsequent efforts of Product Managers to comprehend future
by connecting it to the present and the past will be a complete fiasco.

Page| 14
www.ProductGuy.in
Problem discovery to idea validation
The journey to building a great product that customers love starts with identifying a right
problem. Product Managers should be problem seekers to discover problems or needs
that customers encounter in their business. The discovery process involves developing an
empathy with customers to understand their business, needs or problems that their
business foresee in the near and long-term, and what drivers or factors are triggering
those problems. How customers are handling those existing problems, what alternate
outcomes are most desirable to address those problems. Product Managers should rely
on both what they hear and what they see to develop a mental map of all the problems
or needs that customers encounter, how they are addressing them currently, and what is
causing those needs or problems. Product Managers should spend time refining the
problem statement and prioritizing which problems to address. When the focus is on
identifying right problem, conceptualizing a solution to address that problem will result
in a great product that customers want.
Figure 2 - Problem focus
On the contrary, the journey to building products triggers with an idea. An idea often
evokes the feeling of a solution and not the actual problem. Ideas are everywhere and we
hear them every day – An idea that can disrupt the entire market, an idea that can sweep
customers of their feet, and an idea that can displace all competitors. Seldom have those
Problem Solution

Page| 15
www.ProductGuy.in
ideas had a backing of right problems. Most ideas give rise to a problem statement rather
than being born out of a problem statement. Such ideas try hard to map to a problem
that might not be a real problem. Further confirmation bias will shield a Product Manager
from seeing the reality. Never start the journey of building a product with an idea, start
with a problem and get married to the problem, so you will strive to create a right solution
for the right problem.
Figure 3 - Solution focus
Measure desperation index
I am borrowing Maslow hierarchy of needs framework to understand the priority of the
need or problem that Product Manager chose to address. 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, and 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.
Solution Problem

Page| 16
www.ProductGuy.in
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, B2B customers buy
products for office automation, payroll, email communication, sales and leads tracking,
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 B2B 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, 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.
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
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| 17
www.ProductGuy.in
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
observing purchasing patterns of customers. Purchasing patterns of not specific products
but entire products in the purchase list. Pyramid should now provide the list of needs that
are at the top of customers’ priority list.
Figure 4 - Hierarchy of Needs2
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
2
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

Page| 18
www.ProductGuy.in
when customers drastically cut the budget, using the pyramid of the hierarchy of needs,
Product Manager can easily identify what needs do customers might be willing to forego.
Desperation index provides an indication of what needs are important to customers.
Nevertheless, there is no hard and fast rule for always picking needs at the top of the
priority list.
Idea validation
Building a product is like a weaving a story about how the product will bridge the gaps
between current outcomes and desired outcomes for the problems that the new product
will address. Idea validation is about collecting evidence to check whether we have
chosen the right problem, whether the outcome is most desirable to customers, and
whether the idea meet a viable business model for creating a sustainable business.
I recommend validating all generated ideas based on three parameters3
.
(i) Desirability - Do customers desire the new product to address their existing
needs or problems. Does the product deliver best possible outcome
(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? Do the new product
meets a viable business model?
(iii) Feasibility - Is it technically feasible to build the new product that will optimally
address customer needs or problems? Does the Organization has required
competence to build and market the new product?
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
to transition 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.
3
Desirability, Viability and Feasibility was elaborated by Tim Brown in his book ‘Change by Design’
Understanding ‘WHY NOW’ is critical to ensure
that the new product is neither too early nor too
late to the market

Page| 19
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 determine 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 too 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 discussion. 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 needs are in existence since a longtime but unaddressed
so far. However, the recent improvements in technology or increase in economic
status of the population or existence of any other factors would have made it
either 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
the existence of certain drivers.

Page| 20
www.ProductGuy.in
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 make 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 that are capable of creating a conducive environment to address
dormant needs.
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.
 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. mPesa4
.
4
Source: http://www.vodafone.com/content/index/what/m-pesa.html

Page| 21
www.ProductGuy.in
 E-commerce enabled the possibility of selling less of more niche products5
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 marketplace 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.
 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.
5
Chris Anderson has elaborated about the concept of selling less of more in his book ‘The Long Tail’.

Page| 22
www.ProductGuy.in
Technology need not be the only 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 alternative energy and energy-efficient
products.
 Depletion of potable water would create the need to derive reliable alternate
sources of potable 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 a 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 an environment is conducive for it to prosper.
Evaluating timing of the new product idea will provide enough evidence that problems or
needs do exist and it will provide sufficient indications of what factors are driving needs
or problems or what factors are trigger new outcomes (mobile banking – old needs but
new outcomes). The analysis that Product Managers do while evaluating timing factor
and shreds of evidences that they collect will be right indicators to predict the future for
determining how needs, problems, and outcomes evolve or vary across the entire
duration of product lifecycle.
Outcome thinking
Outcome thinking is not being aware of what the product delivers but being aware of
what target customers accomplish with the new product. Outcome thinking glues Product
Manager to the problem and not to the solution. It is essential to imbibe outcome thinking
during validation of new product idea to ensure that the idea is indeed delivering the
outcome desired by target customers.

Page| 23
www.ProductGuy.in
Did you ever wonder why smartphones are hurting gum sales? What is the connection
between those seemingly unrelated products? Those products are in relation to the
outcome that they deliver. Customers buy gum to eradicate boredom and with the
emergence of smartphones, there was never a scope for boredom leading to declining of
gum sales. The outcome thinking has suddenly provided a new revelation that gums are
competing with smartphones to deliver an outcome i.e. eradicating boredom.
Figure 5 - Problem focus
My tryst with outcome thinking started with a milkshake example that Christensen
Clayton outlined as part of his jobs-to-be-done framework. It appears that people bought
milkshake because it helped them tide over a long and boring drive. Suddenly, the
competitors to milkshake are not just any other drink or food but just about anything,
that can help customers tide over a long and boring drive. Outcome thinking changes the
entire perception of perceived alternatives. Outcome thinking facilitates Product
Manager to stay married to the problem and not to the solution. When Product Manager
remain married to the problem (long and boring drive) and not to the solution
(milkshake), they could constantly think of better solutions through enhancing existing
product (incremental changes to milkshake – make it thicker or provide in large
quantities) or introducing a new product. Doing so, we keep continuously churning out
great product beating inflection points.
Outcome thinking facilitates Product Manager to
stay married to the problem and not to the
solution
Problem Solution
Outcome

Page| 24
www.ProductGuy.in
Focus now shifts away from solution or idea to an outcome. Solutions or ideas are means
to deliver the outcome. Outcome thinking always glues Product Manager to focus on
what customer intended to accomplish with the product. Solutions or ideas will always
be a by-product of outcome thinking. Outcome thinking is a cornerstone for validating
ideas and evaluating how idea delivers better outcomes than existing alternatives. From
the perspective of alternatives that customers use to accomplish an outcome, Product
Manager has to evaluate whether there is sufficient incentive for customers to migrate
to newer outcomes and what would hold them to maintain a status quo. Are there any
costs that customer might incur for migrating to newer outcomes. Product Manager has
to evaluate both cost and incentives to understand the willingness and ability of
prospective customers to embrace newer outcomes.
Current Outcome
 What is the current
outcome
Alternate Products
 List all alternate products
that customer use to
accomplish the outcome.
Incentives
 What is the push for
customers to migrate to
new outcome
New Outcome
 What is the new
outcome, how is it
different from old
outcome
New Product
 What is the new product
Cost
 Is there any cost that
customers incur to
migrate to a new
outcome.
 Identify what pulls
customers to remain with
status quo.
Customer Needs or Problems
In our earlier example, tide over a long and boring drive is a customer need or problem
while milkshake is an outcome. Outcomes are manifestation of solutions
Push
Pull

Page| 25
www.ProductGuy.in
Product-Market fit - Desirability
While talking about timing, I was focusing on a set of drivers that (i) make 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?
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 the 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 the 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
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 it

Page| 26
www.ProductGuy.in
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 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 or deliver the desired outcome?
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 that Product
Manager took earlier to identify the existence of the need, to understand drivers causing

Page| 27
www.ProductGuy.in
the need, and to understand consequences of not addressing the need can help identify
the outcome intended by customers. Often a new product can address multiple
outcomes. Customers use a smartphone for audio/video calling, taking photographs,
chatting, navigation etc. While building the new product, Product Manager has to identify
all possible outcomes and categorize them into the core and allied outcomes. Customers
really care if the product idea helps them accomplish core outcomes. Delivering allied
outcomes 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 whether the new
product idea will help customer accomplish core outcomes.
Core outcomes and allied outcomes are synonymous with needs vs wants. Customers
would consider the new product only if it is addressing their needs and attempts to
address 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 outcomes, identify customers’ needs and customers’ 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 6 - 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,

Page| 28
www.ProductGuy.in
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 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.
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 the 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 a 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 7 - Product-Market Fit

Page| 29
www.ProductGuy.in
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.
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 about 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 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
The real indicator of reaching product-market fit
is when customers start exclaiming that is the
product for me

Page| 30
www.ProductGuy.in
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 indicating the existence of the real need
for luxury cars – Quite obviously reliable reports indicating the rise of high net
worth individuals in a developing country along with confirmation of their
penchant for luxury goods is sufficient indication for companies like Bentley to 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 product6
. Freshdesk identified the gap (or could I say ‘White
Spaces’) successfully emerging as a reliable alternate player in customer support
software.
Signs indicating the 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
6
Source: http://blog.freshdesk.com/the-freshdesk-story-how-a-simple-comment-on-h-0/

Page| 31
www.ProductGuy.in
need not look for signs indicating the existence of a need, instead (s)he can validate
the existence of drivers that can be conducive to generate a demand for the need.
Share the idea
Robert Kennedy co-founder of MaxMyTV pitched the idea of Interactive TV at a
startup event in Pittsburgh in 20127
. 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 an idea with anyone citing that an 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
an idea. Nevertheless, sharing an 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 idea8
. 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.9
7
Source: http://yourstory.com/2014/09/maxmytv/
8
Source: http://blogs.wsj.com/accelerators/2014/10/20/scott-weiss-round-up-the-experts/
9
Source: https://en.wikipedia.org/wiki/IronPort
Signs indicating existence of a need are definitely
ubiquitous but sources signaling a need are well
defined.

Page| 32
www.ProductGuy.in
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.
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 video 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 video10
.
10
Source: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/

Page| 33
www.ProductGuy.in
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 the 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
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 an 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 should pivot
new product development and should formulate an 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

Page| 34
www.ProductGuy.in
more on it in product planning section. For business review, highlight the plans to
build an MVP and the purpose of 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
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 fundamental for 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.
The efficacy and efficiency of respective
methodologies will determine the choice
between MVP and prototype

Page| 35
www.ProductGuy.in
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
lucid on how the outcome of MVP would affect new product development. The
outcome of MVP should be binary resulting in either pivot or preserve. Product
Manager should have unconditional clarity 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 is 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.

Page| 36
www.ProductGuy.in
Product feasibility
In addition to establishing the 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 as envisioned is possible and the new product will comply with all
required procedures (if any). 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 the
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
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 demographics) of TAM is targeted first.
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
local geo-market before expanding globally. In such case, Product Manager should initially
Feasibility is not only about evaluating technical
feasibility but also about evaluating the
feasibility to build the new product as envisioned
within acceptable cost structure and timeline

Page| 37
www.ProductGuy.in
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.
Figure 8 - Addressable Market vs Serviceable Market vs Target Buyers
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 a new low-cost product idea. Much of this space
Total Addressable Market
Total Serviceable Market
Target Buyers

Page| 38
www.ProductGuy.in
might fall under the category of ‘Fortune at bottom of the pyramid’11
conceived by C.K.
Prahlad12
. If customers are 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.
Organization fit
Product Manager should conclude the ideation phase trying to evaluate whether the new
product is in alignment with the Organizational 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.
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), a smaller chunk
of customers could only afford it.
11
Reference: https://en.wikipedia.org/wiki/The_Fortune_at_the_Bottom_of_the_Pyramid
12
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| 39
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 the
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| 40
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
(Use at least 2 distinct approaches to measure 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 the total market size?
 What is the 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
 Where in the hierarchy of needs, is the need address by the new product
positioned?
o Is the desperation index – low, medium or high?

Page| 41
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 the capability to
reach the target segment?
d. 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?
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 a profound impact on lives of target customers?
e. What is the platform strategy? Are we leveraging existing platform or
creating a 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| 42
www.ProductGuy.in
3. Competitive Analysis
a. How does Product Manager position the new product against the
competition? What would be vectors of differentiation for the new
product?
b. What is the current positioning of competitors?
c. How could competitive landscape 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 the
business plan in the form of a word document or a power-point slide 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. Analyzing the impact would help Product Manager
comprehend how much customers would really care for addressing the need.

Page| 43
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 the 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 needs 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 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?
Analysts can provide precise information on the overall size of the market and
growth potential of the market. 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| 44
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 the 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 potential in long term.

Page| 45
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 the 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| 46
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 a 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 an 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 a
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 product architecture team
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
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| 47
www.ProductGuy.in
unique 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, capital expense incurred to buy
HW and other equipment required to build the new product, and cost to
manufacture and distribute the new product 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

Page| 48
www.ProductGuy.in
 Expansion of product portfolio for a significant value addition. E.g. LinkedIn
acquisition of Pulse to have users spend more time on LinkedIn
 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 the existence of in-
house competencies, cost to develop, time to develop etc. can determine the
choice between buying and making. 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 product
architecture team has to evaluate the necessity to introduce any new technology.

Page| 49
www.ProductGuy.in
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
any case, the risk is higher and hence it is appropriate to explicitly list new
technology introduction during the 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 the 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.

Page| 50
www.ProductGuy.in
 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
(1) Does the proposed new product address the right problem?
(2) Does the proposed new product address 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 validate those 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 the 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| 51
www.ProductGuy.in
 How could competitive landscape 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 use 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| 52
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. There is no need for extensive elaboration of those details
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 –
“With the emergence of connected cars, several other
IOT use-cases, machine-to-machine communication,
there is a huge demand for edge analytics in order to
avoid overloading a transport network with duplicate
information. Our expertise in analytics will provide a
headway in addressing the exact need of target
segment delivering more added value. Few million
dollars investment coupled with the unique business
model to charge % of cost savings can catapult the new
product as a major player in a $B edge analytics
market.
I am merely attempting to build an ‘Elevator Pitch’ for the new product.
I am precisely addressing why it is the attractive market for us, how our expertise can put
us in an enviable position to better address prevalent and evolving problems of the target
segment. In addition, the elevator pitch should be loaded with some details that
immediately capture the attention of everyone.

Page| 53
www.ProductGuy.in
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
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 does own the entire responsibility for the 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| 54
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 the capability to reach
the target segment?
 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 a profound impact on lives of customers?
 What is the platform strategy? Are we leveraging existing platform or creating a
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| 55
www.ProductGuy.in
Competitive Analysis
 How does Product Manager position the new product against the competition?
What would be vectors of differentiation for the new product?
 What is the current positioning of competitors?
 How could competitive landscape potentially change in future?
 What is the unfair advantage?
Financial Analysis
 What is the ROI of the new product?

Page| 56
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 are 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
 Is the need recognized or known to customers or does the new product has to
generate demand?
Market

Page| 57
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 will it 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.
Product/
Competition$$$Value

Page| 58
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 9 - Lean Canvas14
14
Source: https://leanstack.com/businessmodelcanvas/

Page| 59
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| 60
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 an 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 to 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| 61
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. Ideas are everywhere what executives look
for is the commitment and conviction of someone to carry the idea to the finish line.

Page| 62
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| 63
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| 64
www.ProductGuy.in
What do you believe – Defines purpose
Conceptualization of new product sans any belief is deprived of the right purpose. What
the new product could do and how it could do does not define the purpose. Those are
transactional items, purpose and belief transcend all of them to create an emotional
connection with customers making them believe in the product believe in what it does
through creating a vision of the future. 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. Belief and purpose can also define
the marketing message that will make customers believe in the product believe in what
it does. The difference between good and great product lay in its ability to define why.
Organization beliefs
What does your Organization believe in – Is the new product built upon that foundation
of belief? 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 exist and how it is intended to deliver
its desired functionality. Otherwise, how do products of the same category from two
different companies differ, what is the secret sauce that differentiates those products?
Assume smart phones from Samsung and Apple. Are n’t the organization beliefs
contribute to the secret sauce of respective smartphones? Few more elements to ponder
upon, what do great companies like Apple, Google, Facebook, Amazon, Netflix etc. believe
in, are n’t their products direct reflection of what they believe. Therefore, every new
product built should embody the Organization beliefs and the new product vision should
be a reflection of those beliefs.
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 how it is
intended to deliver its desired functionality

Page| 65
www.ProductGuy.in
What does Apple believe in – Shall I state ‘Innovation, Simplicity and Building Great
Products’.
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
and pass the following belief test.
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 Apple? Can the new product
idea be the next big bet?
It is not always about building unique products, but also about 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 its approach to building a simple and elegant music player that had powerfully
integrated 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

Page| 66
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
fundamentally 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.
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? Product Manager is explicitly pondering over the beliefs of
the Organization and the purpose of its existence. Those elements provide a foundation
for defining ‘THE WHY’ behind the new product. Defining WHY behind the product
imbibes the belief and purpose within each stakeholder, so all stakeholders know why
It is not always about building unique products,
but also about building products uniquely that no
one else dared to build so

Page| 67
www.ProductGuy.in
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 10 - Golden Circle
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
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.

Page| 68
www.ProductGuy.in
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.
Figure 11 - Transformational Engagement vs Relational Engagement
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
make a decision. Organizations make better products and survive longer if decision
making is not centralized. However, Organization should aid its employees with
guidelines. Belief and purpose are the only way to provide guiding principle or tenets for
the decision-making process.
It is not what we make or sell. It is what we
believe makes a lot of difference both internally
and externally
How
What
Why
Transactional Engagement Relational Engagement

Page| 69
www.ProductGuy.in
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
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 makes
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, they start believing in the ability
of the Organization and its product to create 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.
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
Organizations make better products and survive
longer if decision making is not centralized

Page| 70
www.ProductGuy.in
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.
How often has a Product Manager noticed following comments when interacting with
customers – Your product does not what competitor’s product does, 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.

Page| 71
www.ProductGuy.in
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 the current state, and where the
Organization intends to head from now 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 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 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 upon realizing 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
People embrace change only upon realizing what
is in it for them

Page| 72
www.ProductGuy.in
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.

Page| 73
www.ProductGuy.in
Building the new product for FUTURE
While drafting business review, I had extensively focused 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 is not
Nostradamus to 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 has to build customer insights through experiments and observing
customers in their natural habitat, immersing in their business, assimilating their business
process, problems, and challenges and not just listen to what they say but to read
between the lines to understand what they did not say
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 the 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 the subsequent chapter. One plausibility to understand future is to
comprehend what has caused the present to diverge from past and use that as a
reference to anticipate what will cause future to diverge from present.
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

Page| 74
www.ProductGuy.in
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 (Time-To-Market). The 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. Every product
has certain scale parameters and every scale parameter has an expiry date. Product
architecture plays a crucial role in determining whether those parameters can scale
beyond their initial limits. Some of the parameters have a soft limit i.e. the parameters
can scale beyond their initial range without requiring too much rework. Consider SaaS
products, demand for a SaaS product can rise from 1000 customers to 1 million customers
very quickly immediately after determining the product-market fit. With cloud providers
like AWS, Azure scaling of SaaS products is never difficult. SaaS companies can deploy and
distribute multiple instances of their products globally. Cloud providers have efficient load
balancers to manage those instances. Therefore, it is sufficient to build a SaaS product for
few thousand customers and scale them as the demand arises. However, scale
parameters of few other products (mostly HW products) have a hard limit. Increasing
them requires a lot of rework, requires Product Manager, architects, and developers to
hit the drawing boards. What we should essentially consider is the cost of revisiting the
drawing boards. There could also be a counter argument that what if customers would
never require the scale that the product delivers. True, we are then not adapting lean

Page| 75
www.ProductGuy.in
development methodologies. We are wasting resource attempting something that
customers never require. It is for Product Manager to make those trade-offs.
Building new product involves lots of decision-making. Certain decisions are irreversible
or reversing them will cost a lot. Other categories of decisions are always reversible.
Decisions involving scale parameters with hard limits are irreversible decisions and the
decisions involving scale parameters with soft limits are reversible decisions. Product
Manager has to make both kinds of decisions during the course of building the new
product. However, certain irreversible decisions are dependent on anticipation of how
customer requirements evolve in future. Irreversible decisions cannot be made
irrationally. The decisions are taken thoughtfully after analyzing all possible risks.
However, for a well-informed decision-making, Product Manager should develop deeper
insights about customers to understand how their future requirements might evolve.
Developing customer insights is like unearthing those deep truths about customers that
customers themselves might not have acknowledged directly.
Considering the lifetime of an HW product or a complex SW product could at least be for
five years with a possible extension of support for a couple of years, anticipating how
future might affect the new product is crucial to ensure that the new product is scalable
for precise future needs of target customers. 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 additional software
is almost zero. So building scalable products that can sell more for a longer duration is
required for better revenues with higher margins while adhering to lean practices without
wasting any resources unnecessarily through developing better customer insights.
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, back in 2013), I could anticipate two threats (1)
Developing customer insights is like unearthing
those deep truths about customers that
customers themselves might not have
acknowledged directly

Page| 76
www.ProductGuy.in
YesNo
Adoption
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 that can help Product
Manager consciously identify the probability of occurrence as elaborated in detail later in
this eBook.
Figure 12 - Threat matrix of virtualization in service provider network
I had earlier indicated about three possible threats for the new product. I did use one of
them to draw the below threat matrix to assess the impact of virtualization on the
proposed new product. There are two possible scenarios:
i) ISP customers adopt virtualization in various insertions points in their network
beyond DC (Data Center).
ii) ISP customers do not adopt virtualization in their network. Virtualization is
restricted to only DC.
Probability
High Low

Page| 77
www.ProductGuy.in
The subsequent section of this eBook elaborates how to analyze factors that could
contribute to various scenarios outlined in threat 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 poses 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 long, then Product Manager has the responsibility to anticipate the need
to get the 1st
mover advantage and to excite customers before competitors do. In the 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 the time taken to
research, develop and validate the new product.
Another aspect of how far to look into the future will depend on the two other factors
that I had outlined earlier while discussing why to look into the future.
1. To build a product architecture that allows the product to scale for future needs
2. To conceive a threat matrix.
The above factors essentially mean 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 the 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 the 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| 78
www.ProductGuy.in
How to understand future?
Understanding future is tantamount to diligently anticipating the following:
 How do customers’ needs evolve?
 How do technologies evolve?
 How do markets evolve?
 Who are customers of tomorrow?
 What are customer needs of tomorrow?
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 evolve, 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 invented 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. We are always on the cusp of major technological changes, a structured analysis
is required to differentiate fad from reality for analyzing which major technologies are
poised to become a reality and what factors could cause them to enter a mainstream

Page| 79
www.ProductGuy.in
market for wide adoption. Later evaluate the impact to the new product both from a
perspective of threat and opportunity.
Let me 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| 80
www.ProductGuy.in
Figure 13 - 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 below 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 can 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
beyond than just playing chess and driving cars. Simultaneously it is essential to undergo
16
Source: http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-
1.html?utm_source=share&utm_medium=twitter&utm_campaign=sm_share

Page| 81
www.ProductGuy.in
similar analysis to understand when big data systems required for AGI systems will
actually evolve. Will it happen before 2030 or later? We should always perform such
analysis to understand both threats and opportunities staring at the new product from
related emerging technologies.
While trying to understand the impact of technology either from a perspective of threat
or from a perspective of opportunity over a definitive timeline, it is essential to do some
structured analysis as shown above. Such analysis is 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, economy etc. while anticipating
how future unfolds and determining how all those factors will influence the evolution and
acceptance of a 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 could have provided Kodak clear hindsight of when digital
photography is ready for mainstream market and what factors can aid its adoption.
Accordingly, Kodak could 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 approximate duration for such
possibility? I presume traditional companies making cars might have done such analysis
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 the 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| 82
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

Page| 83
www.ProductGuy.in
a simple linear model of combining smaller changes. Along with identifying the smaller
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 overly 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?

Page| 84
www.ProductGuy.in
 How can the technology mature? Can affordability and maturity of the technology
be good enough factors for adoption of the technology in B2C space?
 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 adopting virtualization in service provider networks.
We drew following observations that prevent the adoption of virtualization in service
provider networks. Below observations, reflect scenario as in 2013 and not as of today.
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 virtualized product (i.e. a
software appliance running within a virtualized environment). 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 a higher
growth rate in next 5 years.

Page| 85
www.ProductGuy.in
 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
 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
a 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.
The ultimate goal is to create a mental map of all possibilities of future and then identify
the factors that determine the likely occurrence of each of those possibilities. The biggest
responsibility for Product Manager is the ability of narrowing down the possibilities to
just one future that is most likely to occur based on the identification of corresponding
causal factors that is highly likely to occur. The fundamental idea is that we should not
leave anything for chance.
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| 86
www.ProductGuy.in
Discovering needs – Drafting PRD
After the approval of new product development, Product Manager should embark on next
steps 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 the business
case.
 Why customers need the new product?
 What are the top customer needs to be addressed by the new product?
 Why is it 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?
Responses to above queries would facilitate Product Manager to outline a 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, the purpose behind the new product and the objective 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
Very critical to laying
foundation for a flexible
product architecture or
platform

Page| 87
www.ProductGuy.in
product. The previous section of this eBook has articulated in detail the foundation that
defines the belief and purpose of the new product.
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| 88
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 are
identification of needs recognized by target customers. Product Manager understands
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’.
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
of customers outlining the expected business outcome, Product Manager should
thoroughly analyze the reasons for customers proposing such outcomes.
Never ask customers what they need, always
always always ask why they need

Page| 89
www.ProductGuy.in
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 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.
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 are
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| 90
www.ProductGuy.in
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 happening to
dependent micro or 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.
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
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| 91
www.ProductGuy.in
 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.
 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

Page| 92
www.ProductGuy.in
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 micro or macro factors. Once Product
Manager understands the dependent micro or macro factors (such as economic
principles, regulatory policies, internet trends, technology evolutions, per capita income,
customer behaviors 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.
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.

Page| 93
www.ProductGuy.in
(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 in the 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 recognize 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
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

Page| 94
www.ProductGuy.in
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 boldly 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. When
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 will 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
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.
Efficient discovery of needs will lead to an
effective invention of the new product
To build a great product, think ahead, think
future. More importantly, think bold

Page| 95
www.ProductGuy.in
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.
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 requirements 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?
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

Page| 96
www.ProductGuy.in
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 requirements etc. There will always be conflicting priorities
such as early TTM of product packed with tons of functionalities. 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 requirements that constitute
minimum valuable product. Minimum viable product constitutes a minimal set of
requirements 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,
Product Managers should outline if there is a need for any synergies between existing
products and new product within the same product line. Undeniably, a 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

Page| 97
www.ProductGuy.in
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
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

Page| 98
www.ProductGuy.in
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 the 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.
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.

Page| 99
www.ProductGuy.in
If the gap between an existing product and the incumbent product is too wide, trying to
ape the incumbent product and following it will deprive the new product an opportunity
to surge ahead. Instead, listen to the market gaining deeper insights about customers’
behaviors and their needs, 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
targeting 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 requirements, 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 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
addressing genuine customer needs because they either did not spot those needs or could
Customers sometimes embrace competitor
products not because they love those products
but because there are no viable alternatives
I strongly believe in the principle – ‘Do not blindly
chase competition’

Page| 100
www.ProductGuy.in
not address those needs. It is essential to identify those reasons to understand the risks
in addressing specific needs. Product Manager looking at the competitive analysis often
get excited that there is a potential gap to address without realizing the inherent risks.
Alongside those analyses, Product Manager should develop deeper customer insights to
understand the needs that customers desire but not addressed by any product.
Understanding and analyzing competitors are not only to identify the gaps in their
products but also to gain an understanding of where they are heading, what needs they
might address, and what markets they might chase. Such structured analysis, when
bundled with customer insights, will provide insightful details on which gaps to close,
what new technology to embrace and which opportunities to chase to leap competition.
Doing so, Product Manager can 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.
Every incumbent product is vulnerable – Defy conventional wisdom
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.
Product Managers should identify why
competitors have not done what they have not
done

Page| 101
www.ProductGuy.in
Figure 14 - 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
(leave alone succeeding) in the luxury car market beating the likes of Audi, BWM,
Mercedes, Lexus, etc? Yet, Tesla zoomed to the top beating the engineering, luxury,
speed, performance, and safety of luxury cars built by Audi, BMW, Mercedes, etc. While
sales of every other luxury carmaker were declining, Tesla managed 50% YoY. The
phenomenal growth of Tesla when the growth of the entire market was actually declining.
Tesla clearly shows that they have defied every conventional wisdom of building
products. Elon Musk has shattered existing benchmarks for building the new product. The
first element that an investor would look for while building a new product is whether the
target market is a growing market. Similar logic applies to Waze as well. Investors would
be interested to know whether the new product is addressing a tangible gap and whether
there is a place for an alternate product. How many of us would have had the brilliance
to spot the white space in navigation products and boldness to overcome Google. Waze
did it, Waze managed to build the amazing navigation product preferred by lots of users
over Google maps. I could not imagine someone building a better navigation product than

Page| 102
www.ProductGuy.in
Google considering navigation product require lots of work and even Apple failed in its
attempt to build an awesome navigation product.
Those examples are testimonials to the fact that it is highly unlikely to build awesome
products adhering to existing benchmarks. Conventional wisdom always believes in
building a new product in growing markets and in markets where there is a palpable gap
of unaddressed needs. The Conventional wisdom of building products is accrued naturally
through precedents set by earlier successful products. Astronomical valuation of
Facebook during its initial days based on its active users instead of its actual revenues has
set a precedent for every other internet company to focus on user acquisition and not on
generating actual revenues. Someone should set the precedent first before it becomes a
conventional wisdom. The Majority of great products have set the precedent and not
followed any existing precedent set by other successful products. Tesla and Waze have
also set a new precedent going against conventional wisdom. They have proven that
every incumbent product is vulnerable and there is always an opportunity. However, it is
not an opportunity that is visible in plain sight. All it requires is a keen eye to identify white
space, bold thinking, appetite for risk, impeccable execution to beat incumbent products.
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| 103
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| 104
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 15 - Product Adoption Life Cycle
Core product which could be termed as the 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| 105
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| 106
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. The 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 the 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 requirement 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| 107
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 an exclusive focus on discovering and
understanding, as many customers’ 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 discovery of all possible needs. The collaborative discovery of needs
will ensure discovering and understanding of exhaustive set of customer needs. It might

Page| 108
www.ProductGuy.in
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 a
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.
A 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,
the 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 a 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 a
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| 109
www.ProductGuy.in
formulating product strategy, while product roadmap plays a crucial role in executing the
strategy.
The 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 the existence of the
product and where the product should be heading. The 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 the product. The
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 the preparation
of Great product roadmap, and it should be the overarching principle that governs the
process of preparing product roadmaps. The process for 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 a 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| 110
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 a sales team with pipeline deals, revenues forecast, targets, estimates etc.,
an account team with customer satisfaction index, an executive team with vision etc.
Product Manager should be proficient in the language of each entity.
Mutual respect, trust and admiration is not
formed by position or authority but by actions,
thoughts and deeds

Page| 111
www.ProductGuy.in
Figure 16 - Product Manager Relation Cycle
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 and disseminate information to every source that requires it.
Product Manager will disseminate information to various sources in a format that each
source understands.
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
Product
Manager
Sales
Engineering
Marketing
Account
Managers
CEO/ CFO/
VP-Product
Analysts

Page| 112
www.ProductGuy.in
real problem. Product Manager should also assess the implications of any decision by
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 requirements 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| 113
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/

Page| 114
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, it lacked basic
elements like a removable battery, MMS support, file transfer, support for
cut/copy/paste etc. 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| 115
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 effortlessly 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 product requirements would facilitate the new product to make $$$
within the framework of product beliefs and purpose.

Page| 116
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 should Organization 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 requirements 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 introduce any new functionality or new technology to align
with customer value proposition and differentiation?

Page| 117
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| 118
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 or
micro 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| 119
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| 120
www.ProductGuy.in
them diligently during product development phase. More details about product planning
phase in the subsequent section.
Product ecosystem – Is it ready?
Product ecosystem is a combination of external factors or drivers whose existence should
be conducive to the success of the product idea. The ‘Timing’ parameter of validating new
product idea can help assess the existence of those drivers or factors. 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)
18
Source: http://www.wired.com/insights/2013/10/why-business-models-fail-pipes-vs-platforms/
Product ecosystem is a combination of external
factors or drivers whose existence should be
conducive for success of the product idea

Page| 121
www.ProductGuy.in
Identify what role the new product plays. If it is a producer, then success is dependent on
vibrancy of the platform and Product Manager can hardly exercise any control over 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
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 do change, there should
be conscious effort to introspect whether the new product will succeed.

Page| 122
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| 123
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 17 - 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
T1T0
Discovering Needs – Drafting PRD
Vendor Finalization
Validating Market Hypotheses Freeze Product Requirements
Business Review
Formulate Hypotheses
(Product/ Solution)
Discovering Needs – Drafting PRD

Page| 124
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 product
requirements might affect customers, add value to customers or how engineering team
should develop those product requirements. It is essential to obtain absolute clarity even
before those requirements 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| 125
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.
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| 126
www.ProductGuy.in
Is MVP a trap?
MVP is a development methodology that I have been advocating until now for building a
lean product that addresses real needs of real customers and as desired by those real
customers. Every methodology has its own fallacies unless we appropriately use them.
With MVP too, we have to be cautious not to fall into a trap of probably relying on it too
much. First, MVP can help validate only needs of today and for reasons stated in ‘Why
look into future’ section under ‘Discovering needs – Drafting PRD’ chapter, MVP might
not be viable for all products. Especially with products that has the necessity to scale at
least 10X from the current needs, MVP is not a viable methodology to comprehend scale
requirements through a cycle of build, measure and learn. Further, we have to ponder
over the following elements of MVP.
i) What hypothesis to validate?
ii) How to validate hypothesis?
iii) How many hypothesis to validate? and
iv) How long to validate?
Figure 18 - MVP Lifecycle

Page| 127
www.ProductGuy.in
Trap 1 (MVP is not one-size-fits-all): The efficacy of any development methodology (Agile
or MVP) lay in realizing the true purpose of those development methodologies. Not
knowing when to use those methodologies and how to use those methodologies will lead
to utter chaos and inefficiency. Eric Reis devised MVP as a methodology because of
uncertainty in markets, customer behaviors and their expectations leading to product
failures. Because of uncertainty, Product Managers fail to build new products for right
needs and for right customers. For eliminating uncertainties through validated learning,
Product Manager could leverage MVP for incrementally building the new product in a
cycle of build, measure and learn with a primary motivation to validate whether the new
product is addressing the right needs, for right customers and as desired by those right
customers. However, not every new product caters to uncertain markets. Certain
products are conceived for predictable markets with predictable needs incorporating
already proven technology.
In a scenario where competitors are crawling everywhere and there are analyst to provide
any information about the need addressed by the new product or about the market
targeted by the new product, Product Manager should leverage those details to build
better insights about customers and market. What makes certain insights more
meaningful is the ability of Product Manager for always reading between the lines to
understand what had worked and what had not worked. Product Manager would later
augment those insights to define the necessity for MVP and identify what unknowns will
be resolved through MVP. MVP cannot be an excuse for lack of insights about customers
and markets, MVP should only complement already existing information to obtain better
insights. Now, this leads to the second trap, how much to validate and learn?
Trap 2 (Validating too much for too long): Validating too many hypothesis will
unnecessarily delay the development cycles risking the possibility of any competitor with
better knowledge of customers and market go past the new product. For every
hypothesis, Product Manager should ponder whether it is essential to validate each
hypothesis directly with customers or is it possible to validate it based on customer
insights. Product Manager by virtue of interfacing with customers, being part of the
industry for a longer period should have developed some insights about customers,
markets and technology. Such insights should be useful for conceiving the product. I am
in favor of lean practices but not in favor validating every element of the new product
with customers. Right balance is required to validate the most critical elements of the

Page| 128
www.ProductGuy.in
new product while maximizing validated learning and minimizing efforts. However,
Product Managers often do the contrary.
Trap 3 (Maximum efforts, minimal learning): After optimizing the number of hypotheses
to validate, Product Manager has to identify the most optimal ways to do validate them.
Building a minimal version of the new product might not always be the best answers for
validating learning. Dropbox founders validated their idea through building a video
because building a minimal product consumes time and any change in expected behavior
of customers requires Dropbox team to refactor the product making it costlier and time
consuming. Ideally Product Manager should follow lean practices even for picking the
number of hypothesis to validate, how to validate those hypothesis and how long to
validate those hypothesis. Time should be a major consideration while adapting MVP
methodology. In the words of Eric Reis
Minimum viable product is that version of a
new product which allows a team to collect
the maximum amount of validated learning about
customers with the least effort.”
True to those words, MVP is about achieving maximum learning with most optimal
efforts.
Trap 4 (Delivering with little value): Another trap is the risk of alienating customers
especially when the new product addresses a need already addressed by competing
products. In such scenarios, minimal version of the product that delivers the same value
as existing products already in the market might not excite customers and Product
Manager risks alienating customers even though there is explicit disclaimers that the
product is a minimal version. MVP sometimes should provide a hint of what is in store for
customers and it should excite customers just as a movie trailer captures the attention of
its audience providing sneak preview of the entire movie.
If the new product is another LinkedIn, Gmail or Salesforce, what could be the MVP
version of the new product that might excite prospective customers? New Product, which
might be a replica of any existing product, should deliver new value or deliver same value
as existing product in a unique way. Otherwise, the commercial success of the new
product is questionable. Therefore, as part of MVP, Product Manager should validate the

Page| 129
www.ProductGuy.in
unique value delivered by the new product to verify whether it is a real differentiator.
Doing so, MVP will provide a preview of the product differentiators that could excite early
adapters. MVP while helping Product Manager validate the efficacy of the product in
addressing a need uniquely should also excite prospective early adapters to buy the
product.
Trap 5 (Not choosing right customers): Another crucial element for MVP is to choose right
set of customers. Always target customers who would be could be potential early
adapters. In addition, the chosen set of customers should share the same passion for the
new product as the Product Manager does. Few section of customers get excited about
break through products embracing new technology, few other customers want to be
delighted with minimal intervention. The later set of customers hate when new the
product uses their business environment as a trial ground.
MVP is a double-edged sword. While customers help Product Manager perform validated
learning to pivot or preserve product development, customers will also throw feedback
for further evolving the product. Product Manager is obliged to honor such requests after
validating the fit with overall strategy of the product. Therefore, it augurs well to focus
on a specific target segment that are potential adapters of the new product ensuring that
their needs are addressed and the product is out on the market as quickly as possible.
Doing so, Product Manager can also avoid the problem of diverse feedback from MVP
customers. In B2B segment, I always prefer picking customers who can generate revenue
in first two quarters of releasing the product. Certain section of customers do not
generate immediate revenue but provides sufficient infrastructure to validate the
product (early innovators).
Not every customer is very vocal about sharing feedback. Right way to perform validating
learning is to observe customers using the new product. Never really rely on what
customers actually say, what they often say is not what they actually intend. For true
validated learning, rely on customer behaviors, body language, and usage patterns. There
is a cultural aspect to feedback sharing, not every culture embrace the quality of calling
spade a spade. Therefore, I loathe feedback forms, user group interviews etc.

Page| 130
www.ProductGuy.in
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
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.
STEP1

Page| 131
www.ProductGuy.in
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
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 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,
STEP2STEP4STEP3

Page| 132
www.ProductGuy.in
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.
Freeze product requirements
The most important task during ‘Product planning’ phase is to freeze the list of
requirements 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 requirements could make it to the final list. Even though
PRD might provide some details on what requirements are not important for version 1.0
by clearly marking the priority of each requirement, 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 requirement1 vs requirement2
but between later TTM (with requirement1 and requirement2) vs early TTM (without
requirement1 and requirement2). 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 requirements 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.
In an earlier section on hypotheses, I had indicated that there are unknowns,
assumptions, and risks associated with the requirements of the new product. Product
Manager can finalize the subset of product requirements that are independent of
hypotheses while pending decision on the remaining set of product requirements until
the validation of dependent hypotheses. Let me illustrate the process with a hypothetical
example of 16 product requirements. We followed a unique development methodology
combining agile and waterfall to introduce agility in refining requirements during the
progression of product development instead of finalizing the entire requirements before
proceeding into product development phase. Later section of this eBook has added more
details on how we introduced such unique development methodology while building the
new product.

Page| 133
www.ProductGuy.in
Product Requirements Status
R1 Closed
R2 Closed
R3 Closed
…
…
R10 Closed
R11 Decision Pending
…
…
Table 3 - List of product requirements and their status
There was absolute clarity on requirements (R1…R10) with regard to what to do, why to
do and for whom it is required. Product Manager can delay the decision on remaining
requirements (R11…R16) until validation of dependent hypotheses. Outcome of
hypotheses validation will allow Product Manager to refine the dependent product
requirements (R11…R16). Product Manager should approve the final list of requirements
determined after validation of all hypotheses and (s)he has to be sure that the frozen list
of requirements 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 requirements 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.

Page| 134
www.ProductGuy.in
Product vs Solution
Is there a difference? There is no definitive yes or no. Customers are interested in
addressing their problems or needs, or accomplishing a specific activity. To do so,
customers use tools. The tools can be either a product or combination of products. When
it is a combination of products, I call it as a solution. Let us pick a classic (or clichéd)
example of a need or an activity – customers want a hole. A single product called a drilling
machine addresses the solution. Let me pick another activity called smart parking. To help
customers park a car effortlessly requires identifying a free space close to customer’s
location, directing the customer to the reserved parking space, allowing him to pay for
parking through easier and flexible options require a plethora of products to integrate for
working together to accomplish an activity. An activity can be termed as one or more
tasks accomplished to achieve the desired purpose e.g. parking a car. While specific tasks
are identifying a free space (Sensors), reserving a free space for a specific driver (Marking
in database), directing the driver to the reserved parking space (Navigation), allowing
driver to pay for parking (Payment solutions) etc.
The earlier two examples had a definitive purpose (1) Customer want a hole (2) Customer
want to park the car. Solution is synonymous to an activity and it helps customer in
accomplishing a specific purpose. So is product not a solution? Not always. As we had
noticed in the example of customer requiring a hole, the drilling machine can achieve the
purpose and hence the drilling machine can be termed as a solution from the context of
an activity called making a hole. Product Manager should consciously identify whether
the new product can accomplish an entire activity or specific tasks of an activity.
The focus on solution is more important only when the new product could accomplish
specific tasks of an activity. In such scenario, Product Manager should explicitly identify
the opportunities for integrating the new product with other products to deliver an entire
solution. Whether to integrate with internal products or external product depends on the
Organization strategy, whether to integrate through proprietary interfaces or define
standards also depend on the Organization strategy. Product decisions should never be
random and independent. There should be rationality, objective and purpose behind
every decision. Further, every product decision has to push Organization closer to its
bigger goals and objectives. The integration of the new product with other products is
more so important when the new product independently could not deliver any concrete
value to customers. Especially when target customers expect all the pieces to a solution

Page| 135
www.ProductGuy.in
on a platter. Hardly few customers prefer to buy individual pieces of a solution and later
do the integration on their own. The fact that most enterprise B2B product vendors have
explicit tab for solutions in their online product page indicate that customers now prefer
buying solutions. Product planning phase is the right phase to identify all missing pieces
of a solution puzzle and identify right products to integrate with the new product. The
other elements to sort out which team will validate the entire solution. While individual
product teams validate their product, someone should own the responsibility to validate
the entire solution i.e. whether all the products integrate well to deliver the right solution.
Go-to market strategy will then shift to marketing the solution instead of just marketing
the new product. If integration with external vendors are required, then Product Manager
should determine the terms for partnership that is mutually agreeable to all the parties.
Did you ever realize how Product Manager could sell, package and deliver the solution?
What is the pricing model? Does Product Manager charge the entire solution or charge
individual pieces of the solution? The answer to how Product Manager will charge the
solution is entirely dependent on how Product Manager will package and deliver the
solution. There are two possibilities.
1. Sell the entire solution with pre-integration of all products like how vendors sell a
completely built personal computer with all pre-installed software. Customers can
unpack it and readily use it.
2. Sell the products of a solution separately. Provide documentation on how to
integrate all the products of a solution allowing customers to integrate them or
provide separate services at an additional cost to perform integration. This model
provides flexibility and it works for customers if they already possess some
products necessary for delivering the solution or if they want to use their own
products. This happens if the integration between various products of a solution
happens through standard APIs.
The right approach is based on multiples factors (1) what customers really prefer (2)
strategy of Organization to upsell or cross-sell their own products. I am an ardent fan of
Product decisions should never be random. There
should be a rationality, objective and purpose
behind every decision. Every product decision is
intertwined to accomplish something bigger.

Page| 136
www.ProductGuy.in
solution selling with emphasis on positioning product ‘exactly at the intersection of
problem and solution space’ rather than marketing product capabilities.
Meticulous planning
If there is one element to which I would attribute the success of our efforts to build the
new product, it is meticulous planning. Planning should be on top of everyone’s mind to
figure out every nuance including those things that you least expect. Often, it is those
things that you least expect hit you the hardest and the entire plan comes crashing down.
Planning, planning, planning and planning is crucial to see through what is coming during
the new product development. Meticulous planning of every element associated with
new product will allow Program Manager and other stakeholders thoroughly think
through every finer elements of building the new product including details as simple as
color of the product. Continuously planning will help us isolate and construct a plan that
ultimately works. Even though Program Manager is synonymous with planning, it does
not negate the responsibility of others to do little bit of planning of their activities.
Give me six hours to chop down a tree and I will
spend the first four hours sharpening the axe
- Abraham Lincoln
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
aspect of the planning phase is to identify all possible risks (budgeting, vendor
management, product performance, compliance etc.) and assumptions. Outline all
possible risks associated with various elements of building the new product. It hardly
matters whether probability of occurrence is high or low. Outline exhaustive list of risks,
probability of occurrence, mitigation plans when occurred. Always be ready for an
occurrence that is least possible. Simultaneously, Program Manager should outline the
deadline to eliminate unknowns 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.

Page| 137
www.ProductGuy.in
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
requirements that constitute the new product.
 Has the engineering team has to ever wait on Product Manager for clarity of
requirements? For how long?
 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?

Page| 138
www.ProductGuy.in
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
measures those metrics and act upon it continuously throughout entire product life cycle
of the new product.

Page| 139
www.ProductGuy.in
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 by product acceptance
criteria can be termed as goals that can facilitate better planning because those are
tangible, measurable and time-bound results to accomplish.
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 instill
confidence to rest of the stakeholders that they can build the new product as envisioned
or conceptualized. However, product development is invariably prone to surprises.
Several 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.

Page| 140
www.ProductGuy.in
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 an airplane 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
airplane can fly non-stop until the completion of building the entire product. The
development team has to build some simulation tools that can help them estimate scale
metrics without building the actual airplane. 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| 141
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 requirements 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| 142
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| 143
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
requirements 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| 144
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 validated 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| 145
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, a 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, it is not possible to streamline the development work. Program
Manager could alert Product Manager on the 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| 146
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 the 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 the product, why the 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

Page| 147
www.ProductGuy.in
Focus on the little things and the big things will take care of
themselves.”
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 from suggesting to take some cues from
Program Manager on how to prepare an effective checklist. Program Managers are
generally more adept at such tasks. Note of caution is to ensure that 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
Product Manager has to focus on the little things
and the big things will automatically take care of
themselves

Page| 148
www.ProductGuy.in
Program Manager would focus on product development, supply chain, documentation,
compliance, vendor finalization etc.
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, determing product cost and turning-on
ordering are mostly interrelated items of ordering tool. It is not possible to record product
cost without the 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

Page| 149
www.ProductGuy.in
on the nature of the product and market conditions, but irrespective of the methodology,
for pricing review it is always best to have some reference point so Product Manager
could justify the price. 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.
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
The most important aspect of pricing is
appropriately monetizing the new product
without leaving any money on the table

Page| 150
www.ProductGuy.in
proportional to its storage capacity and RW speeds etc. Seldom Product Manager does
not get the pricing right on 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.
Pricing by itself is a bigger topic, I just outlined the thoughts based on my experiences and
there is no right or wrong approach to determine the price of the new product. End of the
day what matters is that whether the product is recovering the cost and making sufficient
margins without leaving any money on the table, whether there are right mechanisms to
measure the efficacy of the pricing of the new product. Product Manager evaluates the
pricing of the new product alongside its business model. Business model primarily
outlines how to capture value. Another aspect to consider is the total cost of ownership,
while the product might be affordable the total cost of ownership might be too high for
target customers to afford. For instance, the service cost and spare parts of the cars could
be higher or in a B2B product the support cost, training cost could be higher. I have
summarized some additional aspects to pricing based on my experience
Transition to subscription license (aka SaaS model)
The virtualized product (i.e. a software appliance running within a virtualized
environment) that we built is not a cloud-hosted product. Customers can download the
software upon buying the license, the software can later be installed on top of a
hypervisor on any x86 machine, preferably Cisco UCS19
, as we would like to upsell our
own products. However, customers can use the software only for a stipulated time
because of subscription licensing model moving away from the perpetual model. Unlike
cloud model, the software patches do not happen automatically. The customers are
eligible for all support during the period of the active license. With the virtualized product,
we always want to provide options for customers to reduce CAPEX, increase recurring
revenue for the organization, provide flexibility to use the product as long as customers
require it.
The other choice that subscription pricing will have is tier pricing based on differentiated
value or eat all you want model. The choice purely depends on whether a majority of
customers requires all the functionality or can we substantially segment customers based
19
Reference: http://www.cisco.com/c/en/us/products/servers-unified-computing/index.html

Page| 151
www.ProductGuy.in
on their needs. The former scenario would call for an ‘eat all you want’ model and it is
simple. The later scenario would call for splitting of functionality into tiers like Gold, Silver,
and Bronze. In either case, there is a possibility for further dissecting the pricing model
based on either actual usage or pay for a term irrespective of the usage.
Subscription Model (Annual, Quarterly, Monthly, Custom)
Eat all you want model
Tiered Model
Customers pay for their usage.
Identification of right metric that
has potential to grow
No correlation to actual
usage
Subscription models presented above are not exhaustive. I presented them for reference
to better illustrate the options and challenges in a subscription model. The subscription
model requires an infrastructure to track the licenses and alert customers for recurring
payment after licenses are expired. In addition, the infrastructure should also count the
active usage of the number of instances of software by each customer and validate
whether a customer is holding a sufficient number of licenses. Additionally, there could
be another possible requirement to allow transfer of license from one machine to
another, considering that the software has to be installed on any machine (probably any
server, laptop etc.). In some scenarios, there could be a necessity to allow transfer of
licenses from one user to another depending on the overall business model. The usage
model further adds to the existing complexity by adding the necessity to monitor the
usage of value metric used for billing. If based on actual usage, then identification of right
metric is crucial. I would suggest choosing a metric that has potential to grow. The
internet growth of users is slowing but the usage growth, especially in mobile, is
exploding.
Therefore, any product that delivers internet services should ideally define usage metric
not based on users but on actual usage. Ideally, pick a metric that grows. Otherwise, the
revenues will flatten.

Page| 152
www.ProductGuy.in
Vs
Figure 19 - Internet User Growth vs Usage Growth
Lastly, how shall we derive the pricing for subscription model from a perpetual model? I
can recommend a way to derive the base price. I say base pricing because it should be
x
$
T
0

Page| 153
www.ProductGuy.in
additionally accompanied with a measurable value. A subscription model is a huge
operational overhead to any organization contributing to the additional cost, there is a
risk of not holding customers for the entire lifetime of the product. Most importantly,
subscription pricing offers lots of flexibility to customers. The recovery of additional cost
incurred because of subscription pricing happens through effectively monetizing
additional value delivered to customers. Therefore, it is crucial to tag additional
quantitative value to the base price. To compute the base price, I used a simple principle
of annuities.
Perpetual License - Customer pays x$ initially for using the new product for its entire
lifetime.
Subscription License – Customer pays y$ at regular intervals. Let us assume quarterly
payment and let us assume that the customer will subscribe licenses for an entire lifetime
of the product. Let us chose the lifetime of the product as 3 years. Therefore, the license
amount payout happens 12 times.
It all boils down to basic financial formulae related to annuities. The intention is to
determine the value of $y such that the periodic payments of $y at a future data are same
as the present value $x. Customers do a periodic payment of $y every quarter for next
consecutive 3 years. To compute annuities or periodic payment, it is essential to assume
a rate. I would suggest using the standard lending rates. For illustration purpose, I picked
an annual rate of 12%.

Page| 154
www.ProductGuy.in
𝑦 =
𝑥
(
1 − (1 +
𝑟 ∗ 𝑁
12
)
−𝑛
(𝑟 ∗
𝑁
12
)
)
 r is the interest rate
 N is a duration of the license. As per our example, it is 3 because of quarterly
payment
 n is the total number of payouts, quarterly payout (i.e. 4 times a year) for 3 years
is 4 * 3 = 12
Quantify the additional value that customers obtain because of subscription pricing and
add it to $y to get the actual cost of subscription license. Next logical step after
determining the price of the new product is to measure ROI.
Computing ROI
ROI computation of the new product after determining the pricing and the model (SaaS
or a perpetual model) is simple. Product Manager with a flair for mathematics would get
rid of this phase with utmost ease as long as (s)he is able to forecast units sold for each
quarter for the entire lifetime of the product. For any product, we should determine the
following.
1. Revenue estimation
2. Cost estimation
a. Operating costs – Cost of engineering, Capital expenses for buying
equipment
b. COGs – For HW products
c. Royalty payments for IP (If applicable)
d. License costs – If the new product incorporates SW of other vendors
e. SG & A –SG & A covers sales, marketing and other administrative expenses
associated with the new product. Standard mechanism is to calculate it as
fixed % of overall revenues.
3. Cannibalization impact
4. Operating Margin

Page| 155
www.ProductGuy.in
5. Cash flow
6. Breakeven or Payback period
7. NPV (Net Present Value) of all future cash flows
8. IRR (Internal Rate of Return) of all future cash flows
For better illustration, let us assume the lifetime of the new product as 3 years and it took
1 year to develop the new product. Duration of a year is for conceptualizing the idea,
validating the idea, building the product and finally, launching it. Completion of product
validation through MVP process also happens within the duration of a year. Even though
revenues start flowing from the 1st
quarter of a 2nd
year, the ROI calculations should
happen from the 1st
quarter of a 1st
year, as costs will be incurred for development of the
new product and there will be capital inflow during the period. It is essential to include
1st
year to measure negative cash flows and calculate payback period.
Important milestones for illustration
 The start of product development – Q1 Y1. The 1st
year includes all the activities
related to product development – Idea validation, business review, product
development, product development, MVP validation etc.
 Product Launch – Q1 Y2. The launched product could be termed a minimum
valuable product that customer prefers to buy. The sales of the new product
happens from Q1 Y2
Therefore, all calculations that I will do going forward will be done for 4 x 4 (4 quarters
for 4 consecutive years)
Revenue estimation
Estimate the revenues for the perceived duration of the lifetime of the product. Ideally, I
would suggest Product Manager estimates revenue based on a likely scenario. Later we
can determine the worst scenario and the most optimistic scenario as % of a likely
scenario. Most financials are computed on a quarterly basis, so let us follow the same
standards to estimate the sales on a quarterly basis from the first quarter of enabling sales
for the new products. There is a possibility to turn on pre-orders for few products before
the actual launch. In such case, Product Manager should consider the date of enabling
pre-order for estimating revenues and not use the actual launch date of the new product.

Page| 156
www.ProductGuy.in
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Units
List Price / Unit
Discount %
Product
Revenue
Table 4 - Units forecast of the new product
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 = 𝐿𝑖𝑠𝑡𝑃𝑟𝑖𝑐𝑒 ∗ 𝑈𝑛𝑖𝑡𝑠 ∗ (1 − 𝐷𝑖𝑠𝑐𝑜𝑢𝑛𝑡 %)
Cost estimation
There are two types of costs incurred during the entire lifetime of the product (i) variable
costs and (ii) fixed costs.
 Variable costs vary with a number of products sold to customers. For HW products,
variable costs are incurred as soon as they are manufactured. However, for
calculating ROI, it is ideal to account for variable costs after selling each unit. The
costs of inventory are accounted as sunk costs after killing the product and taking
it away from the market.
 Fixed costs are costs incurred in developing the new products and they are
independent of product sales. The product reaches breakeven when the revenues
compensate the fixed costs.
Variable costs of the new product are
i. The cost of SW license added to the new product – The new product can include
any SW from OEM vendors. The cost paid to vendors is proportional to the
number of products sold
ii. COGs (Cost of Goods Sold) of the product – Applicable for HW products
iii. Royalty payment, cost of an Intellectual Property of an external entity
Each unit of the new product sold incurs the above cost. Always calculate per unit variable
cost as the sum of all applicable costs listed above.
Fixed costs of the new product are
i. Cost of equipment required for the new product development
ii. Engineering cost incurred to build, validate and support the new product.

Page| 157
www.ProductGuy.in
The above costs can incur either once or at regular intervals. The above costs are
independent of the number of products sold and they do not vary with the quantity of
sales.
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Units
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin
Gross Margin %
Table 5 - Product revenue of the new product
𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛 = 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 − (𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒𝐶𝑜𝑠𝑡𝑠 ∗ 𝑈𝑛𝑖𝑡𝑠)
𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛 % =
(𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 − 𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛) ∗ 100
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒
Please be aware that only direct product costs are included in calculating gross margin.
Fixed costs that that includes engineering cost and expenditure of capital assets incurred
due to buying equipment to aid the new product development are not including for
calculating gross margin. In addition to those costs, it is essential to account few other
operating expenses while calculating operating margin
Any cannibalization impact?
Consider the product revenue of any existing products that the new product might
possibly cannibalize as a cost. Forecast how many units of existing product, do the new
product cannibalize each quarter. Estimate the product revenue as outlined in Table-5.
While calculating the net margins of the new product for each quarter, consider the
product revenue of the cannibalized product as cost.

Page| 158
www.ProductGuy.in
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Units
List Price/ Unit
Discount %
Product Revenue
Variable Costs
Gross Margin
Table 6 - Product revenue of the cannibalized product
Total product revenue is the difference between the product revenue of cannibalized
product and product revenue of the new product.
= 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 𝑁𝑒𝑤𝑃𝑟𝑜𝑑𝑢𝑐𝑡
− 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 𝐶𝑎𝑛𝑛𝑒𝑏𝑎𝑙𝑖𝑧𝑒𝑑𝑃𝑟𝑜𝑑𝑢𝑐𝑡
𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒𝐶𝑜𝑠𝑡
= 𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒𝐶𝑜𝑠𝑡𝑠 𝑁𝑒𝑤𝑃𝑟𝑜𝑑𝑢𝑐𝑡 ∗ 𝑁 𝑁𝑒𝑤𝑃𝑟𝑜𝑑𝑢𝑐𝑡
− 𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒𝐶𝑜𝑠𝑡𝑠 𝐶𝑎𝑛𝑛𝑒𝑏𝑎𝑙𝑖𝑧𝑒𝑑𝑃𝑟𝑜𝑑𝑢𝑐𝑡 ∗ 𝑁𝐶𝑎𝑛𝑛𝑒𝑏𝑎𝑙𝑖𝑧𝑒𝑑𝑃𝑟𝑜𝑑𝑢𝑐𝑡
𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛 = 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 − 𝑉𝑎𝑟𝑖𝑎𝑏𝑙𝑒𝐶𝑜𝑠𝑡
𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛 % =
((𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 − 𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛) ∗ 100)
Using the above equations, I further proceed to compute the operating margin after
accommodating the cost of cannibalization.
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Gross Margin %
Table 6 - Net product revenues of the new product

Page| 159
www.ProductGuy.in
Operating margin
SG & A is the other major costs incurred by the new product. All expensed incurred for
sales, marketing and administration of the new product are tagged under SG & A. In
general, fixed % of revenue is allocated to SG & A. Please be aware of all the operation
costs tracked in your organization. The majority of operating costs are calculated as fixed
% of product revenues. For SG & A, let us assume SG & A spend as 10% of overall product
revenues. Account fixed costs due to an expenditure of capital assets and engineering
cost while calculating operating margin.
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Product Revenue
Variable Costs
Gross Margin
Capital Assets
Engineering Cost
SG & A
Operating
Margin
Operating
Margin %
Table 7 - Operating margin of the new product
𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝐶𝑜𝑠𝑡
= 𝐶𝑎𝑝𝑡𝑖𝑎𝑙𝐴𝑠𝑠𝑒𝑡𝑠 + 𝐸𝑛𝑔𝑖𝑛𝑒𝑒𝑟𝑖𝑛𝑔𝐶𝑜𝑠𝑡 + 10% ∗ 𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒
 10% of Product Revenue is SG & A cost
𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝑀𝑎𝑟𝑔𝑖𝑛 = 𝐺𝑟𝑜𝑠𝑠𝑀𝑎𝑟𝑔𝑖𝑛 − 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝐶𝑜𝑠𝑡𝑠
𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝑀𝑎𝑟𝑔𝑖𝑛 %
= (𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑅𝑒𝑣𝑒𝑛𝑢𝑒 − 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝑀𝑎𝑟𝑔𝑖𝑛) ∗
100
Cash flow
Cash flow indicates the amount of cash inflow after deducting all expenses from the
product revenue.

Page| 160
www.ProductGuy.in
Q1 Y1 Q2 Y1 Q3 Y1 Q4 Y1 Q1 Y2 Q2 Y2 … … Q4 Y4
Operating
Margin
Capital
Expenditure
Cash Flow
Cash Flow (after
Tax)
Cumulative Cash
Flow
Table 8 - Cash flow of the new product
Cash flow is mostly same as operating margin unless there is a need to account for any
additional capital expenditure that was not accounted earlier. The early investment on
the new product proposal was not consciously accounted, as it will be later spent on
engineering, buying equipment etc. Those costs are accounted anyways. Otherwise, we
will double account the same money.
However, if there is any capital expenditure that we have not accounted until now should
be accounted in cash flow calculations, the formula is
𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤 = 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔𝑀𝑎𝑟𝑔𝑖𝑛 − 𝐶𝑎𝑝𝑡𝑖𝑎𝑙𝐸𝑥𝑝𝑒𝑛𝑑𝑖𝑡𝑢𝑟𝑒
𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤𝐴𝑓𝑡𝑒𝑟𝑇𝑎𝑥 = 𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤 ∗ (1 − 𝑇𝑎𝑥%)
𝐶𝑢𝑚𝑢𝑙𝑎𝑡𝑖𝑣𝑒𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤 𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝑄𝑢𝑎𝑟𝑡𝑒𝑟
= 𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤𝐴𝑓𝑡𝑒𝑟𝑇𝑎𝑥 𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝑄𝑢𝑎𝑟𝑡𝑒𝑟
+ 𝐶𝑢𝑚𝑢𝑙𝑎𝑡𝑖𝑣𝑒𝐶𝑎𝑠ℎ𝐹𝑙𝑜𝑤 𝑃𝑟𝑒𝑣𝑖𝑜𝑢𝑠𝑄𝑢𝑎𝑟𝑡𝑒𝑟
Breakeven or Payback period
Breakeven or payback period is the quarter during which the cumulative cash flow turn
positive for the first time.

Page| 161
www.ProductGuy.in
NPV (Net Present Value)
The entire lifetime of the new product is 3 years. Therefore, organization earns revenue
on the new product for 12 consecutive quarters. NPV indicates the current value of the
sum of all future cash flows (both positive and negative) after deducting tax.
Use NPV formula in excel to calculate the NPV of both operating margin and capital
expenditure.
 NPV of Operating Margin = NPV (LendingRate/4, Operating Margin of Q1Y1: Q4Y4).
 NPV of Capital Expenditure = NPV (LendingRate/4, Capital Expenditure of Q1Y1:
Q4Y4).
 NPV of Cash Flow = NPV of Operating Margin – NPV of Capital Expenditure
Use the standard applicable lending rate and calculate the rate for a quarter.
IRR (Internal Rate of Return)
IRR is the rate at which the net present value of all future cash flows both negative and
positive is zero. IRR is a measure of attractiveness of investing in the new product. To
calculate IRR, use IRR formula in excel.
 IRR = IRR (Cash Flow of Q1Y1:Q4Y4) * 4
Sometimes, we might have to present 3 scenarios for projecting ROI
i) Less Optimal – This is a worst case scenario for the new product
ii) Optimal – Optimal situation and which is most likely to happen and
iii) Most Optimal – Best scenario for the new product.
Product Manager can draw a scenario analysis to identify what factors would lead to each
of those three scenarios. However, for estimating ROI for three scenarios, I would
probably do it for an optimal scenario. For any scenario, estimating units forecast is the
beginning. For less optimal and most optimal scenario, we can compute units forecast as
% of units forecasted for an optimal scenario. Probably, I can use 80% for less likely and
120% for a highly likely scenario. After estimating units forecast, diligently following the
above steps will help Product Manager compute all the required data for measuring ROI
of a new product and build a financial summary for all the three scenarios

Page| 162
www.ProductGuy.in
Financial Summary
Scenario Less Likely Most Likely Highly Likely
Product Revenue
Variable Costs
Gross Margin
Gross Margin %
Capital Assets
Engineering Cost
SG & A
Operating Margin
Operating Margin
%
NPV
IRR
Payback Period
Table 9 - Financial Summary
The above table summarizes the entire elements related to financials of the new product.
CFO or VP Finance will be interested in checking whether NPV is attractive and IRR is
above the expectations of Organization. During the business review and later for pricing
approval of the new product, Product Manager will use the financial summary to
summarize the overall attractiveness of the new product.
The excel sheet to perform the above ROI calculated could be downloadable from
www.ProductGuy.in/The New Product - ROI.xlsx.
GTM (Go-To-Market) 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.

Page| 163
www.ProductGuy.in
 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
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 how 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 customers are not valuing those attributes and the
success of the new product is at huge stake. The Product Manager should carve the
product story for GTM while conceptualizing the new product and not towards the end
depending on what constitutes the new product.
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
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
The primary intention of communicating product
value is to make customers believe in the new
product, believe in what it delivers

Page| 164
www.ProductGuy.in
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.
The 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
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

Page| 165
www.ProductGuy.in
launch plans etc. Product Manager alone would not be able to drive all of them, but (s)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.
Internal Evangelism
It is as important to evangelize the product internally as it is to do externally. Sometimes
what a product could perform with its underlying technology could be boundless, but
Product Manager fails to recognize those possibilities because her imagination or
knowledge of customer needs always has boundaries. Some classic examples are speech
recognition, text to speech converter, and speech to text converter. Those technologies
are foundation to a wide range of use-cases. The options are truly boundless. Internal
evangelism especially in a bigger organization spreading across multiple geographic
locations can help expand the possibilities of what the new product could actually
accomplish. Spread the word out about the products and its capabilities. Expanding the
opportunities are not immediate priorities of building the new product, it is a thought I
would like Product Manager to have lingering on their minds to expand the scope of the
new product as the adoption goes higher.
The other important and crucial factor for evangelizing the product internally is to create
champions of the products who can spread the word about the product. Through internal
evangelism, we spot and connect with all three archetypes – Mavens, Connectors, and
Salespeople. Malcolm Gladwell explains those archetypes in his book ‘The Tipping Point’.
Mavens have wealth of information deserving the tag - information specialist. Mavens
can help us validate some hypotheses around market, product, and solution. They can
help us identify new methodologies to reach or acquire customers, help us expand the
opportunities for the new product. Connectors can connect the Product Manager to the
right persons who can help us during the new product. During the new product
development, Product Manager will not have all the right connections both internally and
externally as well. Product Manager might need a connection to analysts to mention
about the new product in their report (for e.g. Gartner) or a PR to create a sufficient buzz
around the new product. Even internally, Product Manager will not have connections to
a team that can add the product to the global pricing list, a team that can validate whether
product pages have employed right SEO/SEM techniques, and a team that can help
prominently highlight the new product in an event occurring close to the launch of the
new product. More often, right connections can help us get the job done quickly. Finally,

Page| 166
www.ProductGuy.in
Salespeople are persuaders who can help Product Manager sell the idea of the new
product both internally and externally as well. Internal evangelism should start with the
validation of new product idea because Mavens, Connectors, and Salespeople are
required right from idea validation phase. Mavens did help me a lot especially with the
building of the virtualized product (i.e. a software appliance running entirely within a
virtualized environment). They shared plenty of details around the additional
opportunities and risks associated with building a virtualized product. All those inputs
contributed to successfully building the virtualized product. I in fact succeeded in creating
a multiple variation of the virtualized product by identifying additional opportunities
through connecting with Mavens.
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
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 a B2B segment).
However, all those efforts of the 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 the 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 customers 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

Page| 167
www.ProductGuy.in
new product and should instill empower sales team with necessary knowledge and
acumen to break those defenses. Therefore, sales enablement is not just about training
sales team on 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 the
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 an 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 the sales team is articulating 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 lingers 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 the 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
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
Sales enablement is not just about training sales
team on what the product does and why, but it is
also about communicating what the product
does not do and why

Page| 168
www.ProductGuy.in
new product has to spur an entirely new product ecosystem, then Product Managers has
to sweat a lot to create a proper ecosystem that would fuel the success of the new
product. Another aspect to consider is that the elements of whole product vary as the
product evolves through various stages of technology adoption life cycle (described by
Geoffrey Moore). The decision-making process of early adapters is not same as the 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, the existence
of support etc. in addition to product capabilities as the key deciding factor in the buying
process.
Final Word: Product development is the 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| 169
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 a 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 to him?
 Is product manager periodically reviewing the interim progress of developing the
new product and sharing the feedback without waiting until the completion of
the 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| 170
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 alternative 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
the 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| 171
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| 172
www.ProductGuy.in
databases etc. The conceptual view will let everyone know how various elements
interoperate to deliver the solution.
Figure 20 - 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 21 - Conceptual view of Projector

Page| 173
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 a 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 on 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| 174
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 an 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| 175
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) a 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| 176
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 on
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| 177
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| 178
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 the 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| 179
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| 180
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| 181
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 are 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| 182
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 the 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| 183
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| 184
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 the 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. Assumptions are 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| 185
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.
Assumptions are definitely a sin during new
product development

Page| 186
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| 187
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| 188
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| 189
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 product architecture is dependent on the HW. Both are mutually dependent. There is
a necessity to ensure that HW and architecture can allow the software (i.e. functionality
block) to scale as needs of customers evolve with little or no change to both the elements.
Why are we putting so much emphasis on product architecture? I once came across a
tweet that states every scale has an expiry date. True to those words, software has to
scale in future as customer needs evolve and product architecture should support such
scale requirements in future with little or no changes to product architecture. Certain
elements of product architecture are rigid and it is not possible to modify it as new needs
arise. Therefore, it becomes crucial to building a product architecture with a hindsight of
how customer needs evolve in future. I did vehemently establish the fact several times in
this eBook that the new product should cater to needs of tomorrow and not just for needs
of today. Building MVP is not viable to identify needs of tomorrow while it is a viable
option for identifying needs of today. Developing customer insights along with
identification of factors that can influence the evolution of technology, the evolution of
the market, the evolution of customer needs are crucial for anticipating probable needs
of tomorrow. Clearly, for enterprise products where architecture can play a big role in
determining the success of the new product and where the design and development of
architecture happen upfront, agile is counterproductive. Incrementally building product

Page| 190
www.ProductGuy.in
architecture is a grave mistake. However, Program Manager introduced agility in building
functionality blocks that address actual customer needs.
During requirements phase, we did outline all assumptions, unknowns, and dependencies
across requirements of both product architecture and product functionality. The first
priority was to eliminate all unknowns and validate all assumptions surrounding the
design of product architecture. The design was mere theoretical until we start building it.
Therefore, there will be many assumptions primarily around the ability of product
architecture to meet scale requirements. To validate all those assumptions and eliminate
unknowns, we constructed hypotheses. On those lines, we also constructed hypotheses
surrounding product functional requirements. The product development happens in an
interval of 6-8 weeks called DTHOs. Our 1st
priority was to eliminate unknowns and
validate all assumptions related to product architecture in earlier DTHOs. Dependent
products requirements were refined based on the outcomes of those DTHOs.
Hypotheses of Product Architecture
Hypotheses Associated Requirements Dependent Requirements
H1 R1 R11
H2 R2 R12
H3 R3 R13
H4 R4 NA
H5 R5 NA
Table 10 - 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 11 - Hypotheses of Product Functionality

Page| 191
www.ProductGuy.in
The list of hypotheses surrounding both product architecture and product functionality
has provided an indication to Development Manager and Program Manager on two
aspects. First, the set of functionalities or requirements (R1…R10) that engineering team
should implement during the initial DTHOs for validating hypotheses. Second, the set of
functionalities or requirements (R11…R16) that engineering team should delay until
validation of hypotheses (H1…H10). Delayed functionalities or requirement are later
implemented depending upon pivot or preserve scenario in accordance with the outcome
of validating each hypothesis. PRD has clearly articulated the list of incomplete
requirements. As initial DTHOs validated hypotheses (H1…H10) through implementing
requirements (R1…R10), I refined all dependent requirements (R11…R16) implemented
in subsequent DTHOs. The dependent requirements are mostly functional requirements
that are refined after validation of hypotheses related to both the requirements of
product functionality and product architecture.
One example of a hypothesis is – Ability of the product to meet throughput scale
requirements (Hypotheses – H1). The PRD had a clear requirement for the product to
deliver 60 Gbps at an average packet size of 512 bytes while maintaining low latency. The
conventional wisdom is to measure and report maximum throughput at an average
packet size of 512 bytes. Engineering team did validate the hypothesis by building the
entire product but performing sizing through simulation. We identified during hypothesis
validation that 60 Gbps is achievable albeit with a higher packet size. As I had indicated
earlier, marketing team later did lots of analysis, found out the average packet sizes in
customer networks is much higher, and we could conveniently defy the conventional
wisdom. We never froze entire requirements. Depending on the hypotheses validation,
dependent requirements were refined during the course of the new product
development introducing agility within waterfall model.
The biggest criticism of waterfall model is that it always heads in one direction. However,
we did introduce agility to shift our thinking back and forth between development,
design, and requirements. Requirements (R11…R16) were kept open and refined after
corresponding hypotheses are validated. We clearly introduced a loop containing product
requirements, product design, and product development until we validated all the
hypotheses. However, following a strict waterfall model, we had to build a foundation for
product architecture upfront unlike in agile before going in a loop containing
requirements, design, and development of product functionality. Such model is required
for enterprise software products until we find out a methodology for modularly building

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

Page| 193
www.ProductGuy.in
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 a 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)
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 for 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
Under the concept of ‘Tag On’ marketing, my
new product might not be the protagonist of
marketing campaign nevertheless it gets
required attention

Page| 194
www.ProductGuy.in
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.
The way we did was through hierarchical approach. The biggest benefit of a bigger
organization is the existence of hierarchy in every functional group (i.e engineering, sales,
marketing, finance, operation etc.). We had to identify the right people who can take us
to the doorsteps of our target customer. With the focus being worldwide and the number
of customers being very high, we had to employ a systematic approach. What I did for
EMEAR is to identify a BDM or Sales head in Europe, Middle East, Africa and Russia. I took
their help for reaching out to account team or sales team of each country in their region.
Irrespective of whether their customers could be potential target customers for the
product immediately or not, I did conduct a detailed session on the new product making
them familiar with the new product and its capabilities. When account team or sales team
have all the required details about the new product, they can position it appropriately
when an opportunity arises. However, when we know there is a definitive opportunity
with any of our existing customers to sell the product immediately, I had deeper
engagements with corresponding account team or sales team than just evangelizing the
product. We had to strategize on how to reach those customers and how to position the
new product effectively. Doing so, we are able to reach the doorsteps of all our

Page| 195
www.ProductGuy.in
prospective customers. It was really tiring talking to every sales team across EMEAR.
There were days where my calendar was buzzing with activities of meetings talking to
various sales team continuously for 6-8 hours. With no sufficient budgets to market the
new product, there was no other effective alternative to target existing customers.
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 addressing their problem and they will 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

Page| 196
www.ProductGuy.in
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
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 – Nothing beats impeccable execution of the new product.
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| 197
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| 198
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| 199
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| 200
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| 201
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 do Product Manager 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| 202
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 the 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 is the natural choice to impersonate them during new
product development for providing feedback and review about the new product until the
start of product validation by customers through an MVP.

Page| 203
www.ProductGuy.in
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
have a clear understanding of how to execute the new product vision within the
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| 204
www.ProductGuy.in
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 a 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| 205
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| 206
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| 207
www.ProductGuy.in
References
Table 1 - Whole product matrix................................................................................104
Table 2 - Product comparison chart of Nokia N97 and Apple iPhone ........................113
Table 3 - List of product requirements and their status ............................................133
Table 4 - Units forecast of the new product..............................................................156
Table 5 - Product revenue of the new product .........................................................157
Table 6 - Net product revenues of the new product ..........Error! Bookmark not defined.
Table 7 - Financial Summary ....................................................................................162
Table 8 - Hypotheses of Product Architecture ..........................................................190
Table 9 - Hypotheses of Product Functionality .........................................................190

Page| 208
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’
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.
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

Page| 209
www.ProductGuy.in
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.
Capital Expenditure or Capital Expense (CAPEX) is the money a company spends to buy,
maintain, or improve its fixed assets, such as buildings, vehicles, equipment, or land. It is
considered a capital expenditure when the asset is newly purchased or when money is
used towards extending the useful life of an existing asset, such as repairing the roof.
An Operating Expenditure or Operating Expense (OPEX) is an ongoing cost for running a
product, business, or system.
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

Page| 210
www.ProductGuy.in
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
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.
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

Page| 211
www.ProductGuy.in
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-
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.

Page| 212
www.ProductGuy.in
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
Virtualized Network Function20
- 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)21
- 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.
20
Source: http://www.webopedia.com/TERM/V/virtualized-network-function.html
21
Source: https://www.sdxcentral.com/nfv/definitions/nfv-mano/

Page| 213
www.ProductGuy.in
The definition provided for the above acronyms are directly picked from WIKI.

Building Enterprise Product - For Moving Targets of Customer Needs and Outcomes

More Related Content

Similar to Building Enterprise Product - For Moving Targets of Customer Needs and Outcomes

More from Murali Erraguntala

Recently uploaded

Building Enterprise Product - For Moving Targets of Customer Needs and Outcomes

Editor's Notes