Lean Product Management 1.1

Lean

Product

Management

Achieving Optimal Product‐Market Fit
in Record Time with Fewer Resources
By Greg Cohen
Foreword by Brian Lawley
280 Group Press
Copyright © 2011 by Greg Cohen
All rights reserved. No patent liability is assumed with respect to the use of the information contained herein.
Although every precaution has been taken in the preparation of this book, the publisher and author assume no
responsibility for errors or omissions. Neither is any liability assumed for damage resulting from the use of the
information contained herein.
First Edition: September 2011 (v201205015‐AR)
eBook ISBN: 978‐1‐60005‐216‐3
Place of Publication: Silicon Valley, California, USA
Trademarks
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately
capitalized. 280 Group Press™ cannot attest to the accuracy of this information. Use of a term in this book should
not be regarded as affecting the validity of any trademark or service marks.
Warning and Disclaimer
Every effort has been made to make this book as complete and as accurate as possible, but no warranty of fitness
is implied. The information provided is on an “as is” basis. The authors and the publisher shall neither liability nor
responsibility to any person or entity with respect to any loss or damages arising from the information contained in
this book.

i
Contents
Foreword ............................................................................................................................................. 1
Preface ................................................................................................................................................ 2
The Need for an Alternative Product Management Framework............................................................ 4
Intended Audience ......................................................................................................................................... 4
SECTION 1
INTRODUCTION TO LEAN PRODUCT MANAGEMENT ............................................................................ 6
Lean Product Management Defined ..................................................................................................... 6
The Role of the Lean Product Manager ......................................................................................................... 6
Mathematical Definition ................................................................................................................................ 7
Fit ................................................................................................................................................................ 8
The Foundation of Lean Product Management ................................................................................... 11
The Theory behind Lean Product Management .......................................................................................... 11
Principles of Lean Product Management ............................................................................................ 16
SECTION 2
THE PRODUCT‐MARKET FIT CHALLENGE ............................................................................................. 19
Models .............................................................................................................................................. 19
Understanding the Product–Market Fit Challenge ...................................................................................... 19
Case Studies ................................................................................................................................................. 22
Optimizing (Type I) ....................................................................................................................................... 23
Market Driven (Type II) ................................................................................................................................ 24
Tech Driven (Type III) ................................................................................................................................... 26
Visionary (Type IV) ....................................................................................................................................... 28
Matching the Discovery and Development Processes to the Product‐Market Fit Challenge ................ 31
Problem, Product, and Business Model Defined ......................................................................................... 31
ii
Problem Undefined ...................................................................................................................................... 31
Product Solution Undefined ........................................................................................................................ 32
Business Model Undefined .......................................................................................................................... 34
Two or More Vertices Undefined ................................................................................................................ 36
Validated Learning ....................................................................................................................................... 36
Key Product Discovery and Business Model Questions ............................................................................... 39
Project ...................................................................................................................................................... 39
Problem .................................................................................................................................................... 39
Product ..................................................................................................................................................... 40
Business Model ........................................................................................................................................ 42
Piecing It All Together .................................................................................................................................. 43
SECTION 3
BECOMING LEAN ............................................................................................................................... 44
Practices ............................................................................................................................................ 44
Skills and Knowledge Areas ................................................................................................................ 48
Measures ........................................................................................................................................... 49
Pay‐Off and Risk................................................................................................................................. 51
Portfolio Planning and the Ideation Funnel ................................................................................................. 52
Implications to phase gate ........................................................................................................................... 53
Implications for project funding .................................................................................................................. 54
Leaks versus Launches ....................................................................................................................... 55
Process Improvement ........................................................................................................................ 56
Where Do Services Fit? ...................................................................................................................... 56
Conclusion ......................................................................................................................................... 57
Advancing the Discussion ................................................................................................................... 57
iii
Acknowledgements ........................................................................................................................... 58
About the Author ............................................................................................................................... 59
About 280 Group ............................................................................................................................... 59
Other Books by the 280 Group ........................................................................................................... 60
iv
Figures
Figure 1: Mathematical expression of Lean Product Management ............................................................. 7
Figure 2: The five‐step Lean Thought Process ............................................................................................ 12
Figure 3: Working in smaller batches significantly reduces delivery time ................................................. 13
Figure 4: By sequencing projects, we can deliver value sooner and commit later .................................... 14
Figure 5: Total differentiation is a function of time ................................................................................... 16
Figure 6: The goal is to maximize the area under the curve, which represents the differentiation of our
product over time ....................................................................................................................................... 17
Figure 7: Product‐market fit triad ............................................................................................................... 20
Figure 8: Problem‐Product Solution Matrix illustrating the four product solution types .......................... 21
Figure 9: Problem, product, and business model combine to yield eight different product‐market fit
challenges ................................................................................................................................................... 22
Figure 10: Flip created a new camcorder segment by focusing on under‐served needs and cutting back
on over served needs .................................................................................................................................. 25
Figure 11: Google Adwords report for “video watch” shows an astounding one million monthly searches
as well as hints at some of the intended uses. For reference, Rolex receives just over four million ......... 33
Figure 12: Business Model Canvas .............................................................................................................. 34
Figure 13: Producing validated learning requires many cycles to converge on a viable product‐market fit.
It also requires some resets when a hypothesis turns out to be false. During those times, we cycle
counterclockwise. ....................................................................................................................................... 37
Figure 14: Ansoff’s Product Growth Matrix. The matrix is in terms of your company. Thus, entering a
new market means entering a new market for the company. The market may be established with other
companies serving its needs. ...................................................................................................................... 41
Figure 15: Olsen Design Maturity model defines four levels organizational capability ............................. 44
Figure 16: Example portfolio view of current projects based on differentiation, level of uncertainty, and
time horizon ................................................................................................................................................ 52
Figure 17: Start‐ups that made a significant change to their original business plan succeeded more often
than companies that stuck to their original business plan ......................................................................... 53
v
Figure 18: Traditional serial product lifecycle is ordered by activity. In contrast the concurrent product
lifecycle needed for the many product‐market fit challenges in which the problem, solution or business
model are not fully defined is phased by learning objectives. ................................................................... 55
vi
Foreword
Over the past twenty years Product Management has matured and become recognized as a profession.
The need for a strong product management function, process and staff as a critical component for
delivering excellent products with high profitability has never been more fully recognized or
acknowledged than it is now. Great companies invest in building great product management, and the
result is that they reap the rewards of customer loyalty and profitability.
Along with the changes in terms of visibility and recognition there have also been many advances in
Product Management methodology and resources. Product Management Associations, ProductCamp
(Pcamp) conferences, books, best‐practices templates, frameworks, white papers and many other
resources have been brought to life.
The 280 Group itself has contributed a large amount to the efforts of moving Product Management
forward. Our 280 Group Press series of books, Optimal Product Process™ consulting and training
offerings, newsletter and blog, Product Management LifeCycle Toolkit™ and Product Management
Office™ and our vast array of free resources and white papers have helped tens of thousands of
companies to implement better product management.
Twenty‐five years ago when I began my product management career none of these resources existed.
Indeed, things have come a long way. But as with anything, there is always a need to push the envelope
and see what can be done to break free from the past and move forward into an exciting and more
fruitful future.
Thus we present to you this book. It is designed to challenge your thinking about how Product
Management has “always been done.” In fact, it is designed to challenge the 280 Group’s own thinking
about best practices and the methodology that we train and help companies to implement.
It is possible that the theories put forth in this book will have limited applicability. It is also quite possible
(and in my mind highly likely) that for many companies and teams there is a need to do things very
differently than the Product Management history and tradition would allow for.
So please enjoy this book. Be highly critical. Challenge our assumptions. Be vocal. Participate. Work with
us to discover new and better ways to great Product Management.
We welcome your feedback and opinions!
Brian Lawley
CEO and Founder, 280 Group
1
Preface
The dot com era was an exciting time for me. I had left the relatively stable word of medical devices and
diagnostics on the East Coast, and headed to Silicon Valley to join the Internet boom as a software
product manager for the e‐commerce platform provider Pandesic. Intel and SAP had provided generous
funding for the company and the organization had grown to over 400 people. The company had plenty
of cash and lots of brains, with many employees coming out of Intel, Visa, and SAP. My Pandesic
colleagues might very well have been the most talented group of individuals with whom I have ever
worked. But we had a problem: our customers were learning how to sell products through the internet
and our traditional product development techniques couldn’t keep pace with the needs of a rapidly
changing market.
In one year, I was recruited out of Pandesic to join an idealab! Incubator company. Although I didn’t
realize it at the time, this was to be my most profound experience in product management. We had a
tiny team with no formal business plan ‐ just a charter to see how far we could take an idea that
ideaLab! had dreamed‐up and short term milestones to ensure we were making progress. We used the
LAMP open source stack (Linux, Apache, MySQL, and PHP). Our development team never exceeded
seven members. We launched the product within two months, which was unheard of in those days. At
first we worked on five‐week release cycles, which we soon compressed to three weeks when we
adopted XP (Extreme Programming.)
We studied how users behaved on our system (you need to realize this was 2001, and we had very crude
metrics at best). We zigged and zagged with each new piece of information. We were nimble, and it
was an amazing rush to work in this type of environment. Unfortunately for us, the dot com bubble
imploded and capital dried up. Although we had exceeded all our commitments to the board, we were
still far from profitability. Most of our customers were dot com businesses who were also struggling for
survival, which meant our timeline to breakeven was rapidly growing longer. Before long, ideaLab! made
the only reasonable choice, which was to shut us down and focus their shrinking resources on a smaller
set of projects that were likely to yield quick results.
After my time at ideaLab! I never looked at the world the same way again. It wasn’t until years later,
after further study of Agile development, Lean concepts, and Steve Blank’s “Four Steps to Epiphany”,
that I fully grasped why our small team at ideaLab! accomplished so much in such a short time with so
few resources. In this guide, I’ll refer to concepts like validated learning. At ideaLab! we called that
“throw it against the wall to see if it sticks.”1 Further, when we changed our business plan as a logical
outcome of what we learned that day, we didn’t call it a “pivot.” It’s just what we did – it didn’t have a

1
One way to tell if spaghetti is properly cooked is to throw it against the wall. If it sticks, it is ready to eat. If it falls
off, it needs to cook longer.
2
specific name. Fortunately, there is now a language to describe these techniques that ideaLab!
experimented with in the days of Web 1.0. They became more widely adopted during the Web 2.0
boom, and are now being popularized and further developed through the Lean Start‐up movement. The
codification and evolution of these practices is a major step forward.
The implications of this little slice of history are now clear. The choices we have when we build product
have changed, and product managers need to understand the new rules to know when it is beneficial ‐
and even necessary ‐ to apply new methods. Further, best practices only exist at a point in time.
Product teams have and will continue to identify better practices, and product management as a
discipline will continue to evolve.
In this guide, I intend to lay out an alternate framework for product management. The framework
accommodates the uncertain nature of new product development, the different contexts in new
product development, and continually improving the practice of product management.
I hope you enjoy reading this guide as much I enjoyed writing it.

3
The Need for an Alternative Product Management Framework
The product manager’s role is now recognized as critical within technology companies. Yet we still
practice our trade as a craft rather than as a management science. Further, the profession has been
slow to leverage and understand the full impact of changes in process and technologies that can
radically improve the speed and effectiveness with which we can
create products that customers love, and which are differentiated
from the competitive alternatives. As competitive pressures and
the rate of technological increase, effective product management “We get brilliant results from
becomes a necessity. The margins between product success and average people managing
failure continue to narrow. brilliant systems. Our competitors
get average results from brilliant
This guide seeks to examine Lean principles and how they apply people working around broken
to the field of product management. Furthermore, it seeks to systems.”
provide a framework for continuous improvement and self‐
reflection, so that product management as a discipline can move ‐ Fujio Cho, Toyota chairman
from craftsmanship to management science – a process that can
provide companies with sustained competitive advantage.
Intended Audience
Although the principles in this guide are universal, it is written for technology companies and individuals
leading product management teams and organizations. Much of the discussion centers on software
development, with a further focus on hosted products that have user interfaces. Software ‐ especially
hosted web services ‐ offers a flexible medium in which to work. There are three characteristics of
hosted software that are particularly attractive to product managers:
 Updates require minimal cost and time to deploy into the marketplace. Because the transaction
cost for the updating is so low, it is feasible to make frequent improvements to the product.
 The product can be instrumented to provide a rich set of analytic data, which gives the product
manager great insight into how the product is being used, what features are being used, and the
frequency of use. This usage data can be captured quickly, continually, and at low cost.

4
 Design and development (i.e. manufacturing) largely happen in tandem, which allows design
decisions to be locked down late in the development cycle. Many design decisions can be changed
with minimal cost. This is different from a manufactured good where the design must be finalized
to create the tooling,2 and changes can be expensive. Of course, 3‐D printing may lessen this
constraint.
So the application of the methods discussed will need to be adjusted to address the individual
constraints of the company culture (which may itself need to change), the product medium and the
market environment. Specifically, some adjustment is recommended for physical goods, client installed
software, mission critical products, or regulated products to accommodate the increased time and cost
of each iteration in the learning cycle.
Lastly, this guide is intended to challenge conventional thinking: as always, apply common sense.

