Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Unit 1. Introduction to the Product Lifecycle.

Jez Humble
August 27, 2018

Unit 1. Introduction to the Product Lifecycle.

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.

Jez Humble

August 27, 2018

More Decks by Jez Humble

Other Decks in Education


  1. i290 lean/agile product management unit 1: foundations @jezhumble https://leanagile.pm/ [email protected]

    This work © 2015-20 Jez Humble Licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
  2. 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
  3. 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
  4. diffusion of innovations Competitive advantage Commodity

  5. technology adoption lifecycle Geoffrey Moore, Crossing the Chasm

  6. old way

  7. new way What are the most important costs inherent in

    our business model? Which Key Resources are most expensive? Which Key Activities are most expensive? ATeT]dTBcaTP\b 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? 2WP]]T[b 2dbc^\TaAT[PcX^]bWX_b 2dbc^\TaBTV\T]cb RWP]]T[_WPbTb) 0fPaT]Tbb  7^fS^fTaPXbTPfPaT]TbbPQ^dc^daR^\_P]hzb_a^SdRcbP]SbTaeXRTb. !4eP[dPcX^]  7^fS^fTWT[_Rdbc^\TabTeP[dPcT^da^aVP]XiPcX^]zbEP[dT?a^_^bXcX^]. "?daRWPbT  7^fS^fTP[[^fRdbc^\Tabc^_daRWPbTb_TRX R_a^SdRcbP]SbTaeXRTb. #3T[XeTah  7^fS^fTST[XeTaPEP[dT?a^_^bXcX^]c^Rdbc^\Tab. $0UcTabP[Tb  7^fS^fT_a^eXST_^bc_daRWPbTRdbc^\Tabd__^ac. <Pbb<PaZTc =XRWT<PaZTc BTV\T]cTS 3XeTabX TS <d[cXbXSTS?[PcU^a\ TgP\_[Tb ?Tab^]P[PbbXbcP]RT 3TSXRPcTS?Tab^]P[0bbXbcP]RT BT[UBTaeXRT 0dc^\PcTSBTaeXRTb 2^\\d]XcXTb 2^RaTPcX^] 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? EP[dT?a^_^bXcX^]b :Th0RcXeXcXTb :Th?Pac]Tab :ThATb^daRTb 2^bcBcadRcdaT 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? RWPaPRcTaXbcXRb =Tf]Tbb ?TaU^a\P]RT 2dbc^\XiPcX^] {6TccX]VcWT9^Q3^]T| 3TbXV] 1aP]SBcPcdb ?aXRT 2^bcATSdRcX^] AXbZATSdRcX^] 0RRTbbXQX[Xch 2^]eT]XT]RTDbPQX[Xch RPcTV^aXTb ?a^SdRcX^] ?a^Q[T\B^[eX]V ?[PcU^a\=Tcf^aZ ch_Tb^UaTb^daRTb ?WhbXRP[ 8]cT[[TRcdP[QaP]S_PcT]cbR^_haXVWcbSPcP 7d\P] 5X]P]RXP[ \^cXePcX^]bU^a_Pac]TabWX_b) >_cX\XiPcX^]P]STR^]^\h ATSdRcX^]^UaXbZP]Sd]RTacPX]ch 0R`dXbXcX^]^U_PacXRd[PaaTb^daRTbP]SPRcXeXcXTb Xbh^daQdbX]Tbb\^aT) 2^bc3aXeT][TP]TbcR^bcbcadRcdaT[^f_aXRTeP[dT_a^_^bXcX^]\PgX\d\Pdc^\PcX^]TgcT]bXeT^dcb^daRX]V EP[dT3aXeT]U^RdbTS^]eP[dTRaTPcX^]_aT\Xd\eP[dT_a^_^bXcX^] bP\_[TRWPaPRcTaXbcXRb) 5XgTS2^bcbbP[PaXTbaT]cbdcX[XcXTb EPaXPQ[TR^bcb 4R^]^\XTb^UbRP[T 4R^]^\XTb^UbR^_T fffQdbX]Tbb\^ST[VT]TaPcX^]R^\ CWT1dbX]Tbb<^ST[2P]ePb >]) 8cTaPcX^]) 3TbXV]TSQh) 3TbXV]TSU^a) Day Month Year No. ch_Tb) 0bbTcbP[T DbPVTUTT BdQbRaX_cX^]5TTb ;T]SX]VAT]cX]V;TPbX]V ;XRT]bX]V 1a^ZTaPVTUTTb 0SeTacXbX]V gTS_aXRX]V ;Xbc?aXRT ?a^SdRcUTPcdaTST_T]ST]c 2dbc^\TabTV\T]cST_T]ST]c E^[d\TST_T]ST]c Sh]P\XR_aXRX]V =TV^cXPcX^]QPaVPX]X]V HXT[S<P]PVT\T]c ATP[cX\T<PaZTc 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.
  8. risk management 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?
  9. 3. contingency planning. What do we do if the risk

    materializes? 1. risk discovery. Initial analysis, then ongoing 2. exposure analysis. quantify risks probability [0-1] x impact [$] 5. ongoing monitoring. Track risks, look for materialization, mitigate. 4. mitigation. Make sure planned contingency actions will work measuring risk
  10. risk matrix probability impact low probability low impact high probability

    low impact low probability high impact high probability high impact
  11. exercise visit https://bit.ly/lapm-risk • 5m to come up with ideas

    individually • 20m to create risk matrix as a group • 5m to present back to rest of group
  12. diffusion of innovations MOST IDEAS FAIL!

  13. key transitions 1. problem/solution fit - do we have a

    problem worth solving? 2. product/market fit - does our business model work?
  14. explore vs exploit

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

    Alchemy of Growth
  16. Intuit horizons and metrics

  17. optionality Nassim Taleb, Antifragile

  18. SAGE console By Joi Ito from Inbamura, Japan - USAF/IBM

    SAGE, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=2106156
  19. Margaret Hamilton (Director, Software Engineering Division, MIT Instrumentation Laboratory) in

    1969 with source code from the Apollo Project (bit.ly/agc-code) http://bit.ly/2ciNWcY
  20. None
  21. 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.
  22. None
  23. @jezhumble v-model

  24. @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
  25. @jezhumble http://www.flickr.com/photos/subtle_devices/849361922/

  26. Testing Business Ideas, Bland / Osterwalder, px

  27. 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
  28. @jezhumble releasing frequently 1. build the right thing 2. reduce

    risk of release 3. real project progress
  29. 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
  30. 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
  31. http://www.businessinsider.com/here-comes-elon-musks-announcement-about-ending-tesla-range-anxiety-2015-3

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