In our first class, we’ll discuss the various characteristics and types of products, paying particular attention to the product lifecycle. We’ll introduce the idea of a business model, and discuss the various risks that products might face in different parts of the product lifecycle. We’ll review a brief history of project and product management, and discuss the differences between the two.
i290 lean/agile product management
unit 1: foundations
This work © 2015-20 Jez Humble
Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
grasp the history of project management
understand the lifecycle of products
be able to perform basic risk analysis
know the di
erence between product and project
understand the forces acting on products now
by type: web service, user-installed, embedded
something people will give you money for
goods and services
by lifecycle stage: disruptive, incremental, commodity
by market: b2b (enterprise); b2c (consumer)
usion of innovations
Total Addressable Market (TAM)
technology adoption lifecycle
rey Moore, Crossing the Chasm
What are the most important costs inherent in our business model?
Which Key Resources are most expensive?
Which Key Activities are most expensive?
Through which Channels do our Customer Segments
want to be reached?
How are we reaching them now?
How are our Channels integrated?
Which ones work best?
Which ones are most cost-efficient?
How are we integrating them with customer routines?
For what value are our customers really willing to pay?
For what do they currently pay?
How are they currently paying?
How would they prefer to pay?
How much does each Revenue Stream contribute to overall revenues?
Customer Relationships Customer Segments
How do we raise awareness about our company’s products and services?
How do we help customers evaluate our organization’s Value Proposition?
How do we allow customers to purchase specific products and services?
How do we deliver a Value Proposition to customers?
5. After sales
How do we provide post-purchase customer support?
Dedicated Personal Assistance
For whom are we creating value?
Who are our most important customers?
What type of relationship does each of our Customer
Segments expect us to establish and maintain with them?
Which ones have we established?
How are they integrated with the rest of our business model?
How costly are they?
What value do we deliver to the customer?
Which one of our customer’s problems are we helping to solve?
What bundles of products and services are we offering to each Customer Segment?
Which customer needs are we satisfying?
What Key Activities do our Value Propositions require?
Our Distribution Channels?
Who are our Key Partners?
Who are our key suppliers?
Which Key Resources are we acquiring from partners?
Which Key Activities do partners perform?
What Key Resources do our Value Propositions require?
Our Distribution Channels? Customer Relationships?
“Getting the Job Done”
types of resources
Intellectual (brand patents, copyrights, data)
motivations for partnerships:
Optimization and economy
Reduction of risk and uncertainty
Acquisition of particular resources and activities
is your business more:
Cost Driven (leanest cost structure, low price value proposition, maximum automation, extensive outsourcing)
Value Driven (focused on value creation, premium value proposition)
Fixed Costs (salaries, rents, utilities)
Economies of scale
Economies of scope
The Business Model Canvas On:
Day Month Year
Product feature dependent
Customer segment dependent
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License.
To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/
or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
product development is primarily about
risk management. what are the risks? what
are the probabilities and economic
impacts? which ones do we care about?
how can we measure and mitigate them?
3. contingency planning. What do we do if the risk
1. risk discovery. Initial analysis, then ongoing
2. exposure analysis. quantify risks
probability [0-1] x impact [$]
5. ongoing monitoring. Track risks, look for
4. mitigation. Make sure planned contingency
actions will work
3. feasibility risk (whether our engineers can build what we
need with the time, skills and technology we have)
1. value risk (whether customers will buy it or users will
choose to use it)
2. usability risk (whether users can
gure out how to use it)
4. business viability risk (whether this solution also works for
the various aspects of our business)
• 5m to come up with ideas individually
• 10m to create risk matrix as a group
• 5m to present back to rest of group
Third parties mess with you
It's too hard to use
You can't actually build it
The law of unintended consequences
Your business runs out of money
Your supply chain is disrupted
No one wants it
You can't sell it pro
The government intervenes
Acts of god
usion of innovations
- do we have a problem worth solving?
- is there strong demand for our
explore vs exploit
Baghai, M., Coley, S. and White, D., The Alchemy of Growth
Intuit horizons and metrics
Nassim Taleb, Antifragile
By Joi Ito from Inbamura, Japan - USAF/IBM SAGE, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=2106156
Laboratory) in 1969
with source code from
the Apollo Project
“Managing the Development of Large Software Systems” by Dr Winston W Royce. 1970
I believe in this concept, but the
implementation described above is
risky and invites failure.
Shareholder value is the dumbest idea in
the world … [it is] a result, not a strategy
… Your main constituencies are your
employees, your customers and your
Jack Welch | http://www.ft.com/cms/s/0/294ff1f2-0f27-11de-ba10-0000779fd2ac.html
Testing Business Ideas, Bland / Osterwalder, px
We must set measurable objectives for each next small
delivery step. Even these are subject to constant
cation as we learn about reality. It is simply not
possible to set an ambitious set of multiple quality, resource,
and functional objectives, and be sure of meeting them all as
planned. We must be prepared for compromise and trade-
. We must then design (engineer) the immediate technical
solution, build it, test it, deliver it—and get feedback. This
feedback must be used to modify the immediate design (if
necessary), modify the major architectural ideas (if
necessary), and modify both the short-term and the long-
term objectives (if necessary).
Tom Gilb, Principles of Software Engineering Management (1988), p91
1. build the right thing
2. reduce risk of release
3. real project progress
manufacturing vs software
Must be completed before it can be
Can start using it from early on in
product development process
Must avoid signi
once design complete
Cheap to change if we discover
problems early enough
Doesn’t change much once
Successful products evolve
“Instead of arguing about new software ideas,
we actually tried them out by writing quick
prototypes, keeping the ideas that worked
best and discarding the others. We always had
something running that represented our best
thinking at the time.”
“The Macintosh Spirit” | http://www.folklore.org/StoryView.py?
product vs project
• projects have an end-date and a single
customer, and we care about scope, cost,
quality, and hitting the date.
• products are evolving continuously, we have
multiple customers, and we care about a
broader set of risks