2
Japanese automakers have developed some work‐arounds for this constraint. They rough‐cut dies for stamping
body parts early in the process, as the design is evolving and leave excess material where they believe changes
might still occur. The final design is not locked down until late in the process, leading to better die designs, and
faster time to market. (source: Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Boston:
Addison Wesley, 2003) p. 48.
5
1
Introduction to Lean Product
Management
Lean Product Management Defined
The subtitle of this guide is:
Achieving optimal product‐market fit in record time with fewer resources
Although that captures the essence of Lean Product Management ‐ it's better, faster, and cheaper. If we
wanted to be even more precise, we could expand it a little:
Achieving ever better product‐market fit in ever less time with ever fewer resources3
Although this second definition is less snappy, it makes the point that Lean Product Management is a
journey. It is a process of continuous learning and improvement. There is no point at which we can say,
“We have arrived.” We can only say, “We did better today than yesterday, and I believe with the
following changes we can do even better tomorrow.”
The Role of the Lean Product Manager
Product Managers bridge the problem and solution spaces. In the problem space, the product manager
works to uncover customer problems, identify those that the customer is willing to pay to solve, and
then confirms that there are enough customers who share the problem to constitute a market.
In the solution space, the product manager works with designers, user experience experts, and
engineers to explore possible solutions to the problem. The goal is to find a solution that is technically
feasible and can be:
 Produced at a cost well below the price the customer is willing to pay
 Delivered and serviced through a distribution channel that can reach the target market cost
effectively
 Differentiated from the competitive alternatives

3
James P. Womack, author of Lean Thinking defines Lean as “Creating ever more value for customers with ever
fewer resources.” Dan Olsen adapted the definition to product management in his Silicon Valley P‐camp 2011 talk
“Lean Product Management” (http://www.slideshare.net/dan_o) as “Achieving Product‐Market Fit quickly in a
resource efficient manner” which better captures Lean from the product management perspective.
6
Thus, the faster and more cost‐effectively the product manager, working with the product team, can
achieve product‐market fit, the better the absolute and risk‐adjusted return on the product – for two
reasons:
1. A better fit leads to a more appealing product for the target market
2. A faster fit means the product will enjoy maximum differentiation for a longer period of time.
As product managers learn new ways to achieve product‐market fit faster and with fewer resources,
they become more effective, their products more successful, and their companies more profitable. A
great product manager can create a successful product, and a great product management process can
lead to sustainable, long‐term competitive advantage for the company.
Mathematical Definition
Lean Product Management can be expressed in a simple yet powerful formula (Figure 17):
Figure 1: Mathematical expression of Lean Product Management
The goal is to perform activities that will increase product‐market fit, decrease our time to market, and
decrease our costs. The first half of the equation deals with revenue and the second half with cost. The
expression is a proxy for Profit = Revenue – Cost. A team starts with a given structure, process and
capability, so the formula focuses on changes (or deltas) that might be implemented. Although it would
be impossible to accurately quantify every decision, the formula can be used to guide decisions. For
example:
1. By answering a research question, the product will have greater differentiation in the market,
leading to a higher price point and increased sales. If the incremental profit from the better fit is
greater than the cost of the research, then the activity should be performed.
2. If time to market can be decreased by 30 days with the help of an outside vendor, and the profit
during those 30 days is greater than the costs to accelerate the project, it is worthwhile.
3. However, if time to market is reduced by skipping important concept testing that will ultimately
decrease fit, then this is a bad trade‐off and will make the product less profitable. This is known
as the rush to failure.4

4
Jim Reekes, Senior Consultant and Trainer at the 280 Group, introduced me to this term which perfectly captures

7
Ideally, the improvement cycle is reinforcing, improving two ‐ or all three ‐ variables together. For
example, decreasing time to market by increasing collaboration between groups produces revenue
sooner and reduces costs, because the product team‘s salaries are now going towards the next project
of value.
Lastly, it is important to optimize the whole system and not just a local function. For this reason, the
formula looks at time to market and not the time taken for individual steps. For example, if the product
manager pushes user stories to development without good satisfaction criteria, he may have saved
himself time, but the stories will require additional iterations to achieve acceptable fit, lengthening the
overall time to market and to market fit.
Interestingly, after version one is released, a company may deliberately want to pace the introduction of
the next version ‐ either to maximize profits on the product or because the market cannot absorb
releases at a faster pace. In this situation, you should fix “time to market” based on the ideal release
cycle and focus the product team’s efforts on improving fit and decreasing cost during the allocated
time.
Fit
Achieving and maintaining fit is an incremental process, and therefore needs to be tested repeatedly
from concept development through limited availability and post‐launch stages. This testing occurs
through a mix of qualitative and quantitative methods.
CONCEPT DEVELOPMENT FIT
During concept development, fit is usually measured qualitatively though interviews and focus groups.
If the person being interviewed or shown the concept goes out of their way to ask to be notified when
the product becomes available, that’s a good sign. If you ask them if they’d like to know when the
product becomes available, assume they are just being polite when if they answer “yes.” If they indicate
they like the idea, it is fair. If they indicate they love it, they probably only like it. 5 What does come out
of these concept test interviews are the benefit and feature areas that customers like, are indifferent to,
dislike, or have concerns about. This research not only helps guide the product priorities but also the
messaging.

how product teams can run off at full speed to create a solution before they even truly understand the problem
that needs solving.
5
Remember to also make allowance for cultural differences. Very broadly, individuals from cultures that deprecate
personal demonstrativeness (e.g., the UK, Germany) might be more muted in their response than individuals from
those that place a higher value on positive attitudes (e.g., the US).
8
There are advanced methods, such as problem detection studies, that can help rank problems to be
solved. Kano surveys can provide insight into which product problems would ‐ if solved ‐ create
excitement from users and, conversely, would create dissatisfaction if not solved. Adaptive conjoint
analysis allows companies to test different configurations and prices to understand relative tradeoffs
users will make. These advanced methods:
 Are expensive.
 Assume the user is familiar with the product category (not good for visionary products).
 Assume your implementation of the solution will meet the user’s expectation.
In the concept stage, measurement is often based around trying to be directionally correct. Further,
there is increased risk because the measurement assumes the implementation will meet the customers’
expectation of the solution.
LIMITED AVAILABILITY AND POST LAUNCH FIT
Once the product is in the market, there are metrics that can be tracked to further assess fit, and
whether fit is improving or diminishing with time. With online products, you have an advantage: you
can monitor fit or key performance indicators (KPIs) of fit with metrics such as conversation,
engagement and retention rates. If you can’t track these, you need to find a similar proxy that you
believe correlates to customer satisfaction with your product. Two metrics that can assist are Net
™
Promoter Score , which has been around for a number of years, and Survey.io, which is newer and
gaining popularity in the start‐up community.
Net Promoter Score
Net Promoter Score(NPS) uses a single question to divide users into one of three categories. The survey
question asks, on a zero to ten scale, “how likely are you to recommend [company name] to a colleague
or friend?”
 Promoters (9 – 10) – highly satisfied and loyal customers who are most likely to evangelize your
product and continue to purchase products from your company.
 Passives (7‐8) – satisfied but only moderately likely to refer colleagues, and not loyal to your
company or products.
 Detractors (0‐6) – unhappy customers who are least likely to refer colleagues and repurchase
from your company and may actually provide negative references and bad word of mouth.

™
Net Promoter Score and NPS are trademarks of Satmetrix Systems, Inc., Bain & Company, Inc., and Fred
Reichheld.
9
A company’s Net Promoter Score is the percentage of promoters minus the percentage of detractors.6
A positive NPS is considered good and greater than 50% is considered excellent.7 NPS will vary by
category, so it is important to benchmark your company against competitors for a complete picture.
NPS usually addresses company loyalty. If your company sells more than one product you will want to
segment your data by the solution the survey recipients are using ‐ the question can also be phrased to
ask about the specific product rather than the company. You should also consider the significance of
where in the process you are recording the measure (such as after purchase, a technical support call,
etc.)
Survey.io
Sean Ellis of Survey.io developed a simple, product‐focused question to assist start‐ups in measuring fit.
Users are asked:
How would you feel if you could no longer use [product name]?
1. Very disappointed
2. Somewhat disappointed
3. Not disappointed (it isn’t really that useful)
4. N/A – I no longer use [product]
If 40% or more answer “very disappointed” then you have achieved good fit. If less than 40% you need
to enthuse the apathetic users and conduct further research to understand what will be required or
what it is about your product or business model needs to fundamentally be changed.8
Neither NPS, Survey.io nor other KPI scores guarantee that your product will be successful. Many
elements contribute to a product’s success beyond fit. Further, these methods have their limits – and,
usually, their detractors.9 But the benefits are that they are real‐time indicators, can be collected by
asking users a single question or tracking a single number, and do not require a professional research
firm to analyze. Plus, the results are easy to understand and explain.
Beta
It is not always desirable to release the product to the public. In this situation, “invite only” beta tests
allow for real feedback. The feedback will be less varied than a broader release but engagement should
be higher with the beta testers. Discussions, measurements, and surveys can be used to measure fit.

6
“The One Number You Need to Grow”, Harvard Business Review, December 2003.
7
http://en.wikipedia.org/wiki/Net_promoter_score
8
http://startup‐marketing.com/using‐survey‐io/
9
“Life After NPS: Controversy still surrounds the use of Net Promoter Score”, AMA Market Research, Summer 2011
10
Beta testers agreeing to provide references and participate in case studies are an indicator that fit has
been achieved.
The Foundation of Lean Product Management
Lean Product Management is based on ‐ and adapted from ‐ Lean theory and the Theory of Constraints
(TOC) with a good dose of business, product, and market strategy theory mixed in. It comprises a set of
principles to guide action, a process framework that sets context and defines the path to most
effectively achieve product‐market fit, and a set of practices that map to the principles. Lean product
managers also require new skills traditionally not required by product management and, lastly, new
measures to facilitate learning and improvement.
The Theory behind Lean Product Management
Lean theory has evolved over half a century and constitutes a significant body of knowledge. Lean was
first practiced in manufacturing, with Toyota being a thought leader and the Toyota Production System
being a model implementation. The theory, however, has successfully been applied to healthcare,
services, administration, software development and new product development. This section will only
cover a thin slice of Lean theory. It is intended to only provide enough of a foundation to supply the
minimum context for the rest of the discussion. Readers with a strong background in Agile development
will see many similarities in the underlying practices. Agile shares many of Lean’s values, such as
empowered teams, continuous improvement, visual controls and a respect for people. Lean is also
multifaceted. It is a culture, a disciplined approach to problem solving, and a system for doing work.
The cultural aspects are particularly important for a successful implementation. Top management must
embrace the principles, and employees must develop new patterns for working together. Culture,
however, is a topic unto itself and beyond the scope of this guide. The brief discussion in this section
focuses on the systems view.
The Lean Enterprise Institute describes Lean as five‐step thought process.10
1. Identify Customer Value – define value from the perspective of the customer.
2. Map the Value Stream – identify all steps in the value creation process and remove those steps
that do not create value. Value stream analysis focuses on the flow of material and information
through the system with a focus on throughput and wait times. This is different from Michael
Porter’s Value Chain Analysis, which looks at primary activities (such as operations, sales and
marketing, etc.) and asks how much value each activity creates.
3. Create Flow – assemble value‐creating steps in a tight sequence to enable value to flow quickly

10
http://www.lean.org/WhatsLean/Principles.cfm
11
through the system.
4. Establish Pull – As value starts to flow, value is pulled through the system ideally by the
customer and at the rate of customer demand (“build to order” is a pull system). This contrasts
to most systems, which are push. Looking at a software development example, engineering
traditionally begins development when product management pushes a requirements document
to the development team. In a pull system, development signals that capacity has become
available and product management then provides the next most important requirement on
which to work.
5. Seek “Perfection” – we repeat the previous four steps until we have removed all waste in the
system. Perfection is a state we continue to approach but never actually achieve.
Figure 2 illustrates this loop.
Within this larger context of the Lean Thought Process,
there are five complementary practices, which will be
defined in the discussion following, that can help guide
teams in achieving perfection and a state described as fast,
flexible flow:11
1. Minimize Queues by working in
2. Small Batches, managed through
3. Work in Progress (WIP) limits, to
4. Shorten cycle times, and approach
5. Single piece flow
Figure 2: The five‐step Lean Thought ProcessQueues are the enemy of responsive and flexible solution
development. They hurt cycle time, quality, and efficiency.
This exposes us to changes in preference, competitor pre‐emption, unpredictable schedules (i.e. delays),
decreased quality due to long feedback loops, and reduced revenue.12
Queues are made‐up of two elements:
i) The size of the batch being passed to the next phase and the associated time it will take to
process, plus

11
I was introduced to the term “Fast‐Flexible‐Flow” in Alan Shalloway, Guy Beaver, James R. Trott, Lean‐Agile
Software Development (Boston: Addison‐Wesley, 2010) pp. 14 – 15. The discussion of the practices to achieve
fast, flexible flow is heavily influenced by Donald G. Reinertsen’s book The Principles of Product Development Flow:
Second Generation Lean Product Development (Redondo Beach: Celeritas Publishing, 2009).
12
Reinersten, pp. 56 – 58.
12
ii) any wait time before the batch is worked upon. Limiting batch size, therefore, is very
important, because queue size can never be less than batch size. It can be longer if the batch
has to wait for an available resource before work can begin, but never shorter.
If we want to shrink queues, then we need to learn to work in smaller batches. One technique is to
deliver product requirement (i.e. how to functionally solve the market problem) incrementally in the
form of minimum marketable features13 (MMFs), user stories , or other granular artifacts. In some
contexts, the market requirements (i.e. the market problem to solve) may also be able to be delivered
incrementally.
Figure 3: Working in smaller batches significantly reduces delivery time
A further way to manage queues and keep batches small is to enforce WIP limits. Thus, we limit the
work in progress and monitor queues at each step in the process. If a downstream process reaches its
WIP limit, we analyze the situation to see how to fix it rather than continuing to grow the work in queue.
For example, if a back‐up occurs at QA, the team may shift to assist QA until the back‐up is cleared and
flow is restored to the system; if the team does not have the cross‐functional skill to assist another
function, it will pace its work to the throughput of the bottleneck (with some safety buffer). Overtime,
the team will focus on elevating the capability of the bottleneck to increase its overall throughput.

