Part III : Learning Steps

While the value proposition focuses on the ―why‖ as discussed previously, the product (or
service) requirements focus on the ―what‖ — what are the customer‘s critical needs? The product
requirements are detailed descriptions of what the product must do or what the service must
provide. Identifying key requirements and managing them until they are integrated into a product
or service is the principal task for any product manager (PM). In at least one startup that we
know, the PM was called the ―Chief Search Officer‖ because he spent a substantial amount of his
team‘s resources working with customers while searching for new and critical product
requirements. In this chapter, we discuss the basic steps of identifying and managing
requirements (listed below) which forms one of the key tasks of Digital Product Management
Thinking.

i. Identify and collect requirements from key internal sources (e.g. marketing team,
customer service team, etc.) and key external sources (e.g., folks who sell and service similar
products, potential users, etc.)

ii. Document and assess requirements with various stakeholders.

iii. Figure out a process to track, prioritize, and manage changing requirements over the
course of the project.

We also recognize that the successful classification and management of requirements is a multi-
disciplinary challenge that requires data analytics, adept social interaction, and critical thinking.
Key concepts are described below.

Key Concepts

1. Collect Requirements: The PM identifies key product requirements based on input from
several sources, which includes potential clients and the offerings of competitor products
in the market to name a few. However, even before thinking about specific requirements,
the PM must build a solid and wide base of ‗ambient‘ information to establish a
benchmark (i.e. key features of previous generations of products that were successful in
the market). This is important for two reasons:

(i) Without benchmarking and other basic data, it is very difficult to prioritize requirements.
Ineffective prioritization can lead a PM to pursue low-value product features at the expense of
key features. Even worse, ―tunnel vision‖ can set in too early in the product development process
and key features may be completely ignored. Effective requirement prioritization allows the PM
to take a ―value-of-information perspective,‖ which helps the PM look at the costs and benefits
of getting additional information. This then allows the PM to make an informed decision about
whether to expend resources to collect more information (Levesque & Maillart, 2008). This is
particularly useful when the team is faced with the selection of novel technologies, which can be
time-intensive and can potentially cause delays, a key concern for a PM (Bhaskaran &
Ramachandran, 2011).

(ii) Without an ambient benchmark for existing features, PMs do not get credit for identifying
requirements, especially if the high-priority requirements turn out to be intuitively appealing to
senior colleagues. This could be classified as the, ―Well, even I COULD tell you that‖ problem!

2. Document & Assess Requirements: PMs and their teams can gather such ambient
information through several channels such as social media, meetings with analysts,
participating in the company‘s ongoing conversations about strategy and business
models, by attending relevant meetings, and contributing to discussions. Customers are
often (but not always) the most obvious source of information, but the PM needs to be
able to critically assess the input by asking the following questions: Is this customer
representative of others I am trying to reach? Is this customer‘s knowledge credible? Is it
insightful? Is this customer trying to sway me for other reasons? Customer voices are
powerful, and therefore the PM must be careful to not to be overly influenced by a single
customer. The PM should have a thoughtful process for engaging with customers (e.g.,
via an advisory group that the PM sets up to talk with salespeople and lead customers)
along with internal sources such as partners. It is also useful to examine past
requirements lists, as a PM may find some high-value product features that were
excluded because the technology to support them was not yet available.

3. Modify Requirements: Product requirements will inevitably change during the course of
product development for several reasons, some good and others bad (Wheatcraft, 2012).
The impact of changes and how the PM responds are dependent upon the type of project
and methodology used to develop the product. For example, a downstream change in
requirements for a complex systems product or a semiconductor chip development
project can be severe. Many systems products are developed using a waterfall
methodology that typically seeks to ―lock‖ specific requirements early. This is because a
large amount of resources (e.g., engineering hours) are needed fairly early in the
development cycle, which makes it hard to change requirements after substantial time
and labor has gone into a design that relies on specific requirements and configurations.
By locking these requirements in, it allows downstream process to develop their portion
of the product but it also makes it very difficult to change course.

This is in contrast to something like software products that use an agile development
methodology. Agile development is punctuated by frequent releases and less ―locked‖
requirements, which allows companies to react more easily to change (Kelly, 2015). The same
techniques introduced in the previous section on prioritizing requirements are applicable when
changing or reprioritizing a product‘s requirements. The change can be examined in terms of the
incremental value it generates. Does it increase the efficiency of the product, lower its cost, or
raise a customer‘s tendency to buy the product? In addition, it‘s important to measure the ―how
much?‖ of the expected benefit as well. An incremental gain that uses a substantial amount of
resources may be a net negative, and the PM must be mindful of this at all times. Examples of
typical forums to discuss and decide on changes to requirements:

