This document provides an overview of a course on lean/agile product management. It outlines the following key points: 1) The course covers topics such as the history of project and product management, the product lifecycle, agile software development, lean startup, and innovation accounting. 2) Grading will be based on attendance, a group presentation, a group project, and weekly assignments. 3) The goal is for students to understand concepts like the history of project management, the product lifecycle, risk analysis, and the differences between products and projects.

1. i290 lean/agile product management
unit 1: foundations
@jezhumble
https://leanagile.pm/
humble@berkeley.edu
This work © 2015-17 Jez Humble
Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

2. course overview
• The history of project & product management
• The product lifecycle
• Economic frameworks for product management
• User research
• Agile software development
• Lean startup
• The experimental paradigm of product development
• How to grow high performance teams
• Release planning
• Process improvement
• Innovation accounting
• Product marketing
• Venture capital

3. assignments and grading
• 15% for attendance;
• 20% for one 25 minute group topic presentation;
• 30% for your 25 minute final group project;
• 35% for a set of weekly assignments as described in the
syllabus which take the form of either exercises or short
essays.
Full details at https://leanagile.pm/

4. grasp the history of project management
understand the lifecycle of products
be able to perform basic risk analysis
know the difference between product and project
understand the forces acting on products now
learning outcomes

5. 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)
product

6. lifecycle of innovations

7. technology adoption lifecycle
Geoffrey Moore, Crossing the Chasm

8. 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?
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?
Customer Relationships?
Revenue streams?
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?
Revenue Streams?
Day Month Year
No.
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.

9. business plan

10. risk management
product development is primarily about risk
management. what are the risks? what are
their probabilities and economic impacts?
which ones do we care about? how can we
measure and mitigate them?

11. risk matrix
probability
impact
low probability
low impact
high probability
low impact
low probability
high impact
high probability
high impact

12. exercise
• divide room up into groups based on lifecycle stage:
– brand new, disruptive product: LCD film you stick on
windows that can display images or be completely black
– enhancement to existing product: Windows that are 50%
thinner than existing windows
– legacy product: vinyl windows
• 5m to come up with ideas individually
• 15m to create risk matrix as a group
• 5m to present back to rest of group

13. product/market fit
MOST IDEAS
FAIL!

14. explore vs exploit

15. three horizons
Baghai, M., Coley, S. and White, D., The Alchemy of Growth

16. Intuit horizons and metrics

18. Margaret Hamilton
(Director, Software
Engineering Division,
MIT Instrumentation
Laboratory) in 1969
with the source code
for the Apollo 11
Guidance Computer
http://bit.ly/2ciNWcY

19. waterfall
“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.

21. @jezhumble
v-model

22. @jezhumble
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
products.
Jack Welch | http://www.ft.com/cms/s/0/294ff1f2-0f27-11de-ba10-0000779fd2ac.html
Bernard Gagnon

23. @jezhumblehttp://www.flickr.com/photos/subtle_devices/849361922/

24. We must set measurable objectives for each next small
delivery step. Even these are subject to constant
modification 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-
off. 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

25. @jezhumble
releasing frequently
1. build the right thing
2. reduce risk of release
3. real project progress

26. manufacturing vs software
Manufacturing Software
Must be completed before it can be
used
Can start using it from early on in
product development process
Must avoid significant “discoveries”
once design complete
Cheap to change if we discover
problems early enough
Doesn’t change much once
completed
Successful products evolve
enormously

27. apple macintosh
“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?
project=Macintosh&story=The_Macintosh_Spirit.txt

28. http://www.businessinsider.com/here-comes-elon-musks-announcement-about-ending-tesla-range-anxiety-2015-3

29. 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