13
Minimum marketable feature (MMF) is described by Mark Denne and Jane Cleland‐Huang in their book Software
by Numbers: Low‐Risk, High‐Return Development (New Jersey: Prentice Hall, 2003). The authors describe an MMF
as a feature that "creates market value in one or more of the following ways: competitive differentiation, revenue
generation, cost saving, brand projection, and enhanced loyalty." The authors further go on to state that "even this
list is by no means exclusive, as true value can only be defined within the context of the proposed project and
measured by the organization developing the software."
13
This contrasts to the traditional approach and thinking that views engineering teams as a precious (i.e.
expensive and scarce) resource that must be kept 100% utilized writing new code. Delaying the release
of the product by creating a large backlog at testing does not create value for our customers or our
companies. Rather it makes our teams inflexible and slow to deliver.
As batch size shrinks and the team focuses on fewer concurrent items, cycle times decrease. If features
and enhancements take less time to get through the system (figure 3 above), for example going from
months to a week, then tracking and status reporting are greatly simplified. Status is simple: either the
feature is in progress or it is in queue. The team can even produce estimates of when an item in the
queue will be worked on, based on their capacity and throughput. Lastly, as features are developed
serially but quickly, product management will have considerably more opportunity to solicit feedback
from customers and stakeholders throughout the development process. As new learning emerges
and/or opportunities emerge, the plan can be adjusted for an optimal outcome. Figure 4 below
illustrates how. In this example, an optimal outcome is achieved by serializing the projects:
1) You can place the most valuable and time‐sensitive project (project A) first and realize revenue
from its completion 4.5 months early
2) Leave your options open about the next most valuable project (Project B). At the 4.5 month
mark, you can now decide if B is still the next most valuable project on which to work.
Figure 4: By sequencing projects, we can deliver value sooner and commit later
The final element of fast, flexible flow is the goal of single piece flow. In product development, a “piece”
could be a market requirement, a feature, a user story, etc. Thus, the team works on one item at a time,
only works on that item when there is proven demand (ideally actual orders), and delivers it quickly. The
shorter the cycle time, the more practical single piece flow becomes. New product development,
however, is not manufacturing. The time between stages naturally varies because the work is different
each time, requires new knowledge creation, and will have unplanned challenges. It thus does not make
sense to limit a team to single piece flow. A buffer should exist. But we can appreciate the idealized
state of single piece flow and search for the right balance of WIP and Cycle Time to optimize the flow of
value and desired flexibility of the system.
14
The Influence of WIP and Cycle time
The relationship between throughput, cycle time, and WIP can be expressed as:
Those activities that decrease cycle time for a given step in the process without increasing cycle time by
a greater amount elsewhere in the system will have the net effect of decreasing time to market for the
project. Substituting “Time to Market” for “Cycle Time” produces the formula:
Rearranging the formula produces:
Taking the original mathematical expression for Lean Product Management (figure 1) and substituting
for “Time to Market” yields an equivalent expression that lets us consider the effects of throughput and
WIP and changes we make to the system more directly:

15
Principles of Lean Product Management
Principles are the fundamental assumptions behind Lean Product Management. If you disagree with the
principles then you are unlikely to agree with this framework. Likewise, if you agree with the principles
but do not practice them, your ability to succeed with the Lean Product Management framework will be
limited. Further, the Lean Product Management framework is a work in progress and, as such, it is
anticipated that principles will be clarified further, new principles will be added, and some existing
principles may be retired.
1. We are in business to satisfy customers. Making a profit is a constraint that must be managed,
because an unprofitable business is not viable and will not be around in the long term to satisfy
customer needs. Enjoying above average margins and increasing shareholder value is an
outcome of doing an exceptional job of satisfying our customers.
2. The customer defines value, and they vote in the marketplace every day, with their wallets, on
which products they believe will satisfy their needs best.
3. Focus on Differentiation14
a. Differentiation is how we separate our products and services from the alternatives.
b. Differentiation must be on an axis of value that matters to the customer.
c. Differentiation is a function of the magnitude of one product’s differences compared to
the alternatives, and the time duration in the marketplace that the differentiation is
maintained (as perceived by customers and users). Thus, total differentiation equals the
integral of the differentiation as maintained over time, where t0 represents general
availability of the product and tx represents the point at which meaningful product
differentiation no longer exists (Figures Figure 5 and Figure 6).
Figure 5: Total differentiation is a function of time

14
Porter describes three major strategies to achieve competitive advantage: Cost Leadership, Differentiation, and
Focus. This guide is for companies that compete on differentiation. Differentiation also applies to focus strategies.
If you are able to achieve sustained cost leadership, you will find it a legitimate and superb strategy, but is beyond
the scope of the discussion in this guide.
16
Figure 6: The goal is to maximize the area under the curve, which represents the
differentiation of our product over time
d. To differentiate, we must be clear on our product’s or company’s value proposition.
e. We can differentiate on functionality, performance, service, and/or business model.
4. ABV (always be validating) – follow a discovery and validation path that forces you, the team,
and the business as a whole to state your hypotheses. Along this path, create ways to test each
hypothesis with the smallest investment possible. This is termed validated learning and allows
us to test our assumptions about product‐market fit. Performing these tests lets us reduce risk
to our projects. This is particularly critical where historic data does not exist for making
informed decisions, but, regardless, is an activity that is performed along the entire product
lifecycle, even after launch. This topic will be expanded later in this guide.
5. Shorten feedback cycles – shorter feedback cycles allow us to identify product‐market fit faster
and for less effort than longer feedback cycles
6. Respect people and the team –problem discovery and product development is a human
endeavor performed by knowledge workers. Respect these workers and assume the person
doing the work knows the most about the work. Errors are the result of poor system design and
not the failures of individuals. In addition to working to improve our products, we must also
always work to improve the system. Teams must be given the time and tools to focus on
improving their work practices.
7. Make the product team’s work visible – when the team and company can see how the project
is progressing without having to ask for status, you spend more time developing new learning
rather than answering questions. Further, socialize your plans and any new knowledge that has
caused you to alter your plans.
8. Match the process to the problem – understand the type of product‐market fit challenge
17
(described in Section 2 of this guide) you are trying to solve so that you can use the most
effective approaches.
9. Balance value with risk and cost as well as short term vs. long term needs – there are natural
tensions that affect our products. We must be aware of them and focus to balance them. This
helps us to optimize the outcome both for our customer and for our business.
10. Reduce work in the system – reduce queues and WIP to deliver the most valuable work first,
retain planning flexibility, and defer commitment as long as responsible. Shift your focus to time
(i.e. how long it takes you to create an increment of value or test a hypothesis) and away from
costs.
18
2
The Product‐Market Fit
Challenge
Models
It is true – to a point ‐ that product management models have mostly been characterized by one‐size‐
fits‐all approaches. The 280 Group Optimal Product Process™ (OPP) represented a major step forward
allowing companies the flexibility to fit their culture, specific team dynamics and the need to document
decisions and product strategy at the appropriate level. This guide does not look to refute the validity of
existing models, but to recognize that they do not always provide adequate guidance on how to create
successful products in a variety of business contexts. Lean Product Management seeks to illuminate the
previously dark area of matching the right process to the product management problem being solved.
By selecting the right process, teams can get to market faster, and with an improved product‐market fit.
Many product management and development processes are adopted at the company level. Lean
Product Management is best applied at the project level, as each project will have different
requirements. Lastly, Lean Product Management asks teams to allocate effort to continuously improving
their processes for delivering products to market.
Understanding the Product–Market Fit Challenge
Building upon the previous discussion on the role of product management, the product manager must
manage three distinct areas to achieve a successful product. The solution must:
1. Address the correct customer problems
2. Solve those problems well
3. Be available through an appropriate channel for the customer to find the product and at an
attractive price for the customer to purchase the product.
Business Model is the label assigned to channel and price (also called distribution and price). Business
model also includes services and design elements that are part of the brand experience. Collectively, the
three areas listed above are called the product‐market fit triad (Figure 7). The solution is thus made up
of the product (the physical product and associated components such as update services, out‐of‐box
experience, warranty, etc.) and the business model (how it is priced, where it can be purchased, how to
get support, the level and type of service customers receive while learning about the product,
purchasing the product, and receiving support and training for the product.)
Each of the vertices of the triangle must be analyzed for uncertainty, and the product manager must
understand if a vertex’s topic is known and well understood, or if significant discovery is needed. The
greater the uncertainty, the more discovery required, and the more hypotheses that will need to be
19
tested. In gauging uncertainly, the product manager asks whether the domain is “defined” (known or
understood) or “undefined” (unknown or not understood).
Figure 7: Product‐market fit triad
Four distinct types of product management challenges (Figure 8) emerge from just focusing on the
problem and product axes:
Optimize (Type I) – when optimizing, we address well‐understood problems in a well‐understood
problem space. Optimizations often come from direct feedback from users of our products,
conversations with our customers and prospects, analysis of competitive offerings, and win/loss
analysis. This product management challenge is common when managing an existing product, or when
entering an existing market with a “like” product. Market needs (i.e. the articulation of the problem) are
stable. Product plans and business plans tend to be stable as well (unless the market or technology is
moving faster than the development cycle.) Optimizing improves the product’s performance ‐ usually
along the dimensions of better, faster and cheaper. The performance improvements tend to be less
than twice the current performance and more typically 5% ‐ 20% along one or more of the product’s
dimensions.
Market Driven (Type II) – this results from market research that produces fresh insights into currently
unmet customer needs. It is appropriate for new products and major enhancements to existing
products. Ethnographic studies and in‐depth customer interviews are popular techniques to provide
initial insights into possible problems a solution might address. These may be followed by surveys to
quantify the opportunities associated with solving each problem. Market needs are stable, but product
plans and business plans can shift during the search for a good solution fit. Performance improvement
over existing products is typically in the range of 2x to 10x ‐ but in highly competitive markets, smaller
performance improvements can often yield a substantial competitive advantage.
20
Tech Driven (Type III) – tech driven is the typical solution looking for a problem. It comes from the
insight that a technological change may provide an order of magnitude improvement in performance for
a product, or enable entirely new capabilities that were previously not possible – or, at least, not
possible at a price the market would support. Product plans will shift until the market needs for a
specific target market are deeply understood. If the product is enabling a new capability, it will share
characteristics of a “visionary” product where the market needs will also shift as users learn how to
apply the product to their context. Business plans, likewise, can also shift significantly. Performance
improvements are typically 2x and greater.
Visionary (Type IV) – Visionary products lie so are far out ahead of current customer expectations that
customers have trouble relating to descriptions of the offering. Often the market for these products
does not yet exist. Developing business cases around visionary products is particularly challenging
because there exists little knowledge on which to base assumptions. Market needs, product plan, and
business plan can all shift significantly. Visionary products typically provide performance improvements
greater than 10x and enable entirely new capabilities that were previously not possible ‐ or, at least, not
possible at a price the market would support.
As markets become more competitive, disruptive innovation has occurred with greater frequency.
Managing Type II, Type III, and Type IV solutions have become a necessary competency for product
managers. And yet, most product managers only manage Type I and to a lesser extent Type II products.
To have the largest strategic impact on our companies, product managers also need to know how to
work with the more challenging Type III and Type IV products. For this, they need an expanded skill set
to be successful.
Figure 8: Problem‐Product Solution Matrix illustrating
the four product solution types
Building upon the Problem‐Product Solution Matrix and the four problem‐product solution types, the
business model will either be defined or undefined. In a defined business model, a channel already
21
exists to reach the target market; the pricing model, which defines both the increment of value being
sold and the expected price for that increment, is established. In total, there are eight ways in which
Problem, Product, and Business Model can combine, based on whether the elements are defined (i.e.
established) or undefined15 (i.e. unproven) (Figure 9).
Optimize Market Driven Tech Driven Visionary

Type
(Type I) (Type ll) (Type lll) (Type lV)
Problem Defined Defined Defined Defined Undefined Undefined Undefined Undefined
Product Defined Defined Undefined Undefined Defined Defined Undefined Undefined

Solution
Business
Defined Undefined Defined Undefined Defined Undefined Defined Undefined
Model
MS Word Gore
Salesforce Xerox
2010 Assoc. Post-it®
Example Dell Flip YouSendlt
Samsung Notes
Vocera Redbox Twitter
Galaxy
Figure 9: Problem, product, and business model combine to yield eight different product‐market fit challenges
As mentioned above, the product management profession has mostly focused its attention on Type I
and Type II challenges, where the business model is defined.
However, when one or more of the product‐market fit triad vertices are undefined, project risk goes up
and the ability to linearly plan and execute decreases. Phase gate development processes become
impractical, as they require near‐perfect gathering and analysis of upfront requirements if they are to be
successful. In an uncertain world where requirements cannot be fully understood upfront, and forecasts
cannot be made with reasonable accuracy, the product manager can only state hypotheses that need to
be tested.
Case Studies
With a variety of product‐market fit challenges, product managers need an equally varied set of
processes and measures to keep projects on‐track and minimize risk. The simplest case is when all
elements (problem, solution, and business model) of the product‐market fit triad are defined. The most
challenging case is when all are undefined. The decision cycle (which governs the ability to follow a
traditional project plan) is entirely different for each of the two extremes. The case studies here are
intended to illustrate companies that have successfully navigated each type of product‐market fit
challenge. Product‐market fit is only one of many factors a company needs to get right in order to

