Co-making Great Products

40 %
60 %
Information about Co-making Great Products

Published on February 23, 2014

Author: comakers



“Mediocrity guaranteed.” This sad tagline describes most of the processes we use today including typical agile process. It’s easy to see why. Software development’s an expensive risky business. To deal with the risk, the players involved adopt a client-vendor model where those in the client role give requirements and those in the vendor role estimate time and effort and agree to build what’s asked for. In this model we clearly separate responsibilities so that we know who’s accountable when things go wrong. Although we know things rarely go as planned, and innovative ideas rarely spring from such a relationship, we continue to work in processes where treating our coworkers as outsourced vendors is considered “best practice” and risking everything on the ideas of a select few isn’t regarded as risky.
This talk is about an alternative way of working.
In this talk Jeff explores companies beginning to adopt a style of working where everyone in the organization gets involved with identifying and solving problems. You’ll hear examples from real companies describing their practices for learning first-hand about customers and users, practices for collaboratively designing solutions for the problems found in the real world, and approaches to learning if what we created really benefited anyone. This new style of work is a process cocktail combining the best of agile development, lean software development and lean startup, user-centered design, and collaborative design thinking.
This style of work isn’t the traditional client-vendor model where knowing who’s to blame is the primary concern. It’s a co-making style of work where everyone brings their skills and experience to the table and together takes ownership for making great things.

Co-Making Great Products How whole teams work together to find problems, invent solutions, and deliver great products Jeff Patton twitter: @jeffpatton

This  team  has  delivered  high  quality  working  so?ware   every  sprint But,  they’re  frustrated  because  they’re  failing,  Jeff  Pa3on,   2

This team thinks about success differently 3

s 1. Safety isn’t success 2. Velocity isn’t value 3. The invention game 4. Deliberate discovery drives delivery 5. Reality bites 4

These three companies are focused on winning the software development game 5

1 Safety isn’t success 6

Our  everyday  process  requires   so  much  rigor,  there  wasn’t  really  a   place  for  innova0on JB  Brown Nordstrom  Innova0on  Lab 7

Traditional sequential development process is safe for individuals 8





Separation of concerns is problematic for process 13



2 Velocity isn’t value 16

We’re  great  at  delivering   soFware  using  agile  approaches.     We’ve  just  realized  it  doesn’t  maIer. Eugene  Park 17

We’re not here to build software we’re here to change the world 18

R&D [requirements & design] 20

Deciding  what  to  build  is  difficult The hardest single part of building a software system is deciding precisely what to build. Fred  Brooks,  author  of  The  Mythical  Man  Month,  Jeff  Pa3on,   21

Our  decisions  become   requirements If it’s your decision to make, it’s design. If not, it’s a requirement. Alistair  Cockburn,  author  of  Agile  So?ware  Development:  The  CooperaVve  Game,  Jeff  Pa3on,   22

South  Park  clip,  the  underpants  business:   hIp://

3 The invention game 26

Process 27

“Under the rugby approach, the product development process emerges from the constant interaction of a handpicked, multidisciplinary team whose members work together from start to finish.” From the 1986 Harvard Business Review paper “The New New Product Development Game” by Takeuchi and Nonaka 7

Game 29

Process ≠ Skill knowing how doesn’t make you good Roles ≠ Positions You might primarily do one thing, but you can’t win by doing only one thing Finishing On Time ≠ Winning Keep score, don’t just keep time 30

“Design Thinking” is a learning and invention game 31

It seems like common sense Understand the There problem you’re solving is nothing & focus on specific more uncommon problems than common sense. Consider lots of possible solutions Make sure it’ll work before investing big Sco$sh  Mathema-cian   Thomas  Chalmers 32

Different ways of thinking NOT process roles, hand-offs, sequence and phases,  Jeff  Pa3on,   33

Study the world now, imagine and test the a new future world Later Now,  Jeff  Pa3on,   34

Learning happens outside the building Later Now,  Jeff  Pa3on,   35

UX  Designers  act  as  experts  and  guides “Design isn’t a product that designers produce, design is a process that designers facilitate.” -- Leah Buley Leah  Buley,  Jeff  Pa3on,   36



Share understanding, not documents 39

O?en  when  we  verbally  discuss  ideas,  we  may   incorrectly  believe  we  have  the  same  understanding,  Jeff  Pa3on,   40

RepresenVng  our  ideas  as  models  allows  us  to   detect  inconsistencies  in  our  understanding,  Jeff  Pa3on,   41

Through  discussion  and  iteraVve  model  building   we  arrive  at  a  stronger  shared  understanding,  Jeff  Pa3on,   42