o Weekly ―scrum‖ meetings in agile projects

o Cross-functional team reviews and formal phase reviews in waterfall-based

projects

o Periodic ―change control board‖ processes that some companies use to address
requirements changes or other business changes;

o Out-of-cycle meetings that the PM may call at any time to discuss a proposed
change.

4. Prioritizing Requirements: Because resources are finite, not all requirements can be
acted upon. PMs need to prioritize requirements and align them with their organization‘s
development and marketing capabilities. Often, requirements become a long laundry list
of desired features with no obvious logic. Sometimes, the PM includes recommendations
from the last few customer conversations as though they contain pure wisdom. Other
times, a PM reacts to the ―squeaky wheel‖ — the sales person who says,‖ I NEED this
specific feature to close the deal!‖ or the high-level executive who has a conversation
with a key customer or analyst and directs the PM to include a certain feature. Other
times, the PM‘s team may be risk averse and may cut out uncertain tasks that ultimately
under deliver on the requirements associated with novel and thus uncertain technologies.
These approaches are frustrating to the organization and undermine the PM‘s credibility.
Therefore, a PM should collect, analyze, and then categorize requirements in an efficient
and systematic way. The requirement list should cite the importance of each requirement
and its relative priority.

5. Documenting Requirements – the MRD and the PRD: Requirements are detailed
descriptions of the ‗what‘ of the market or product. Requirements are often published in
the form of a Market Requirements Document (MRD) or a Product Requirements
Document (PRD), or both. In some large organizations, the product marketing manager
or marketing professional writes the MRD while the PM writes the PRD. In smaller
organizations, the PM is in charge of the MRD and the PRD. In either scenario, the MRD
is a high-level document that outlines the overall market, customers, competitors, and
channels of distribution; it also describes where the proposed product fits best in terms of
alternative market segments. An MRD provides context to several PRDs that address that
market, but rarely does it provide guidance on feature-level details (e.g., exactly how
many buttons a user interface needs for a given release).
A PRD answers these feature-level questions of specifically what to develop and why at the
feature level. One of the typical mistakes PMs (especially technically proficient PMs) make
when they write a PRD is specifying too many engineering details and venturing too far into the
world of functional specifications (e.g., the best location for buttons in the user interface). Doing
so impedes the team‘s creativity and initiative. Figuring out the ‗how‘ is the role of the architect,
engineers, and other functional specialists on the team. Numerous examples of MRDs and PRDs
are available online (e.g., Actuation Consulting, 2014).

Learning Steps
After composing hypotheses on product requirements based on customer input, the PM works
with stakeholders (e.g., designers and supply chain partners) to implement these requirements by
selecting product features (i.e. product functions, software interfaces, hardware speed, etc). The
response, called product definition, identifies which subset of requirements will be addressed, in
what time-frame, and through which release. The goals of this chapter are to familiarize the PM
with the following concepts — initial product definition and product evolution through market
experimentation:

i. Understand linkages between the minimum viable product (MVP), the technology
adoption lifecycle (TALC), and diffusion of innovation (DOI) models.

ii. CLPC3 Exercise: Design Minimal Viable Product configurations to facilitate

experimentation.

Key Concepts

1. MVP: The concept of an MVP flows from the ―lean startup‖ approach developed by Eric
Ries in 2008 and is based on two principles: maximize chance of success, and ―release
early – release often‖. An MVP is a basic version of your product (the solution) that is
capable of ―doing a job‖ for specific customers. An MVP is targeted to a small set of
early adopters and provides basic functionality, enough so that these customers will buy
it. The MVP demonstrates enough utility and vision for customers to stay interested in
revised and upgraded versions. An MVP should result in detailed feedback from these
early adopters who can establish the viability of the product or solution concept while
providing direction for revision, updates, and newly emerging needs to be added to the
roadmap. Designing the MVP focuses the team on what the early customer really values
and rarely has the ―bells and whistles‖ and robustness associated with ―grown up‖ or
highly evolved products (Blank 2013).
 2. Prototype versus MVP: It is easy to get confused about the difference between a