15
Adaptation from D. Silverstein, P. Samuel, and N. DeCarlo, The Innovators Toolkit (New Jersey: John Wiley &
Sons, 2009) p. xxvi and S. G. Blank, Four Steps to the Epiphany, (Cafepress.com, 2006) pp. 12 – 16.
22
succeed. Further, the case studies are provided as illustrations ‐ there is no suggestion that the
companies used the methods described in this guide.
Optimizing (Type I)
Optimizing produces small levels of solution differentiation. Typically, these are
products that are “new and improved” and, when combined with a new business
model, sometimes have no differentiation at all. When a market is no longer
growing, optimizing often is the investment a company needs to make just to
maintain their position in the marketplace.
Business Model Defined (examples: MS Word 2010, Samsung Galaxy)
Because problem, solution, and business model are relatively well understood, it is possible for the
product manager to create a reasonably accurate business case to describe an opportunity and a market
requirements document (MRD) to describe the prioritized needs of the user. The development team
can produce good estimates for the work needed to build the product if they are building upon a
product on which they have already worked. The product marketing team understands how to launch
and promote the product and produce solid estimates of the likely revenue the company could achieve
from it. This is where any company already in business spends most of its time. Short waterfall (i.e.
serial development) methods work well here. However, if the market is very dynamic ‐ requiring extra
flexibility ‐ or time to market has large payoff, Agile development would be preferred. Regardless, at the
project level, the decision making cycle is very linear and maps well to a phase gate process.
MS Word 2010 is an example of an optimized product. It represents the next greatest version of the
ubiquitous office application Word. It addresses bugs and issues uncovered by Word 2007 users and
also includes new features such as a screen shot function and a protected view for documents opened
from potentially unsafe locations (e.g. the Internet or an email attachment.) Microsoft has existing
models to price and distribute the product, and can predict with good accuracy how the product will
sell.
The Samsung Galaxy tablet is a very different example. Samsung is producing an optimized alternative
to the Apple iPad. Its major differentiating factor is that it is not an Apple product. It runs Android, a
more open operating system and application ecosystem, and it costs less than the iPad. Faced with an
ever‐present threat from the iPad (and iPhone), Samsung pursues a fast follower strategy and will need
to compete against other Android products. Time to market is critical to pre‐empt the competition and
try to extend its limited differentiation in the Android tablet marketplace for as long as possible. This
can be a successful product, and Samsung has done well pursuing a fast follower strategy in the past;
but because Samsung needs to master new technologies, there is more development risk. Further, the
Galaxy will need to be one of many products that contribute to Samsung’s bottom line. Although
Android phones and tablets in aggregate are catching‐up – or, in some cases, have caught up ‐ with
23
iPhones and iPads for market share, it is unlikely any individual Android device manufacturer will match
Apple’s volume.
Business Model Undefined (example Dell)
Pursuing a product optimizing strategy where the business model is undefined has the potential to
create not just a successful product, but also a successful company. What is interesting about these
companies is they often do it with products that lack any differentiation whatsoever. Dell originally sold
a product called a “PC Clone”. By its very definition, a clone is undifferentiated. What Dell did do was
sell direct a good‐quality product, with good service, competitive (although not the lowest) prices, and
the ability for their customers to configure their systems exactly as they wanted them. Dell even offered
risk‐free return and next‐day‐at‐home product assistance.16 Dell also achieved competitive advantage
through its superior supply chain management.17
Market Driven (Type II)
Business Model Defined (example: Flip Camera)
Pure Digital Technologies, creators of the Flip Camcorder, identified an under‐
served segment of the camcorder market and created a new category of
camcorder called “shoot and share.” At the time the Flip camera launched in 2007,
camcorder sales were flat. Within a year of its introduction, Flip had 17% market
share on a unit basis, four points behind Sony’s 21% market leadership share.
Flip camcorders were sold through a traditional retail channel, but Pure Digital Technologies redefined
the axes of competition (Figure 10). The traditional camcorder companies continued to improve areas
that had long been satisfied, such as image quality and hours of storage. Flip cut way back on these and
instead focused on three under‐served needs:
1. Ease of sharing video via email and the Internet
2. Ease of shooting ‐ there are only five controls on the camera
3. Small size. Instead of being portable, the Flip camera was pocketable.
FlipShare, the software for quick editing and sharing, was loaded onto the camcorder’s solid state
memory. A USB connector was built in (so there were no cables to carry or lose). When the camcorder

16
http://content.dell.com/us/en/corp/our‐story‐company‐timeline.aspx
17
Internal processes can provide companies with sustained competitive advantage. Some of these processes are
within the influence of product managers, such as market research, others, such as supply chain management, are
not.
24
was plugged into a computer, the editing and sharing software could be quickly installed. Lastly, it was
priced below a traditional camcorder.
Figure 10: Flip created a new camcorder segment by focusing on under‐served needs and
cutting back on over served needs
The fate of the Flip camcorder is worth further examination. Cisco Systems purchased Pure Digital
Technologies in 2009 for $590 million in stock. Although still enjoying strong sales and positive brand
recognition, Cisco Systems announced in 2011 that it was discontinuing the Flip camcorder line as part
of a larger divestment of consumer focused products. One of the stated reasons was the threat from
smartphones, although Flip had a good many years left before smartphones would make it obsolete.18
Had Flip’s management team explored new business models, it might have positioned itself to take
advantage of competitive offerings and next market disrupter. In particular, Flip might have built a
subscription business around FlipShare, offering consumers safe, cloud storage and easy sharing for
their memories. Once Flip users accumulated enough video on FlipShare, even if they change
camcorders or move to a smartphone, they are unlikely to abandon the FlipShare service. Start‐up
KinKast.com might just be the company that reaps the rewards of the video sharing and offsite storage
market.
Business Model Undefined (example YousendIt)
In 2003, Ranjith Kumaran set out to address a market problem: it was difficult for people to send large
files via email and FTP. He founded YouSendIt and developed an elegant solution, whereby a user could
upload a file to YouSendIt via the web and the recipient would receive an email with a link to download

18
http://en.wikipedia.org/wiki/Flip_camera
25
the file. Senders and recipients whose email servers blocked large files found YouSendIt immediately
useful.
The company, however, was unsure how to charge for their service. Had they looked at the traditional
delivery models, they would have charged per file delivered ‐ just as the post office charges per letter or
package. But it must have struck Ranjith that the established package delivery business model would
not translate well to electronic documents. The company experimented with advertising‐based revenue
but this did not generate enough revenue, for two reasons. First, users go to the YouSendIt site to either
send or retrieve a file – they have a task on their mind and they don’t linger on the site, so they are
unlikely to click ads. Second, YouSendIt has no way to work out a user’s interests (the way, say, Google
can by examining a search term, or a content site can match advertisements with an article), so
advertisements can’t be targeted to the audience.
The company then explored a freemium model, in which the base service was free and higher value
services required payment. YouSendIt sliced value along many dimensions, including total downloads
per month and maximum file size (which, although it has been reduced, remains generous for free
users); confirmed delivery; password protection; file expiration date controls; and the ability to send
multiple files together. Users can subscribe to YouSendIt to get the premium features and a few of the
features can be purchased on a per‐transaction basis.
More recently, YouSendIt developed business specific solutions. The core service has largely stayed the
same, but the business‐specific offering is sold on a per‐seat basis, and includes custom branding and
user level reporting. The company even became SAS70 Type II compliant. That isn’t a benefit for
individual users, such as creative professionals, but it’s important to enterprises and law firms using the
YouSendIt solution.
Tech Driven (Type III)
In the tech driven category, companies select the solution, usually driven by a
technological innovation, and then see where and how they can apply it.
Business Model Defined (example: Gore Associates and Vocera)
W. L. Gore & Associates is a tech driven company. The company specializes in
flouropolymers and constantly seeks to identify products that would be
enhanced by their use. Gore is best known for Gore‐Tex®, its semi‐permeable fabric coating that is used
to waterproof outerwear and footwear while remaining breathable and comfortable for the user. But
they also produce products for the electronics, aerospace, automotive and medical industries, among
others. Most companies would not seek to compete in such varied markets, but Gore is a technology‐
driven company. They start with the solution, and identify problems independent of industry, where
they can apply their knowhow ‐ which they have been doing for over 50 years.
26
Vocera is a classic technology driven start‐up. The founders saw how three technologies ‐ wireless LANs
(local area networks), voice recognition, and a hands free communication badge ‐ could combine to re‐
define how mobile workers communicate within a facility, replacing clumsy pagers and noisy overhead
announcement systems. A worker using Vocera’s product can contact any other worker by touching a
single button and stating the name of the person to whom they want to speak. The business model was
based on enterprise sales: they would sell the hardware badges and license the software. The only
problem was that Vocera was not sure who, if anyone, had an acute enough pain to actually buy the
solution. After brainstorming potential verticals and then conducting targeted focus groups, they hit
gold with hospitals and medical facilities.
Business Model Undefined (examples: Salesforce and Redbox)
Salesforce’s founder Mark Benioff had a big vision of software being delivered as a service (SaaS) and
fundamentally changing the way enterprise software was developed and distributed. Salesforce
exploited the Internet to achieve this, and had to develop a multi‐tenant platform to create economies
of scale. 19 The initial solution could have been applied to any enterprise application, but CRM emerged
as the top candidate for SaaS delivery. Salesforce now had to test its hypothesis. Its initial solution
sought to be no better in features and functions than products that already existed in the marketplace.
The entire feature set was already defined by the major players ‐ such as Seibel Systems (later acquired
by Oracle) – already in the CRM space.
Salesforce, however, wasn’t selling licensed software with big upfront fees, yearly maintenance, and the
need for an in‐house IT staff to maintain the solution. Salesforce’s business model was fundamentally
different. It sold an on demand solution, delivered through the Internet. It offered customers three
great benefits: a pay‐as‐you‐go model , a very attractive price point, and freedom from needing a
dedicated IT staff to set‐up and maintain the system. The product itself was actually inferior to many of
the alternatives. The web did not support dynamic content when
Salesforce launched. The user had to manually click a refresh button to
see data update on the screen. Further, the Internet could be slow in
those days and the time to render new screens often seemed
interminably long. But Salesforce wasn’t competing on feature; it was
competing on a new business model and using a new technology to
disrupt the status quo. In doing so, Salesforce brought CRM to a whole
new market of small and medium sized businesses that could not
previously afford an enterprise level CRM solution. Photo: Redbox Rental Kiosk outside
retail store (Source:
http://www.redbox.com/content/mediacenter/w
algreens1.jpg)
19
Before SaaS there were ASPs or Applications Solution Providers. These were single tenant‐hosted solutions
delivered through the Internet. Although an important evolutionary step to SaaS, ASPs did not fare very well as
their cost could not be lowered enough to enable a new segment of the market to participate.
27
The DVD Kiosk rental company Redbox started from the solution, which was vending. Vending provides
an already established business model. Redbox first tested their system by selling groceries, placing four
kiosks in the Washington Metropolitan Area that offered items such as milk, eggs, and sandwiches.
Strategically, Redbox also tested a second concept ‐ a DVD rental kiosk. Within the year Redbox pulled
the grocery kiosks and pivoted to focus the company’s full attention on the DVD rental market. Within
four years Redbox surpassed Blockbuster for number of US locations,20 which now number of 27,000.
They have rented over one billion movies to date.21
Vending is often a premium model centered around convenience. But for the DVD market, Redbox
pursued a combined convenience and discount strategy. Movies rented for $1 per night, much less than
Blockbuster. Further, vending is usually a one‐way transaction: the customer buys the product and
consumes it. Redbox’s kiosks had to accommodate the rental DVD being returned.
Visionary (Type IV)
Business Model Defined (example: Post‐it Notes)
Post‐it® brand notes, made by 3M, started as a type III technology‐driven product.
Dr. Spencer Silver, a 3M chemist, developed the technology, a low tack reusable
pressure sensitive adhesive in 1968. He shopped the idea around 3M for over five
years trying to find a problem that the adhesive could solve. In 1974, his co‐
worker Art Fry saw the potential. Fry sang in his church choir and was frustrated when the bookmarks
he used to mark the different hymns to be sung fell out of the book. Fry believed Spencer’s adhesive
could be used to create a reusable bookmark.22 Employees within the company liked the product, but
didn’t start using them in large volumes. Then one day, Fry cut out part of a sticky bookmark and posted
a note with a question on the front of the report he was writing. This was Fry’s eureka moment – before
long, 3M staffers could not get enough samples of this new version of the product.23
3M launched Post‐it notes in four cities in 1977. Sales were disappointing, and the team realized they
needed to give out samples. Consumers did not directly understand the problem the Post‐it solved and
how useful the product could be. 3M gave out samples in Boise, Idaho and users rated their intent to
repurchase at 95%.24 The team knew they had a success on their hands. The product launched