Using  that  shared  understanding  we  can  work   together  to  arrive  at  the  same  future  world,  Jeff  Pa3on,   43

Shared  understanding  is  the  result  of   successful  collaboraVve  work,  Jeff  Pa3on,   44

Words  and  pictures  help  everyone  build   shared  understanding,  Jeff  Pa3on,   45

GameStorming is a good manual for effective collaborative work Having a business meeting without artifacts and meaningful space is like meeting blindfolded with your hands behind your back. Yes, you can do it, but why would you want to? 46

Shared  understanding  takes  space “Make  Space”  is  the  term   coined  by  the  Stanford  Design   School  to  describe  effecVve   collaboraVve  workspace Space  to  model  and  draw: § Walls  and  whiteboards   § Tabletops Flexible  discussion  &  seaVng   space Places  to  store  the  arVfacts   created  during  discovery  work,  Jeff  Pa3on,   47

Shared  understanding  takes  space “Make  Space”  is  the  term   coined  by  the  Stanford  Design   School  to  describe  effecVve   collaboraVve  workspace Space  to  model  and  draw: § Walls  and  whiteboards   § Tabletops Flexible  discussion  &  seaVng   space Places  to  store  the  arVfacts   created  during  discovery  work,  Jeff  Pa3on,   A  large  work  area  in  the   Stanford  supports   many  small  design  teams. 48

Virtual Make-Space? 49

4 Deliberate discovery drives delivery 50

Discovery  compliments  delivery Discovery Use  discovery  to  answer   big  quesVons • What  problems   are  we  solving? • What  solu0on  do   people  want? • Can  people   effec0vely  use   our  solu0on? • Can  we  build  it  in   the  0me  we  have?,  Jeff  Pa3on,   Delivery Use  delivery   to  execute • Plan  the  details • Design,  develop,     and  test • Measure   development  speed • Evaluate  progress • Evaluate  quality 51

Morale  suffers  when   all  we  do  is  build  soFware.      The  thrill  of  building   something  fast,  measuring  it  well,   and  deba0ng  the  results  and  planning   next  steps  make  the  whole  effort   worthwhile. Tom  Illmensee 52

As  you  walk  up  the  stairs  at  Snag-­‐a-­‐job,  you’ll   see  the  first  evidence  of  company  values ©  2009-­‐2011  Jeff  Pa3on,  all  rights  reserved, 53

Head  down  the  stairs  and  you’ll  get  an  informal   reminder  of  the  importance  of  users  of  the   company’s  product Caring  about  their  users  is  part  of  their  DNA ©  2009-­‐2011  Jeff  Pa3on,  all  rights  reserved, 54

Discovery teams build shared understanding of: • the present problems • the future world • the solutions we think will get us there 55

Discuss  and  model  to  build  shared   understanding  of  the  current  and  future  world Gary Levitt, owner & designer of Mad Mimi,  Jeff  Pa3on,   56

Story  Maps  help  us  build  shared   understanding  about  the  future  world product goals (why build the product) users (what are their goals) work (fro m th flow e pers u pect ser’s ive) Gary Levitt, owner & designer of Mad Mimi,  Jeff  Pa3on,   backbone (g ives stru cture to the map) details • smaller s • alternativ teps • UI detai e steps • technica ls l detail s 57

Simple  lightweight  pragmaVc  personas   build  shared  understanding  about  users,  Jeff  Pa3on,   58

Building  them  together  helps  us  learn   what  we  don’t  know 59,  Jeff  Pa3on,  

Sharing  and  talking  about  them  with   whole  teams  builds  shared  understanding,  Jeff  Pa3on,   60

You’ll  need  face  Vme  with  real  people  to   understand,  Jeff  Pa3on,   61

You’ll  need  to  leave  your  office  and  visit   theirs,  Jeff  Pa3on,   62

Go  where  the  people  you’re  helping  work,  Jeff  Pa3on,   63

Go  where  the  people  you’re  helping  work,  Jeff  Pa3on,   64

Go  where  the  people  you’re  helping  work,  Jeff  Pa3on,   65

Go  where  the  people  you’re  helping  work,  Jeff  Pa3on,   66

Go  where  the  people  you’re  helping  work,  Jeff  Pa3on,   67

Map  what  you  learned  to  build  shared   understanding  of  today’s  world *  NarraVve  Journey  Map   courtesy  Duncan  Brown   of  the  Caplin  Group,  Jeff  Pa3on,   68

Journey  maps  describe  today’s  world *  NarraVve  Journey  Map   courtesy  Duncan  Brown   of  the  Caplin  Group,  Jeff  Pa3on,   69

Building  a  map  together  helps  us  explore   the  whole  product,  Jeff  Pa3on,   70

