Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Wont Get Fooled Again by Jeff Patton

34.974 visualizaciones

Publicado el

How organizations are learning to value learning and not just velocity!

We all hate wasting time and money. In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value. And, further, activities that don't result in a product we can deliver are waste. But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea. They likely don't.

This talk is about the rise of learning as a valuable activity. I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing. At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all.

Publicado en: Software
  • Inicia sesión para ver los comentarios

Wont Get Fooled Again by Jeff Patton

  1. WON’T GET FOOLED AGAIN How  organiza+ons  have  evolved  to  value   learning  over  self-­‐decep+on Jeff  Pa'on jeff@jpa' twi'er:  @jeffpa'on
  2. WON’T GET FOOLED AGAIN How  organiza+ons  have  evolved  to  value   learning  over  self-­‐decep+on Jeff  Pa'on jeff@jpa' twi'er:  @jeffpa'on
  3. Trust me, I know what I’m doing
  4. If you’re not failing, you’re not learning -- Derek Sivers,, you should watch the video Why You Need to Fail: watch?v=HhxcFGuKOys
  5. Let’s talk about me...
  6. I don’t need testers
  7. This  is  Bill
  8. Testers  are  team  members
  9. They  work  as  partners  with  developers
  10. Lesson: Testing well is a critical discipline, and a skill you can work a lifetime to be good at. It takes complimentary skills to make a team
  11. I’m a fabulous UI designer
  12. I’m  an  art  school  dropout
  13. 13 As a front-end developer, I was the man
  14. 14 Until we shipped
  15. Lesson: UI design isn’t about making things look good
  16. User  experience  has  layers 49
  17. Build  up  from  the  bo:om 49
  18. Build  up  from  the  bo:om 49
  19. Build  up  from  the  bo:om 49
  20. You  must  address  a  genuine  user  need 49
  21. You  can’t  fake  it 49
  22. We need better requirements
  23. You’re not here to build software, You’re here to change the world
  24. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 24
  25. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 25
  26. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 26
  27. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 27
  28. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 28
  29. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 29
  30. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 30
  31. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 31
  32. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 32
  33. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 33
  34. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 34
  35. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 35
  36. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 36
  37. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 37
  38. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 38
  39. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 39
  40. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on 40 Really means “Shut Up!”
  41. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on Stories  are  an  an+dote  to  “requirements” So7ware  development  has  been  steered   wrong  by  the  word  ‘requirement,’  defined  in  the   dicEonary  as  “something  mandatory  or  obligatory.”     The  word  carries  a  connotaEon  of  absoluEsm  and   permanence,  inhibitors  to  embracing  change.    And   the  word  ‘requirement’  is  just  plain  wrong. 41
  42. As a I want so that Agile  stories  are  about  the  future  world   we  imagine
  43. YES! You rock! on time? outcome your reputation You still rock - mostly...NO You suck, but I won’t tell you to your face... YES! NO You suck!
  44. Lesson: No matter what the requirements are, if the outcome is bad, we lose
  45. We need better research
  46. This  is  my  friend  Andrew
  47. This  is  his  unhappy  client
  48. They’ve  got  an  unusual  return  policy
  49. This  is  where  they  handle  returns 49 During  business  hours  the  place  is  pre'y  crowded
  50. Returns  go  here... Andrew’s CEO, Eric That’s  a  lot  of  returns,  and  it’s  criEcal  they’re   handled  effecEvely 50
  51. Lesson: You can’t get empathy from data
  52. Gemba 現場
  53. Imagine you’re Jane Goodall...
  54. 54 do this don’t do this
  55. Ninety  percent  of  life  is  just  showing  up. -­‐-­‐Woody  Allen
  56. Show  up
  57. Show  up
  58. Show  up
  59. Show  up
  60. Show  up
  61. Show  up
  62. Show  up
  63. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on Get  out  of  the  building,  way  out  of  the   building 63
  64. Jeff  Pa:on  &  Associates,,  twi:er@jeffpa:on Make  friends,  because  you  won’t  want  to   disappoint  your  friends 64
  65. Ateeq  has  an  epiphany I’ve  always  been  confident  I  can   tell  you  precisely  what  users  do.     But  it’s  not  un9l  today  that  I  realize  that  I   could  never  tell  you  why.
  66. data ≠ empathy
  67. We need a better product owner
  68. ce
  69. Marty  Cagan  describes  where  innova+on   comes  from  on  product  teams Marty  Cagan,  author  of  Inspired,  CreaEng  Products  People  Love
  70. Lesson: Product owners lead a cross functional team They help the whole team take ownership Everyone invents and innovates
  71. If we get the right people, and really work to understand our users, we’ll get it right
  72. If  you’re  really   good,  you’re  right  about  a   third  of  the  +me Your  product  decisions  are  more  likely  to   be  wrong  than  right People  like  Marty  say  this  stuff  is  hard (Marty  Cagan,  author  of  Inspired,  How  to  Create  Products  Customers  Love)   Typically  about  50%   to  80%  of  all  sobware  we   ship  fails  to  accomplish  its   objec+ves.
  73. Is  it  as  simple  as  building  only  the   features  people  will  use? It  seemed  like  a   good  idea  at  the   Eme....     “Clippy”  -­‐  Booed   off  the  Microso7   Office  stage  as   seldom-­‐used  and   o7en  despised.
  74. “There were plenty of weak spots that led to Microsoft's disastrous December quarter, but one that didn't get much attention Thursday was how badly the Zune did.” --Ina Fried, CNet News, January 2009 opportunity:   integrated  music   management  and   portable  music   player It’s  only  aber  delivery  that  we  really   understand  value
  75. We’re  probably   right  about  2  Emes  out  of  10 We’ve  got  a  lot  more  flexible   architecture  -­‐  easier  to  test  and  measure.     That’s  ow  we  know  that. Eugene  Park,  Director  of   Product  Management,
  76. Lesson: This is hard, we’re usually wrong. Plan to learn.
  77. Snag-­‐a-­‐’s  daily  standup  focuses   on  outcomes A  development  team  at  Snag-­‐A-­‐
  78. Nothing  leaves  the  board  unEl   there’s  been  a  discussion  on   what  we’ve  learned Snag-­‐a-­‐Job’s  board  courtesy  of  David  Bi'enbender Explicit  release  step Explicit  measure  step  &  metrics
  79. Thomas  Fredell,  Snag-­‐a-­‐Job’s  director  product Yeah,  we  scrapped  that. But  what  was  really  important  was  the   architecture  we  got  out  of  it.
  80. Great architecture is all about scalability and performance
  81. Snag-a-Job’s architectural journey is typical (it just has a more entertaining naming convention) Thomas  Fredell,  Snag-­‐a-­‐Job’s  director  product Our  current  placorm  allows  us   to  build  and  test  so7ware  with  users   faster  than  we  ever  could.
  82. “Engineers’ problem is they start with reuse and end up with something that’s way too complex to build simple things. Focus on: use before reuse” Bill  Sco',  PayPal
  83. optimizes its platform around testing and measurement Eugene  Park,  Director  of   Product  Management, We  built  our  CMS  with  AB   tesEng  in  mind.    We  used  to  mix  Test  and   Target  metrics  gathering  and  homegrown   metrics,  but  over  Eme  we  found  we  could   move  faster  with  our  own.
  84. Lesson: Engineer first for experimentation, then focus on scalability and performance
  85. All we need to do is build-measure-learn with simple prototypes
  86. “You can only learn so much with the highest fidelity prototypes – eventually you need to get real.” Cody  Evol,  Paypal
  87. “The difference between high fidelity and low fidelity is stupid. There’s only right fidelity and wrong fidelity.” Bill  Buxton,  author  of   Sketching  the  User   Experience
  88. Scale up prototypes to validate more. Users say they would We can see that they do Eugene  Park, Front-­‐end  developers  can   quickly  build  and  deploy  tests  without   building  the  backend. works reallooks real
  89. To experiment effectively, it takes time, money, and whole organization participation. All this, and and a culture that makes it safe to learn.
  90. Edmunds  Price  Promise  involved  product,   development,  sales,  and  marke+ng To  validate  Price   Promise   invested  months   of  Eme  and  lots  of   real  dollars  to   learn. Eugene  Park, m In  the  past  we’d  have  spent  months   researching  and  arguing.    Then  we’d  have   gambled  it  all,  or  not  tried  anything.
  91. Lesson: Progressively scale up fidelity of your experiments until you’re testing genuine outcomes
  92. We’ll find a process that really works
  93. “We had the misperception that the process, the practice, or the methods will automatically produce success. Occasionally that’s the case, but most of the time it isn’t.” -- Eugene Park, “What process helps us to do is to not fool ourselves” -- Thomas Fredell,
  94. Lesson: Stay alert Don’t fool yourself
  95. WON’T GET FOOLED AGAIN How  organiza+ons  have  evolved  to  value   learning  over  self-­‐decep+on Questions? Yes, I’m joking. I’ve learned I never leave time for questions. Please grab me in the hall. I have lots of answers. Not to YOUR questions... but still... Jeff  Pa'on jeff@jpa' twi'er:  @jeffpa'on
  96. Extra junk
  97. We need better documentation
  98. Oben  when  we  verbally  discuss  ideas,  we  may   incorrectly  believe  we  have  the  same  understanding
  99. Represen+ng  our  ideas  as  models  allows  us  to   detect  inconsistencies  in  our  understanding
  100. Through  discussion  and  itera+ve  model  building   we  arrive  at  a  stronger  shared  understanding
  101. Using  that  shared  understanding  we  can  work   together  to  arrive  at  the  same  future  world
  102. Shared  understanding  is  the  result  of   successful  collabora+ve  work
  103. Words  and  pictures  help  everyone  build   shared  understanding
  104. To  build  shared  understanding,  use  sketching   and  recording  on  walls  and  whiteboards  
  105. What  you  record  during  conversa+ons   works  like  a  vaca+on  photo Looking  at  it  helps  you  remember  details  that  aren’t  in   the  photo
  106. Scene  from  HBO’s  “The  Wire”
  107. Lesson: Shared documents aren’t shared understanding