20
http://en.wikipedia.org/wiki/Redbox
21
http://www.redbox.com/facts
22
“Art Fry and Spencer Silver: Post‐it® notes”, Inventor of the Week, Lemel‐Son MIT,
(http://web.mit.edu/invent/iow/frysilver.html)
23
A. Fry, S. Silver, and S. Duguid, “First Person: We invented the Post‐it Note”, FT.com, December 3, 2010
(http://www.ft.com/cms/s/2/f08e8a9a‐fcd7‐11df‐ae2d‐00144feab49a.html#axzz18hyDnyKX)
24
Ibid.
28
nationally in 1980, and within two years Post‐it notes were considered a necessity in every office,
alongside pens and paperclips.25
The business model for Post‐its was clear. 3M sold many office products such as Scotch® tape and glue
sticks through office supply companies and retail stores. Post‐it Notes used the existing distribution and
sales channels to reach the customer.
Business Model Undefined (examples: Xerox and Twitter)
Xerox, founded in 1906, developed technology that, decades later, made plain paper photocopying
possible with the launch of the Xerox 91426 photocopier in 1959. The equipment was large, weighing
almost 650 pounds, and expensive.27 Before commercializing the technology, Xerox approached IBM
about selling its patents. IBM commissioned Arthur D. Little, Inc. (ADL), a well‐regarded technology and
management consultancy in Cambridge, MA. ADL concluded that if the photocopier displaced 100% of
the carbon paper and dittograph market, it would not justify the expense of commercializing the
product. Further, the copiers would be out of reach of most business budgets, limiting the total market.
Most of us know the end of this story. Xerox launched an entire new industry segment and grew to be
an industry titan: IBM never entered the photocopier market.
How could ADL’s analysis have missed the mark by such a large margin? ADL did not lack intellectual
horsepower, but they were being asked to forecast a market in the visionary quadrant, where user
behavior cannot be easily predicted. In the average office in 1959, secretaries typed documents (there
were no word processors). When more than one document was required they inserted carbon paper
between multiple sheets of paper. When they made a mistake, they had to manually correct the
original and each of the copies one at a time. The terms “cc” and “bcc” (carbon copy and blind carbon
copy), as used in email, are vestiges of this era. Offices had other processes that seem unimaginable
from today’s perspectives. They had central filing systems that secretaries indexed and meticulously
maintained. Because copies were so hard to make, originals were sent around in interoffice envelopes
with distribution lists attached. When the first person on the list read the notice, they crossed their
name off and put the envelope back in interoffice mail or put it on the desk of the next person on the
list. This cycle repeated until everyone on the list had received the notice.
In hindsight we can see that a secretary would love to be able to type once and copy as many times as
they wanted. Further, if they made a mistake, how wonderful to correct only the master and run off a
new set of copies. Likewise, why slowly pass around an original when you can easily make copies? But

25
Ibid. “Art Fry and Spencer Silver: Post‐it® notes”, Inventor of the Week
26
The copier could reproduce a 9”x14”
27
http://en.wikipedia.org/wiki/Xerox_914
29
to see the possible is to see first that the current process could be improved. Photocopies were
expensive, whereas sending an original around on a distribution list was perceived as being free.
Xerox also made a brilliant move in structuring their business model. They adopted a “razor and blade”
strategy. Knowing most companies could not afford or would not budget to purchase an expensive
photocopier, Xerox placed the machines for free and charged for copies. This allowed users to learn all
the interesting uses for a photocopier. Once people got a taste of how powerful the Xerox machine
was, usage grew and grew.
The concept for Twitter emerged from a day‐long brainstorming session at podcasting company Odeo.
The assumption was that a service that allowed an individual to communicate by broadcasting a 140
character SMS messages would be useful.28 The service initially gained little traction when it launched in
2006. Nine months later in 2007, Twitter negotiated to have two large flat panel displays placed in the
hallways of Austin’s South by Southwest (SXSW) music festival to display tweets about the conference
by conference attendees.29 Usage spiked. Twitter reached a critical mass of users. Within a short time
after, tweeting would enter into the cultural lexicon of America and much of the world.
Beyond conferences, Tweeting had a tribal appeal, allowing users to coordinate their social activities on
a Friday night, break and share news stories, get an insight into the lives of public figures and chat about
live TV events. Celebrities discovered it as a way to engage their fan‐base. Twitter has even been used
to mobilize social revolutionaries and force regime change in the Middle East during the Arab Spring.30
As of March 2011, Twitter had over 200 million users31 sending over 140 million tweets per day.32
Although the service has proven its usefulness, it is still searching for a business model. Some revenue
has come from selling the rights to include Twitter posts in search results for Google and Microsoft. It
wasn’t until 2010, four years after launch, that Twitter attempted to seriously monetize its user base
with an advertising model of promoted trends and tweets.33 Investors, however, believe Twitter has
potential. The company has raised over $360 million in capital as of June 2011.34 Could Jack Dorsey and
his co‐founders have created a financial forecast for Twitter in when they founded the company in
March 2006? Could the team even have created an accurate product roadmap? It would have been a
fool’s errand.

28
http://en.wikipedia.org/wiki/Twitter
29
http://www.quora.com/What‐is‐the‐process‐involved‐in‐launching‐a‐start‐up‐at‐SXSW
30
http://en.wikipedia.org/wiki/Twitter_usage
31
M. Shiels, “Twitter co‐founder Jack Dorsey rejoins company”, BBC News, March 28, 2011
(http://www.bbc.co.uk/news/business‐12889048)
32
L. Rao, “New Twitter Stats: 140M Tweets Sent Per Day, 460K Accounts Created Per Day”, TechCrunch.com,
March 14, 2011.
33
J.P. Mangalindan, “”Twitter’s business model: a visionary experiment”, CNNMoney.com, July 9, 2010.
(http://money.cnn.com/2010/07/09/magazines/fortune/Twitter_business_model.fortune/index.htm)
34
http://www.crunchbase.com/company/twitter
30
Matching the Discovery and Development Processes to the
Product‐Market Fit Challenge
In all the case study examples in the previous section, with the exception of Microsoft Word 2010, either
time to market or flexibility (which is the ability the adjust plans quickly to assimilate new information)
were critical to success. The urgency and flexibility needs were driven by:
 Achieving product‐market fit with minimal investment, or
 Maximizing the amount of time the company’s product enjoyed maximum differentiation in the
market.
Lean’s focus on time and limiting work in progress to achieve flexibility can offer product managers a
source of great competitive advantage.
Problem, Product, and Business Model Defined
When the problem, product and business model are all well‐defined or easily definable, traditional Voice
of Customer (VOC) research methods work well. The product manager should meet, talk to and observe
customers using the company’s product and the competitor’s products. Usage data, when available,
should also be analyzed. In addition, input should be gathered from other stakeholders like sales,
customer support, account management, etc.
Customers and stakeholders understand the product and what it does for them. They will have strong
views on what frustrates them and what could be improved. The customer will likely provide feedback
in the solution space about how the product could be changed. The product manager must be skilled
enough to probe to uncover the underlying problem the customer is trying to address with the solution.
Quantitative surveys can follow to understand how pervasive any given problem is and the level of
satisfaction with the current solution. Business cases, forecasts, and plans can be developed. The
project can follow a fairly linear path of: research, prioritize, develop solution concept, validate
proposed solution concept, build, launch, measure against plan and repeat.
Problem Undefined
If the problem is undefined or unknown, the product team needs to conduct research with the intent of
discovery. As research is expensive, the team needs to prioritize which customer segments and
categories of products are of interest. Different techniques can be used, based on the level of
uncertainty about the problem. The techniques generally fall under the heading of Voice of the
Customer (VOC) research, with the goal of producing a list of problems by relative importance and
31
satisfaction with current alternatives.35 Unlike the Optimization challenge (see Understanding the
Product–Market Fit Challenge, page 19), the VOC research must be performed in much greater depth.
Some of the techniques include:
 Ethnography ‐ the observation and sometime interviewing of users to identify problems. This
includes the User Centered Design method of Contextual Inquiry.36
 Individual Interviews
 Focus groups – group discussions
 Apprenticing37 ‐ when you perform the role of the target customer to experience firsthand the
challenges being faced.
Out of this research comes a long list of problem statements. Quantitative analysis and surveys can then
be used to score the problems uncovered in the interview and observation stages. This data is further
sliced to identify segments of users who share similar viewpoints about the importance of the different
problems.
In the case of the Tech Driven (Type III) challenge, the research will first focus on uncovering the general
problems users have; further feedback can then be solicited by discussing the solution. If a working
product exists, it can be given to users to actually use. For the Visionary (Type IV) challenge, the
approach is similar, but we can’t expect users to be able to project their needs, or foresee whether the
solution will solve them. The users have to be allowed to use the product and discover how it can make
their life better.
Product Solution Undefined
If the product solution is undefined, but the problem is well understood, the product team first needs to
brainstorm potential solutions. These can then be vetted through concept testing to provide guidance
about customers’ interest and priorities. Concept testing is the act of soliciting user feedback in the
solution space. The user is introduced to a potential solution and asked to react to it. Each concept
represents a hypothesis to be tested about the priorities and trade‐offs in the solution design. In
general, the richer the concept test, the better the feedback.38 Because the problem is validated, the
primary question is, can an adequate solution be developed to address it? At the early stages, the
product manager wants to be testing multiple concepts and the development team might very well be

35
http://en.wikipedia.org/wiki/Voice_of_the_customer
36
http://incontextdesign.com/contextual‐design/
37
“The Apprentice” is describes in Innovation Games by Luke Hohmann, (Boston, Addison Wesley, 2007), pp. 106 ‐
109.
38
If you are looking for the user to aid you in the design of the concept, however, lower fidelity concepts may work
better because the user will be more comfortable suggesting changes to it.
32
pursuing multiple solutions. The focus interview (conducted in a group or individually) is a traditional
method for gathering concept feedback.
In the Business to Consumer (B2C) or Business to Small Business space, a faster and less expensive
method of testing is to build a small website and run a Google Adwords campaign for the product. By
emphasizing different elements of the solution in the campaign, the product manager can learn about
what customers value most and how the product should be positioned. Further, different campaigns
can take users to different landing pages or sites explaining different concepts. The customer can even
be asked to take action, including committing to purchase. Purchase is the best validation for any
solution. Actions could include users submitting email if they would like to be notified when the product
is available or placing a pre‐order for the product. Another interesting twist on actually advertising the
concept is to use AdWords (Figure 11) to see how many people are already searching for a like‐sounding
solution. These methods do not replace the richness of a one‐on‐one or one‐to‐few discussion, which
can often produce entirely unexpected insights. But these techniques can clarify positioning and
validate that customers will part with their money for the solution.
Figure 11: Google Adwords report for “video watch” shows an astounding one million monthly searches as
well as hints at some of the intended uses. For reference, Rolex receives just over four million
At some point, the company has to build the product and see if it adequately addresses the need. At
this stage the company should only be concerned with building a working prototype and getting it in the
hands of a target user as quickly, and for as little money, as possible. The goal is a validated proof of
concept. Whatever can be left out should be left out, or at least handled manually outside of the system
– this is possible with many features. Early e‐commerce systems, for example, delivered orders via fax to
fulfillment centers because the two systems were not integrated. In this stage, the product team is on
quick product iterations and learning cycles.

33
Since the company intends to sell the product, try to close the sale where possible. This not only
validates that the solution solves the problem, but also that the solution creates enough differentiated
value to support the intended price point. This is particularly important for B2B (business to business)
products that can’t be easily tested online. The product manager needs to know if the customer will
spend their budget to solve the problem. In this case, the product manager is looking for a typical early
adopter, which is someone who knows they have the problem, is willing to cobble together a solution,
may have already tried to do so, and has budget to solve it.39
Business Model Undefined
When the business model is undefined, it must also be tested. First, business models can be
prototyped. A great tool for working through various Business Models is the Business Model Canvas
(figure 12). It can be downloaded for free at: http://www.businessmodelgeneration.com/canvas ‐ a full
explanation can be found in the book Business Model Generation (2010) by Alexander Osterwalder and
Yves Pigneur.
40
Figure 12: Business Model Canvas

39
Geoffrey Moore, Crossing the Chasm (New York: HarperBusiness, 1991) pp. 33‐38.
34
Once a number of qualitative models have been explored, the most promising can be further developed
in Excel to understand the key metrics and performance indicators and the full potential for each model.
Just as a product concept can be demonstrated in varying fidelities, so too can the business model.
Make the solution and business model concepts appear as real as possible and seek feedback from
potential users and partners. You can even produce a video that stages the setting and interaction of
the business. This is particularly useful for testing out retail concepts. If the participants ask when the
solution will be available, that is a good sign.
Web‐based solutions definitely have an advantage when it comes to ease of testing of the business
model. The solution can be built, and the product manager can gather data on unique visitors to the
site, conversion rates and other statistics that might be relevant to a given business ‐ such as retention
rates, activity on the site, number of purchases, average revenue per user, cost to acquire new users,
and more. Hypotheses can be tested, and live experiments can be deployed on site to see if the changes
improve the metrics and key performance indicators.
For B2B companies that sell direct, testing is also easy: new models can be tested with each sales call.
Early on the company may support very different terms in its contracts as it tests the acceptance of a
new model. The challenge then becomes to move the one‐off agreements during the discovery phase
to the standard agreements as they reach their renewal dates.
The hardest business models to test are those involving channel distribution. It takes time to grow
channel relationships, and further time and effort to get those partners active. The product manager is
competing with current revenue generating products. Creating a productive channel takes time and
feedback is delayed. It is recommended you work with partners to close initial sales so you can learn
from each experience until a repeatable sales process has been developed.
It should be emphasized that the sales force or channel should not be scaled until the solution fit,
distribution model, and pricing have been validated. The first job is selling to early customers. The next
job is interviewing them to ensure the product meets their needs and, if so, how they are using the
product. Although we try to influence how customers perceive our products, positioning happens in the
customer’s mind. Therefore, we want to hear directly from the customer about what they find valuable
in the solution; ideally it matches what we think is valuable about our solution, but it doesn’t always
happen that way. Once the positioning and sales process are validated, we can look at scaling the
business.

40
Business Model Canvas usage is governed by Creative Commons Attribution‐ShareAlike 3.0 Unported license.
http://creativecommons.org/licenses/by‐sa/3.0/
35
Two or More Vertices Undefined
As the product‐market fit triad becomes increasingly undefined, the greater the need for quick iteration.
Companies sometimes need to iterate to develop their understanding of the problem, the solution, and
the business model all at the same time. The faster a company can iterate, therefore, the more
hypotheses the company can test; the more hypotheses it can test, the more likely that the path to
success will be identified. Alternatively, if a successful path does not emerge, then the faster the
company can invalidate a project focus area, the faster it can shift those resources to a more promising
idea. Speed and flexibility, once again, are our friends.
Validated Learning
As stated earlier, in many situations, creating a reliable business case, forecast, and design specification
for a product is just not realistic. The sooner companies, product teams, and product managers are
willing to acknowledge that they don’t have all the answers, nor will they have all the answers upfront,
the better they will do at managing the uncertainties and risks of new product development. Thus, the
most we can ask of any team is to deliver validated learning at all stages of the development process.
The steps are as follows:
1. Identify the product‐market fit challenge (Type I, II, III, or IV).
2. Record the knowledge that is known or defined.
3. State assumed product positioning: problem, target customer, type of solution, what it
addresses, and how it differs from the alternatives.
4. Identify the initial discovery steps to ground the product team in the problem, product solution,
and/or business model space.
5. Document the hypotheses that need to be tested for the unknown or undefined areas.
6. Determine the fastest and most resource‐effective way to validate each of the hypotheses, so
the product team will be able to make a decision about whether to move forward ‐ or rethink
the problem and run a new validation test.
7. Return to step 3 and repeat.
36
Figure 13: Producing validated learning requires many cycles to converge on a viable product‐market fit. It also
requires some resets when a hypothesis turns out to be false. During those times, we cycle counterclockwise.
Depending on how much is unknown, different learning cycles can be applied to reach validation:
1. Discovery, Hypothesis, Test, Learn (DHTL) – as portrayed in Figure 13. and discussed above, this
model starts with discovering or researching an area of interest, developing hypotheses, testing
those hypotheses, and learning or drawing conclusions. This sets‐up the next DHTL cycle. This
model supports product management tasks and can be applied to qualitative and quantitative
research including observation, concept testing, surveys, and live product testing.
2. PDCA (PDMA)(PDSA) – Plan, Do, Check, Act (Plan, Do, Measure, Act)(Plan, Do, Study, Act) is also
known as the Deming cycle. This model assumes the scientific method can be applied, and a
statistically significant data set can be acquired. It works very well for web analytics and
quantitative studies.
3. Inspect and Adapt – make frequent inspections to ensure the project is moving in the right
direction and adjusts the plan based on the new information. Inspect and adapt is perfect for
empirical processes usually associated with creative endeavors where new knowledge can only
be learned from experience. The Scrum software development framework is based on this
model.
37
4. Build, Measure, Learn – This model promoted by Lean Start‐up41 seeks to build the simplest
product possible, validate it with customers, and learn ready for the next round. This is the
reverse of the typical phase‐gate process, in which we look to learn everything upfront before
building. The point here is to develop the hypothesis and build something so that feedback can
be collected in the solution space.
The common thread within these processes is developing a hypothesis and testing it. It is important to
do it quickly and as inexpensively as possible.
Sometimes we can test a concept document, sometimes a prototype works well, and other times only
the actual product will do. Often, we need to do more than one. The more visionary the product, the
harder it is to get accurate feedback with just a concept test. Furthermore, how the product is tested is
also important. Web analytics can quantify how much better one design is over another, but little more.
We have to talk to users to understand why one design is preferred over another design.
Luke Hohmann, the creator of Innovation Games research technique, starts all research projects with
two simple questions:42
1) What are your questions?
2) What will you do with the answers?
We can think about the first question as the hypothesis. The second question is much more important:
what decision will you make based on your learning?
Further, at some point in the process, you must try to sell the product, and the sooner the better. If you
can produce a scoped‐down version of the product or produce it in small quantities and sell it, great! If
you can take preorders, great! For enterprise software, even getting a five figure commitment for
concept development is a good test. Testing the customers’ willingness to exchange value is a necessary
validation. Everything else is just talk.
Lastly, for teams to successfully work in tight loops of hypothesis creation and testing, the development
processes has to match. An Agile development process that can elegantly support change is a necessity.
Optimize (Type I) is the only product‐market fit challenge where traditional serial development may still
be considered, and would be preferred for legacy code bases where the cost of change is high because
of code interdependencies and lengthy testing procedures.

41
http://theleanstartup.com/
42
Luke Hohmann, Innovation Games (Boston: Addison‐Wesley, 2007) p. 9.
38
Key Product Discovery and Business Model Questions
Many questions need to be validated. Below is a subset of the most basic ones43. It’s important to
remember that, during any test of a hypothesis, you must remain open to the chance of discovery – the
sudden realization of an unanticipated insight, or the identification of a new path of inquiry.
Project
1. What are the business objectives of this project?
An objective is a measurable outcome at a point in time. For an Optimizing project, an objective
might be to preserve market share, improve retention by 2%, increase usage by 10%, etc. For
Market Driven, the goal might be to create a new line of business for the company to achieve its
growth targets; interim objectives would be developed to ensure the project was moving in the
right direction. For the Tech Driven project, the goal would be to identify a target market whose
members would purchase the product (if available) and work with those members to complete
the requirements and design of the final product. For a Visionary product, the objective might
be build a community of 10,000 users to understand how they will use a new product, such as a
mobile version of the application, as well as baseline metrics for conversion rates and click‐
through rates on premium services and advertising respectively (refer to Understanding the
Product–Market Fit Challenge, page 19).
2. How does the project support the corporate goals?
3. Are we the right company to bring this solution to market and will we be able to compete
effectively?
Problem
1. Who is the customer (be specific)?
a. Who is the user?
b. Who is the buyer? Are they the same person?
c. Who influences the purchase or is impacted by the purchase (answers might be an IT
manager, a spouse, a child, etc.)?
d. Who approves the purchase?
2. What problem does each of the customers want solved?
a. State the problem.
b. Describe the scenario when the problem is encountered.
c. Do different segments exist with different needs (usage or buying)?

43
A more complete list is available in the Master Product Plan.docx in the Product Management Lifecycle Toolkit.
39
d. In considering the early product, which segments and users:
i. Are most valuable?
ii. Will the solution be optimized for?
iii. Will the solution support?
iv. Will the solution exclude?
3. What observational and/or numeric evidence has been collected to support how common and
urgent the problem is?
a. How do customers rank the importance of solving this problem?
b. How do customers rank their current satisfaction with the current alternatives?
c. What evidence exists that customers are willing to pay to solve this problem?
4. Do we believe there are enough customers willing to pay to solve this problem to constitute a
large enough market worth pursuing?
Product
1. What are their current options for solving the problem (remember to include “do nothing”)?
2. What are the strengths and weaknesses of those options? Remember to consider not just the
product but also service, experience, ease of purchase, etc.
3. What is the market entry strategy (Figure 14: Ansoff’s product growth matrix)? 44
a. Are you creating a new market?
b. Are you entering an existing market with an optimized product?
c. Are you creating a new segment with a simpler, less expensive offering that targets
users who currently are not being served by the existing solutions, or whose needs are
being over‐satisfied?
d. Are you creating a new segment with a niche product?
This is a customer intimacy strategy, which is meeting the needs of a specific vertical
segment (e.g. accountants) better than anyone else. When picking this strategy, there
are two growth paths:
 Continue to identify broader needs of that vertical and expand the offering to serve
those needs. Thus, the company would create new products for its existing market.
 Adapt the current product to additional verticals.
Geoffrey Moore uses the metaphor of a bowling alley, in which each new application
area and vertical segment can be viewed as a pin.45 The goal is to knock over enough
pins to score a “strike” where the company’s products and footprint cover a wide
swatch of needs across multiple or most verticals.

44
Steve Blank in Four Steps to the Epiphany has an excellent discussion and detailed process on the steps to pursue
for each of the four market entry strategies. Blank uses the term “resegment” when referring to creating a new
low, end offering or niche offering.
45
Geoffrey A. Moore, Inside the Tornado (New York: HarperBusiness, 1995) pp. 38 – 39.
40
4. What is the product solution?
a. What will the product look like?
b. How many configurations or models will be supported?
c. What functions will the product perform?
d. How to do we want user to feel when using the product?
e. What is the out of box experience?
f. How will customers learn to use the product?
g. What is the warranty?
5. Differentiation
a. How does our solution differ from the alternatives?
b. What is the level of differentiation? Is it:
 Incremental?
 Major?
 Discontinuous?
c. Is the differentiation significant in the eyes of the customer?
d. Is the differentiation sustainable (IP, trade secret, exclusive distribution)?
6. What are the Solution/Development risks?
7. Who are the competitors?
a. What does the competitive landscape look like?
b. What are the likely competitive responses?
8. Are there any regulatory or legal issues to consider?
9. Are there any other open issues or risks?
Figure 14: Ansoff’s Product Growth Matrix. The matrix is in terms of your company. Thus, entering a new market means

entering a new market for the company. The market may be established with other companies serving its needs.

41
Business Model
1. What are the key customer segments?
a. How will each segment be reached?
b. How will the customer be made aware of the solution?
c. Does the customer need to be educated about the solution (important for new
markets)?
d. Do different segments require different channels for purchase and support?
e. Do different segments require different pricing models?
f. Do different segments require different service levels?
2. How will the product be monetized or priced?
a. What is the unit of value that will be sold?
b. What is the target price per unit of value (per user, per CPU, per gigabit, etc.)?
c. Are there multiple streams of revenue?
d. What services can be sold along with the product or vice versa (think beyond just
warranty and support)?
3. Where will the product be found?
a. Where can the product be discovered?
b. Where can the product be purchased?
c. Where can the product be serviced?
4. Service experience – what level and type of service will customers receive when:
a. Learning about the product?
b. Purchasing the product?
c. Receiving support for the product?
d. Receiving training for the product?
5. Financials
a. How many qualified leads to generate a sale?
b. What is the target customer acquisition cost?
c. What is the target lifetime customer value?
d. What is the value chain for each channel?
e. What will your cost structure look like?

42
Piecing It All Together
Applying the concepts to a project would look like this:

Step 1: Identify the Product‐ Step 2: Using the Product‐Market Fit Step 3: Apply the DHTL Cycle to

Market Fit Challenge Type Triad, explore what is well defined (i.e. structure the inquiry. Your aim is to
and sub‐type for your facts) and what is undefined (i.e. achieve sufficient validation of the
product: hypotheses that need to be tested or undefined areas of the Product‐
where the first round of discovery needs Market Fit Triad, in the shortest
Product‐Market Fit to occur) time, with the fewest resources. The
Challenge: DHTL cycle will be employed through
many iterations of learning during
 Optimize the planning, development, launch
 Market Driven and evolution of the product.
 Tech Driven
 Visionary
Business Model sub‐type:
 Business model
defined
 Business model
undefined

43
3
Becoming
Lean
Practices
Practices are activities that can be taught and followed. Given a set of conditions, following the practices
should positively correlate with success. It is also important to understand them deeply enough,
however, to know when they should and shouldn’t be followed. The great danger of listing practices in
a guide like this is that readers might blindly follow them, believing that simply going through the
motions will deliver the desired outcome or reward. This is the cargo cult approach to management.46
Think deeply about the change you are looking to realize, and ask if a given practice will help facilitate
that change. Then add the practice, giving the team enough time to become skilled with it. Once it is
working, examine it to make sure it is working as planned.
1. Product Management’s function is to focus on the problems that need to be solved, while the
function of engineering is to then develop a solution to address the problems identified. Design
happens in the middle, and is a collaborative team effort as practiced by those companies with a
design maturity level of four (Figure 15).
Figure 15: Olsen Design MaturityError! Bookmark not defined. model defines four levels
organizational capability

46
Cargo cults emerge when industrial and pre‐industrial tribal societies interact. Examples of this were observed
after World War II when military bases closed on the Pacific Ocean islands. Tribal members built crude landing
strips, air towers, and non‐functional radios. They then mimicked the behaviors of military personnel they had
observed, in the false belief that this would result in a plane bringing cargo to their island.
44

2. Understand the problem space to identify unmet needs and get feedback in the solution space.47
3. Teams
a. Sit with your team. New product creation is a collaborative effort that requires sustained
interaction between team members. This facilitates knowledge sharing, team alignment,
and optimized design and trade‐off decisions. Sitting with the your team also recognizes
that the value‐creating steps of new product creation run horizontally in the organization
crossing groups, rather than occurring vertically in a single function, and places many of
the value creating players together for better integration.
b. Distribution (as in distributed teams) is a constraint. Working with distributed teams
slows the project down and requires more effort to be successful. Relationships and
knowledge transfer require active management. Teams start to exhibit distribution drag
once people sit across the hall from one another. It goes up as they move to other floors,
buildings, time zones, languages and cultures. It takes additional investment and
conscious effort to overcome this drag.
c. Prioritize verbal and face to face communication. It is easier to send email and
documents. But make an effort to get out of your seat or video call to speak face‐to‐face
with team members and stakeholders.
d. Dedicate one or more team members to design – don’t overlook this critical role.
4. Only detail market and product requirements that have a high probability of being developed.
Thus, do not specify the whole product in detail upfront. Likewise, only research questions on
which you will take action once you have the answers.
5. Think in terms of Minimum Marketable Features (MMFs) and satisfaction criteria. MMFs
represent a granular element of value that is easy for the business side to track and understand.
The development team might further break MMFs down into stories and tasks as the probability
that the MMF will be developed becomes high.
6. Validate – this ties in with the principle of ABV (always be validating). Validation is a continual
process that occurs throughout the product lifecycle until the retirement phase. The goal is to
always have a measure of product‐market fit and how that fit is changing over time.
a. Perform rapid concept testing, including A/B testing to understand what works for the
customer. This also shortens design debates. Rather than debate which design or concept
would be best, test them both.
b. Establish KPIs (key performance indicators) – once in the market, establish KPIs that are
proxies for fit, such as conversion rates, retention rates, usage, etc.
c. Measure satisfaction and loyalty – once in the market, survey customer to baseline
satisfaction, measure changes and track relative to competitors.

47
Dan Olsen, http://www.slideshare.net/dan_o/lean‐product‐management‐for‐web‐20‐products
45
d. Other – there are many other forms of validation such as market message testing. For
physical products, environmental and performance testing such as shock, vibration,
packaging, and UV testing are all important ‐ not just in development but also after launch
to ensure that product quality is being maintained.
7. Set based concept development48 – in critical thinking we are taught to evaluate options, quickly
narrow the set, and proceed with the one option judged best. Instead, pursue multiple
alternatives concurrently in the early stages. This accelerates learning and allows the team to
make a better‐informed decision at a later date. The initial upfront work may take longer but will
prevent more rework later. This is also counter to the idea of iterative development where a
single design is started and iterated upon.
8. Delay decisions to the last responsible moment 49 – the longer you can delay a decision, the more
information you will have. Keep as many options open for as long as is responsible.
9. Time value analysis – understand how the business value of projects and features changes over
time. For example, does the value decay quickly with a short window of premium pricing (as in the
semi‐conductor market), or is your market fairly insensitive to the release of a new product and
happy to continue buying your current product?
10. When selecting projects with high ROI, detailed costing is an unnecessary delay and expense.
11. Budget projects to get to the next learning/validation point. You will then have better
information with which to make a decision.
12. Product Management Process Retrospectives – Have regular reflection meetings to evaluate your
current product management processes. Frame the discussion around the Lean Product
Management formula (figure 1) by asking will the process change produce a closer product‐market
fit, allow us to get to market faster, and/or decreased costs. Pull other departments into the
discussion that are involved in the value stream. Discuss what is working, what isn’t, where value
is not flowing, or blocking other teams, and how to improve. Discuss what experiments you can
run to test if an area of value flow can be improved and how processes might need to vary based
on the product‐market fit challenge (i.e. Type I, II, III, or IV).
13. Portfolio management
Understand how your portfolio is distributed across:
a. Type of problem ‐ Optimize (Type I), Market Driven (Type II), Tech Driven (Type III), and
Visionary (Type IV)
b. Level of differentiation (i.e. level of innovation)
i. Optimize (performance improvements of <100% or 2x)

48
The original term used by Toyota and described by A. Ward, J.K. Liker, J.J. Christiano, D.K. Sobek II in “The Second
Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster”, Sloan Management Review, Spring 1995,
Vol. 36, No. 3, p.44 is “set based concurrent engineering.” I prefer the term “Set‐based Software development”
used by Mary and Tom Poppendieck (Poppendieck p. 42). I have further shortened the term to “set based
development.”
49
Ibid, Poppendieck, p. 57
46
ii. Major (performance improvement >2x but <10x)
iii. Discontinuous (new idea, performance improvements >10x on selected axes)
c. Time to market
d. Expected period that differentiation will be maintained in the marketplace
e. Level of risk
f. Payback period and shape of the payback curve
g. Market dynamics
14. Community – do you have or can you build a community of users that you can observe, receive
ideas, and solicit feedback from? If you are fortunate enough to have such a community, consider
assigning a facilitator to manage that community.

Engineering practices also matter. The more the problem, solution, and/or business model are
undefined, the greater the benefit of Agile engineering practices such as Extreme Programming (XP) or
Scrum with XP practices of continuous integration, test first development, and incremental design.
Kanban software development is another good option. It will be impossible for the product
management group to execute the Discover, Hypothesis, Test, and Learn loop without an engineering
team using a methodology that is flexible to change.
47
Skills and Knowledge Areas
In addition to all the traditional skills product managers have needed, there is a new set to master. Lean
teams move in lock step, collaborating and contributing at each stage. Roles dissolve and competencies
emerge. Each team member usually has an area in which they excel, and for which they are responsible.
These map to the traditional role, such as product management, user experience, development, testing;
but there is fluidity as team members are able to cross over, assist each other and contribute to the
solution definition and design as it moves from rough concept to finished product.50
1. Chartering – facilitating the development of a charter that clearly outlines the vision, mission,
objectives, principles, stakeholders and boundaries of the project. The charter provides decision
guidance to all people involved in the project.
2. Emergent planning – working at different levels of detail in the plan and keeping options open
to adjust to new learning.
3. Quick validation – learn how to validate hypotheses quickly and take action.
4. Continuous customer collaboration – learn how to incorporate the customer throughout the
development cycle rather than at major interval or at end during the beta test.
5. If your product has a user‐facing interface
a. Prototyping/wire framing – these skills are important for exploring concepts with the
team and the customer.
b. Design and UX principles – so you are able to recognize good UX (user experience) and
interact with your design team in the areas such as information architecture and visual
design.
6. Analytics – know how to use analytics to test hypotheses, guide decision making, and to validate
product changes to ensure they have the intended positive impact.
7. Working in small batches – learn to work in small batches across multiple phases of the product
development cycle. Pass small batches of work through the development process so you and
the team remain flexible and responsive. Splitting out value is a sub‐skill of working in small
batches.
8. Agile development – whether your team is using Scrum, XP, Lean or another variant,
understand how your development team works, how to communicate market requirements,
how to support team members, and how to leverage this capability for competitive advantage.
9. Splitting requirements – learn to take large requirements (epics, sagas, etc.) and split them into
smaller requirements, minimum marketable features, and stories.

50
Teams are finding new ways, such as Lean UX, to include all members throughout the product development
effort. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka documented the benefits of a cross‐functional team working
together in their ground breaking Harvard Business Review Article “The New New Product Development
Game”[sic.] where they described the rugby‐based approach to product development where in the ball is passed
back and forth between team members. This article was one of the inspirations for Scrum software development.
48
10. Creativity facilitation – the job of the product manager is to identify the correct market problem
to solve and work with the product team to develop the best solution possible. Learn how to
tap into your team’s creative energy and facilitate the problem solving process.
Measures
Measures provide a mechanism to manage a process and understand if changes are improving or
worsening a situation. Measures, however, are not the goal. If the team believes they are being judged
on the measure, you will get more of it. This can lead to goal displacement. So beware how measures
are used. Consider driving a car: the speedometer is one measure that the driver consults. The driver
knows the higher the speedometer reading, the shorter time the trip will take. But if the driver becomes
focused on maximizing speed without regard to other considerations, he will end up with a speeding
ticket, or possibly experiencing a fiery death. Both are bad outcomes. In the context of Lean Product
management, measures act as instrumentation that allows us to identify variations and perform the
critical problem solving to improve our processes. Key measures are:
1. Throughput – the amount of value created per unit time, which at the whole system level will
lead to faster time to market.
2. Cycle time – there are many processes in which cycle time can provide insight. If we think about
the entire system, the company can evaluate “idea to market demand,” which measures how
long it takes the company to go from receiving an idea to placing a successful product in the
marketplace. “Successful” is a subjective term and highly contextual. The idea is that the
measurement is not made in terms of the time taken to first sale, but in terms of the point when
the management team would say the product has met the company’s expectation for
performance in users and revenue (this will vary dramatically by project type).
Within that major cycle of idea to market demand, examine the time spent in interim stages,
such as idea to approved project or MMF to releasable code. Use this data to balance the flow
of value across the team. Using an idealized example, imagine it takes one week to define a
feature, one week to define the user experience, and two weeks to develop the feature. Given
these timings, the team knows it must define a feature every other week, the user experience
every other week, and develop every week to maintain a smooth flow through the system.
Once a team has a baseline, the effects of process changes can be gauged and the team can
focus on removing or managing the bottlenecks in the system to keep value flowing.
3. WIP – Work in Progress needs to be monitored against cycle times. The more parallel tasks the
team takes on, the longer the cycle time to complete each task. The team needs to find the
right balance between throughput and cycle time. Adjusting WIP allows us to control the
responsiveness of our system.
4. Batch size – batch size defines the increment of value flowing through the system. Tracking this
49
metric can help the team focus on working in smaller batches. The Minimum Marketable
Feature (MMF) is a logical batch size or level of granularity for the product manager to work
with. Agile teams will prefer to further split the MMF into stories. Batch size can be measured
as cycle time per MMF, the number of stories per MMF, or story points per MMF, to understand
how batch size impacts the flow of value through the system. Because new product
development is a creative process, batch sizes will vary per MMF, so further categorization of
each MMF might be required (such as “small”, “medium” and “large”). Also, batch size is a
rough rather than a precise measure. The batch size metric relates to the skill of working in
small batches and learning to split out value, which is described in the Skills section above.
5. Queues –the team should seek to identify where cycle time is significantly greater than batch
size, meaning the item sat waiting without being worked on. If large queues are found, they
should be addressed. You can also look for any item that is aging excessively, maybe because
new MMFs keep coming along of higher priority. If an item is not being moved forward it could
be understaffed, blocked and needing escalation, or just not that important – in which case its
priority should be reconsidered.
6. Idea pipeline – measure how many ideas exist at each stage of development during the
screening process and the categorization of those ideas. Are they incremental, major, or
discontinuous? Are the ideas balanced across the company’s different product areas and lines
of business?
7. New product pipeline – looking at approved projects, how does the new product pipeline
breakdown by type of project and area of business?
8. Revenue and profit from new products – revenue and profit from new products are a good
measure of whether the company is delivering differentiated product to the marketplace and
remaining competitive. During the mid‐1990s, for example, Hewlett Packard generated over
80% of its revenue from products introduced less than five years previously.51
9. Resource allocation – many companies struggle to remain disciplined in pursuing long term
needs when overwhelmed with so many urgent short‐term requirements. Committing to how
R&D dollars will be allocated by type of project can be easier than trying to evaluate each
project individually. Tracking this allocation by projects and dollars can provide insight into
whether the company is balancing its investment. That means tracking percentage of spend
allocated to:
a. Disruptive products
b. Major improvement products
c. Incremental products
d. Maintenance

10. Outcomes – The ultimate measure is this: did the release or the product achieve its stated goals

51
David Packard, The HP Way (New York: Collins Business Essentials, 1995) pp. 211 – 212.
50
(sales, profits, users, market share, customer satisfaction) in the forecast timeframe? Although
outcomes are lagging indicators, closing the feedback loop and reflecting on successes and
misses provides valuable information for improvement.
In some company cultures, it is common to overstate the business case for a project to get it
resourced. That practice is only safe when actual results are never compared to forecasts. This
leads to sub‐optimal decision‐making and loss of organizational learning. Measuring outcomes
breeds a more honest environment for making decisions.
Pay‐Off and Risk
One might ask which type of product management challenge has the greatest payoff. The answer
depends on the level of value being created and the maturity of a market. Optimizers are not
condemned to small wins. Dell rose to be a Fortune 500 company by doing an exceptional job of serving
a rapidly growing market. RedBox, a tech driven company, became a true force in the mature DVD
rental market by offering greater convenience at a lower price than Blockbuster. Dell and RedBox also
assumed considerable risk in developing their businesses, as their business models were unproven.
If you are going to pursue a visionary product, you need to believe the opportunity is substantial to
assume the risk that comes with that much uncertainty. Furthermore, visionary products run the risk of
being too early, as it is very hard to time markets accurately. Visionary companies also take the risk that
the technology may not perform adequately.
Go Corporation, for example, was a high‐flying pen Based tablet computing company founded in 1987.
The company attracted top talent, top partners and top investors. It burned through a staggering $75
million before being shut down seven years later.52
The Apple Newton, a similar project to create a handheld, pen‐based computer, started in 1987. Prior
to launch, the Newton was recast as a new category of product called a Personal Digital Assistant
(PDA).53 It failed in the marketplace.54 Almost 20 years later, Apple finally struck gold by extending the
original Newton vision with its iPhone (released in 2007) and iPad (released in 2010) products.
Visionary products are high risk. Failure, however, does not always have to come with the high price tag
associated with the products above. Products, especially web‐based products, can be built by small

52
http://en.wikipedia.org/wiki/GO_Corp.
53
Palm Inc. was the company that finally succeeded in the PDA space but not until 1997 with the release of its
second generation products the Palm Pilot and the Palm Pilot Professional. By this point they were already a
subsidiary of U.S. Robotics. [http://en.wikipedia.org/wiki/Palm_Inc]
54
http://en.wikipedia.org/wiki/Apple_Newton
51
teams in a short period of time, for relatively little cost. This new model of business economics ‐ the
result of Agile software development, open source software, and the Internet ‐ significantly reduces the
risk of visionary projects.
Portfolio Planning and the Ideation Funnel
With multiple projects that have varying levels of potential impact, risk, and time horizons, a company
must maintain a holistic view to optimize its returns. The portfolio must be managed to ensure that a
balanced set of bets is being placed against maintaining the current business, identifying new avenues of
growth, and the expected maturation of each project (Figure 16). Further, it is easy to get bogged down
focusing on incremental improvements in an attempt to retain existing customers. Incremental
requirements take the least amount of effort to uncover and validate, and are low risk. But a company
must continue to invest in projects that will create a level of differentiation associated with major and
discontinuous innovation. Figure 16 shows an example of a portfolio that is underweight in medium‐
term major impact projects.55
Figure 16: Example portfolio view of current projects based on differentiation, level of
uncertainty, and time horizon

55
Guidance is not provided on what constitutes a short, medium, or long term planning horizon. These are based
on industry, level of growth, and level of change or disruption occurring.
52
The flow of new ideas that will lead to new projects must also be managed. As new ideas can come
from anyone, anywhere, at any time, companies need a process for effectively collecting, categorizing,
and screening. Being able to assimilate new ideas faster than the competition offers competitive
advantage. The more effective and efficient a company is at collecting and screening idea, the more
likely it can exploit an idea to further differentiate its products in the market.
Lastly, certain elements of uncertainty are specific to a company’s context and capabilities. Referring
back to Ansoff’s Product Growth matrix (Figure 14), when a company enters a new market, the project
has more uncertainty and risk than if the same project was performed by a company with an established
brand and distribution channel in that market. Because uncertainty is contextual, a project may
represent a great opportunity for one company and a poor one for another. Every company must
evaluate whether an opportunity is a good fit for it.
As an example, Xerox, whose Palo Alto Research Center (PARC) invented the computer mouse, is often
criticized for not commercializing the technology. But was Xerox ‐ a company focused on selling to the
enterprise with many promising projects in progress ‐ the right company to do it? Or was Apple’s Steve
Jobs, who saw PARC’s invention, in a much better position to figure out (with the help of IDEO) how to
take this invention and turn it into a commercially viable product? Apple’s ultimate achievement was
not a straightforward one: The mouse went from three buttons to one; the graphical interface (also
from PARC) that it interacted with was transformed; the manufacturing cost was reduced from $300 to
$15; and it went from a finicky prototype to a reliable device.56
Implications to phase gate
Phase gate, as typically practiced, is a serial process with limited flexibility. Positioning, design, feature
set, business model and risks are fixed at the early stages of the project. Phase gate assumes near‐
perfect information upfront. As this guide shows, there are many product‐market fit challenges where
our understanding of the customer and need are far from perfect and will never be perfect.
Fred Wilson, partner at Union Square Ventures, noted these statistics for his portfolio about
“transformers” ‐ companies that made a significant pivot, compared to those who stuck to their plan:
Success Investment Return Transformed Stuck to Original Plan % that Transformed
Outstanding Greater than 5x 7 4 64%
Moderate 1x-5x 6 4 60%
Failures Lost money 1 4 20%

Figure 17: Start‐ups that made a significant change to their original business plan succeeded more often than
companies that stuck to their original business plan

56
M. Gladwell, “Creation Myth”, The New Yorker, May 16, 2011
53
Mr. Wilson also notes that until a company has figured out its product and business model, it is essential
to keep the burn rate (i.e.. expenses) to a minimum.57 Lean product managers must also do the same.
This is why finding the product‐market fit fast with minimum resources is so critical. Companies’
funding mechanisms must meter funding judiciously and not only permit but encourage departures
from the original plan.
Implications for project funding
If the product management team is unable to produce any of three things:
1. A Reliable plan, because the product definition or business model is expected to shift
2. Reliable costs, because the product cannot be fully defined upfront
3. A reliable sales forecast, because the market size is unknowable (the case with entirely new
markets)
…then the funding mechanism must also be altered. If it is not altered, the team becomes forced to
fabricate a business case, which does not serve the team’s or the business’s best interests. The team
may also take on more resources than appropriate given the early stage risks and likelihood that the
plan will change.
Resources, therefore, need to be agreed upon upfront (i.e. initial team size and budget), along with the
hypotheses to be tested and the interim metrics that will define success for that iteration. For
companies with annual funding cycles, the frequency of funding decisions needs to increase. Some
projects will get expanded, many will change, and some will get shutdown during the year. There are
similarities to the phase gate process described above: the company still has control and check points,
except the phases overlap and get reordered. The product planning phase might actually include
building a lightweight version of the product and launching it. The data collected may cause the product
to be reconceived, and will influence the planning, the business model, product positioning, sales
messaging, and more. Building the product and observing it in the wild is a necessary step to complete
product planning and, further, to understanding if the product is one that the company wants to fund
and maintain in the future. Thus, the phases are defined by a set of interim objectives designed to
prove the validity of the initial concept. The team may cycle quickly between any one of them and in any
order (Figure 18). The focus shifts from gates that are ordered by the activity (e.g. planning,
development, etc.) to gates phased by learning objectives.

57
F. Wilson, “Why Early Stage Venture Investments Fail”, www.USV.com, November 30, 2007
(http://www.usv.com/2007/11/why‐early‐stage.php)
54

Figure 18: Traditional serial product lifecycle is ordered by activity. In contrast the concurrent product lifecycle
needed for the many product‐market fit challenges in which the problem, solution or business model are not
fully defined is phased by learning objectives.

The goal is to accelerate the time to product‐market fit. So although working in this fashion may seem
less certain, it does allow the company to manage risk and leverage emergent learning and
opportunities.
For an existing product with a fixed product team, the company needs to shift from holding the team
accountable for executing on the plan to holding the team accountable for the outcome. This allows
the team to adjust the plan to optimize the outcome. The alternative is for the team to pursue the
original plan, even though they know the results will be sub‐par, because they are obliged to execute
the plan ‐ and, in all likelihood, being personally evaluated in terms of its performance.
Leaks versus Launches
This guide emphasizes the importance of collecting real feedback as early as possible in the process,
which includes putting the product into the marketplace as early as possible and iterating quickly. This
is also known as leaking the product into the market. There are times, however, when releasing the
narrowest sliver of useful product does not make sense. For existing brands, anything released must live
up to the brand promise. If the product is not at a sufficient level of polish, the brand will be damaged.
Another reason is if you expect the product to garner significant press at its launch. The value of a large
launch is that press mentions and the subsequent buzz creates awareness and demand for the product.
A well‐orchestrated launch of a newsworthy product can be more cost effective than generating an
55
equivalent amount of demand through paid advertising and other sales and marketing mediums.
Referencing the Lean formula (figure 1), if a launch event will lower the total customer acquisition cost
significantly, it makes sense to spend the additional time and resources to develop a fuller featured
product that appeals to a broader target market and use an invite only beta to validate fit. In this
scenario, time to market increases, fit may decrease slightly by limiting testing to beta users, and
development costs increase. These added costs and lost revenue are more than offset by the increased
sales at launch and the lower customer acquisition costs.
Process Improvement
This guide focuses on achieving sustained competitive advantage through better product‐market fit in
both product and business model design. The reason for this focus is that product managers routinely
influence both these areas. Process, however, can also lead to sustained competitive advantage and
should not be overlooked. As mentioned in the case studies, Dell’s success was not purely attributable
to its direct build‐to‐order sales model, but also to its superior supply chain management. While
product managers should remain alert to process areas that can give their companies an advantage in
the marketplace, Lean Product Management is a method that is in the control of the product
management group. By focusing on optimizing the process of product management, companies can
achieve further advantage against the competition. This is the reason that the practice of product
management retrospectives and measures are included in Lean Product Management.
Where Do Services Fit?
Services are a tremendous source of competitive advantage. Better service can overcome the challenge
of an undifferentiated product. Dell won over many customers because it allowed them to configure
their computer (memory, disk size, CPU, etc.) from standard parts. Zappo’s (which was acquired by
Amazon in 2009) sells shoes online. The shoes can be procured from other online sources and in shoe
stores. But Zappo’s succeeded through an easy return policy and fanatical customer support that kept
customers loyal and returning for more.
When applying the Lean Product Management framework, a service can be viewed as either a product
or as part of the business model. There is some leeway on where it fits best. As a general guideline, if
the service is sold, such as YouSendIt’s large file delivery system, treat it as a product. If the service is
not sold, such as Dell’s computer configurator application on its website, consider the service as an
aspect of the business model.

56
Conclusion
Successful companies must have a competitive advantage. Michael Porter stated there are only two
forms of competitive advantage: lower costs and differentiation.58 Lean Product Management supports
a company’s efforts to achieve such an advantage. It does this on three fronts:
1. Better product‐market fit ‐ which means a more differentiated product
2. In less time – which means the company enjoys a maximum differentiation in the marketplace
for longer and accelerates learning.
3. With fewer resources – becoming more efficient means the product team can move faster with
less wasted effort and ultimately less cost.
The process a company should follow when developing a new product should match the type product‐
market fit challenge being addressed. When an area is well defined, product managers perform
analysis. When undefined, the product manager can only perform synthesis.59 Thus, companies should
not implement a single standardized process or measures for developing new products. New product
creation is not a one‐size‐fits‐all model. But consistent values, practices, skills and measures can assist
teams in optimizing the new product development process. Applying and refining the right process to
deliver product‐market fit in less time with fewer resources can provide a lasting competitive advantage.
Advancing the Discussion
This guide is just the start of a fundamental shift in product management practice and effectiveness.
We need product managers’ feedback and experiences to accelerate the discussion and build upon the
body of Lean Product Management knowledge. Clearly, the more that Lean principles are applied, the
greater the body of knowledge and data that will exist for the product management community to draw
on as we develop the ideas further. As such, this guide is intended as a call to action as much as a
handbook: we know about the great effects Lean can have ‐ but to realize them consistently and build
on them, we have to roll our sleeves up and start using them.
Please join the discussion. If you have feedback, a story of success or failure, or other insights, please
email me: greg(at)280group.com.

58
Michael E. Porter, Competitive Advantage (New York: The Free Press, 1985), p. 11
59
J.R. Boyd, “Creation and Destruction”, September 1976, p. 2.
57
Acknowledgements
If you find the concept of Lean Product Management thought‐provoking and valuable, I am grateful. It is
important, however, to point out that this would never have been achieved if it was not for the
significant effort of many brilliant individuals whose have indelibly changed my view of the world and
allowed me to see connections between my own product management experiences (in such varied
areas as medical diagnostics to scrappy Internet start‐ups) and the benefits of Lean thinking. It is always
hard to produce a list like this, and any misinterpretation or misrepresentation of their work is both
unintended, and my responsibility alone.
I would particularly like to thank Dan Olsen who has indulged me in lengthy conversations on product
management. Dan has made a number of key contributions both to this guide and the field of Lean
Product Management as a whole.
I would also like to thank Brian Lawley for his support during the writing of this book, and my colleagues
at 280 Group ‐ in particular Phil Burton, David Fradin and Jim Reekes ‐ for keeping me intellectually
honest. I am thankful for having such an amazing set of colleagues with whom I can share my passion
for product management.
I have listed the names of other individuals whose work I have built upon, or who have influenced my
thinking, in alphabetical order to avoid any bias.
Joe Arnold, David Anderson, Jeff Bay, Kent Beck, Steven Blank, Ronald Brown, Marty Cagan, Jane
Cleland‐Huang, Oden Cohen, W. Edwards Demming, Mark Denne, Pascal Dennis, Michael Feldman, Scott
Gilbert, Eliyahu Goldratt, Bill Gross, Luke Hohmann, Geoff Huckleberry, Ron Jeffries, Daniel Jones,
Avinash Kaushik, Joshua Kerievsky, Henrik Kniberg, Corey Ladas, Domenico Lapore, Lawrence Miller, Rich
Mironov, Geoffrey Moore, Taiichi Ohno, Paul Oldfield, Alexander Osterwalder, Jeff Patton, Yves Pigneur,
Mary and Tom Poppendiecks, Eric Ries, Jeni Sall, Ken Schwaber, Alan Shalloway, Dennis Stevens, Jeff
Sutherland, Scott Weiss, Jim Womack.
I would also like to thank my clients, who have openly shared their challenges with me, and the students
who have taken my classes. You expose me to the large variety of contexts and constraints in which
product management is practiced and ask amazing questions. It is really you who have taught me. You
have provided me with the motivation to seek out better answers and look beyond current practice.
I’d also like to thank the individuals who suffered through early drafts of this book: Ron Brown, Phil
Burton, Tom Evans, David Fradin, Brian Lawley, Dan Olsen. Thank you to Bill Hilton for making this book
more readable and Yasemin Akyuz for cover design, layout and illustrations, and Carrie Naito for your
keen eye in finding typos that everyone else missed.

58
About the Author
Greg Cohen is a Senior Principal Consultant with the 280 Group and a 15‐year
Product Management veteran with extensive experience and knowledge of
Agile development, a Certified Scrum Master, and former President of the
Silicon Valley Product Management Association. He has worked and consulted
to venture start‐ups and large companies alike and has trained product
managers throughout the world on Agile development, road mapping, feature
prioritization, product innovation, product lifecycle process, and product
management assessment. Greg is the author of the books Agile Excellence for
Product Managers and 42 Rules of Product Management as well as a speaker
and frequent commentator on product management issues.
Greg earned an MBA with honor from Babson College and a Bachelor of Science in Mechanical
Engineering with second major in Electrical Engineering from Tufts University.
About 280 Group
The 280 Group helps companies to deliver products that delight their customers and dramatically
increase their profits by providing consulting, product management process assessment, training,
certifications, contractors, templates and books. Winner of numerous awards and featured on CNBC’S
World Business Review and the Silicon Valley Business Report, since 1998 the 280 Group’s
methodologies have been used by tens of thousands of companies across the world to increase their
product management and product marketing effectiveness.

59
Other Books by the 280 Group

Agile Excellence for Product Managers
A plain speaking guide on how to work with Agile development teams to achieve
phenomenal product success

42 Rules of Product Management
A collection of product management wisdom from forty experts from around the
world.

The Phenomenal Product Manager
This book goes beyond the basics and teaches you how to work more effectively
with your teams, how to influence when you have no formal authority, how to get
the most important work done in less time and how to manage and accelerate your
career.

Expert Product Management
Learn four of the most critical elements in ensuring product success, and take‐away
practical strategies, insights, tips and techniques to give your product the best
possible chance for success.

60

Lean Product Management 1.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lean Product Management 1.1

Uploaded by

Copyright:

Available Formats

Optimize Market Driven Tech Driven Visionary

Problem Defined Defined Defined Defined Undefined Undefined Undefined Undefined

Product Defined Defined Undefined Undefined Defined Defined Undefined Undefined

Step 1: Identify the Product‐ Step 2: Using the Product‐Market Fit Step 3: Apply the DHTL Cycle to

Success Investment Return Transformed Stuck to Original Plan % that Transformed

Outstanding Greater than 5x 7 4 64%

Moderate 1x-5x 6 4 60%

Failures Lost money 1 4 20%

You might also like