prototype and a MVP because both describe the product being defined and can be used to
solicit feedback. However, a prototype is developed earlier in the lifecycle than a MVP.
A prototype is often used to establish product viability while a MVP establishes the
viability of the product‘s value proposition. Prototypes are ‗quick and dirty‘ (Hackner
2015). For example, one could deploy a video or a dummy web page as an example for a
prototype to get rapid feedback.

3. Diffusion of Innovation (DOI): In 1972, Everett Rogers proposed that adopters of

technology fall into five customer categories: innovators, early adopters, early majority,
late majority, and laggards. Different user categories rank the various features differently
(Rogers, 2010; also see LaMorte, 2016). Following this line of thinking, a promoter of
an idea (a PM in our case) should be aware of the underlying mechanisms or influences
that determine whether an innovation will reach critical mass or a ―tipping point‖ and be
widely adopted.

4. Crossing the Chasm: Geoffrey Moore built on Everett Roger‘s DOI theory by noting that
the TALC is not a smooth and continuous curve and that PMs should be conscious that
crossing the chasm to mainstream adoption is difficult (Moore, 2009). Relating this
crossing-the-chasm metaphor to the MVP suggests that the MVP is likely to be
developed for the initial adopters since it is based on their feedback. While the early
adopters‘ feedback helps the PM learn and develop the product, the PM should realize
that the next set or category of customers might have different requirements. Thus,
product evolution is not a simple matter of implementing what the early adopters suggest.
In some cases, it might be wise to develop an MVP for each category (e.g., innovators,
early adopters, early majority, late majority adopters, and laggards). Thus, an MVP for
late adopters will probably have many more ―bells and whistles‖ and robustness than the
earlier version steered by what early adopter required (Nielson, 2014).

Lean Experimentation: A Structured Approach

Early design thinking is grounded in observation and empathy, and the statement of requirements
amount to hypotheses about the key customer needs that are likely to be accepted in the targeted
market segments. Lean experimentation calls for minimizing investment in product development
until a scalable product configuration can be established through rapid market feedback. Thus,
the steps of this experimentation process must be established for rapid response by the PM team
to test hypotheses at a low cost. Eisenmann, Ries and Dillard (ERD, 2013) have proposed a
structured workflow to capture the effort associated with hypotheses-driven entrepreneurship.
Many development teams are following the lean approach.

We present a stylized version of ERD‘s workflow in Figure PIII-2, and identify various chapters
from this book that address specific steps in this flow. Step I of the lean experimentation process
requires a visioning exercise, typically using the Business Model Canvass (BMC), in order to
specify the overall strategy. Step II typically involves opportunity identification and customer
development though field observation. This results in hypotheses based on customer
requirements. Step III calls for rapid prototyping and definition of an MVP. This MVP design is
used to set up configurations that lend themselves to experimentation for assessing responses
from a broader range of users. Configuration refers to a combination of features (specified in the
requirement documents drawn up by the PM team based on early filed work and design thinking)
that may be offered to the end customers.

Figure PIII-2: Lean Experimentation Process

Step IV involves measurement of market response for several alternative configurations. Some
of this work may also involve configuration optimization through A/B tests (addressed in future
parts of the course). Step V requires an assessment of profit and loss for each configuration. Such
analyses also allow the PM team to take a systems view of how various choices of features
interact in terms of profitability. PM teams often review the market response (step VI) and revise
their product road map at this stage. The aim is to get validation from the marketplace and scale
up the product‘s production and distribution. This review could also lead to the next revision
(―rev‖) of the product by creating the next MVP, or may require the team to pivot — go back to
step I and revise the strategy. In some instances, the team may have to abandon the project
because the vision simply does not create an economically viable outcome.
Prototype versus a MVP

Please answer the following question, and then provide feedback to at least one of your peers on
their answer. Short (bullet point) answers and feedback are encouraged (also, please scroll down
the peer answers, or use the ―Unanswered posts‖ button in the discussion board and select a peer
answer that is yet to get feedback). Since these discussions are for broadening your exposure,
your responses will not be graded. We encourage you to read feedback that you may receive
before taking the graded test for this part. (For either of the types respond in the discussion box
corresponding to the type name).

A prototype is developed earlier in the lifecycle than a MVP. A prototype is often used to
establish product concept viability while a MVP establishes the viability of the product‘s value
proposition. Please identify your CLPC type (A) an app for Amazon Alexa, (B) A B2B app on
Linkedin or (C) An App on Twitch. Please describe your vision in 1 line and then explain (in 3
lines) the type of prototype – and this does not have to be functional – that you may build to
before setting up your MVP?