Talking  with  end  users  over  a  story  map   drives  discussion  they  can  engage  in,  Jeff  Pa3on,   71

Story  maps  put  problems  and  soluVons   into  context,  Jeff  Pa3on,   72

Words  aren’t  enough,  Jeff  Pa3on,   73

Everyone  parVcipates  in  sketching   soluVon  idea,  Jeff  Pa3on,   74

Take  a  li3le  quiet  Vme  and  sketch   independently,  Jeff  Pa3on,   75

Share  back  ideas  with  the  everyone,  Jeff  Pa3on,   76

Words  and  pictures  help  everyone  build   shared  understanding,  Jeff  Pa3on,   77  doesn’t  stop  with  words,  Jeff  Pa3on,   78

Use  storyboards  to  imagine  user   experience  “later” Snag-­‐a-­‐Job  lo-­‐fi   storyboard,  Jeff  Pa3on,   79

Don’t  just  imagine  experience,  test  it,  Jeff  Pa3on,   80

Tell  your  product’s  story  over  and  over,  Jeff  Pa3on,   81

Edmunds  shares  the  product’s  story  for   all  teams  in  an  internal  “trade  show”,  Jeff  Pa3on,   82

Edmunds  shares  the  product’s  story  for   all  teams  in  an  internal  “trade  show”,  Jeff  Pa3on,   83

Edmunds  shares  the  product’s  story  for   all  teams  in  an  internal  “trade  show”,  Jeff  Pa3on,   84

Edmunds  shares  the  product’s  story  for   all  teams  in  an  internal  “trade  show”,  Jeff  Pa3on,   85

Explicit  release  step Explicit  measure  step  &  metrics Nothing  leaves  the  board  un0l   there’s  been  a  discussion  on   what  we’ve  learned Snag-­‐a-­‐Job’s  board  courtesy  of  David  BiIenbender 92

Nordstrom  InnovaVon  Lab’s  Learning  Loop hIp://­‐study-­‐nordstrom-­‐innova0on-­‐lab.html,  Jeff  Pa3on,   93

Nordstrom  InnovaVon  Lab’s  Learning  Loop hIp://­‐study-­‐nordstrom-­‐innova0on-­‐lab.html,  Jeff  Pa3on,   94

Nordstrom  InnovaVon  Lab’s  Learning  Loop hIp://­‐study-­‐nordstrom-­‐innova0on-­‐lab.html,  Jeff  Pa3on,   95

Nordstrom  InnovaVon  Lab’s  Learning  Loop hIp://­‐study-­‐nordstrom-­‐innova0on-­‐lab.html,  Jeff  Pa3on,   96

5 Reality bites 97

Your  guesses  about  the  future  are   probably  wrong Typically  about   50%  to  80%  of  all   so?ware  we  ship  fails  to   accomplish  it’s   objecVves. People  like  Marty  say  this  stuff  is  hard (Marty  Cagan,  author  of  Inspired,  How  to  Create  Products  Customers  Love),  Jeff  Pa3on,   98

We’re  probably   right  about  2  0mes  out  of  10 99

Is  it  as  simple  as  building  only  the   features  people  will  use? “Clippy”  -­‐  Booed   off  the  MicrosoF   Office  stage  as   seldom-­‐used  and   oFen  despised. It  seemed  like  a   good  idea  at  the   0me....,  Jeff  Pa3on,   100

It’s  only  a?er  delivery  that  we  really   understand  value opportunity:   integrated  music   management  and   portable  music   player “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,  Jeff  Pa3on,   101

If you think writing code is hard, try making product decisions 102

Scene  from  The  Matrix  ©  1999  Warner  Bros  Pictures 103

Everyone’s  focused  on  winning  now  Snag-­‐ a-­‐Job  can  actually  keep  score,  Jeff  Pa3on,   104

Snagajob’s been trying to crack the same tough problem for close to a year now Most of Nordstrom’s weekly experiments don’t result in rolling out a new product has built, tried, and thrown away dozens of ideas 105

Everyone’s   working  directly  with  our   clients  now What  we’re  doing   really  maIers When  there’s   We’ve  found   simple  ideas  that  now   problems,  teams  dig  in,  and   generate  millions  in   figure  out  a  schedule  to  stay  and   solve  problems.    No  one  asks   revenue  every  year them  to. People  are  just   happier What team members say is telling The  new  site   generates  the  same  revenue   with  a  frac0on  of  the  features   and  code  -­‐  and  our  customers   like  it  beIer 106

“It’s not easy. We’ve got lots of problems. But there’s no going back.” 107

Co-Making Great Products How whole teams work together to find problems, invent solutions, and deliver great products Questions? Jeff Patton twitter: @jeffpatton

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...