Deliver Awesome Product Experiences

97
Deliver Awesome Product Experiences Vice President, Strategic Process Innovations, [24]7 Innovation Labs http://managewell.net http://slideshare.net/managewell http://twitter.com/tathagatvarma Tathagat Varma Sr. Member IEEE and ACM, SPC, CSP, CSPO, CSM, PMP, PRINCE2

description

My presentation to folks at Mahindra Comviva on the launch of their Product Management Council in Bangalore, Sep 26

Transcript of Deliver Awesome Product Experiences

Page 1: Deliver Awesome Product Experiences

Deliver Awesome Product Experiences

Vice President,

Strategic Process Innovations, [24]7 Innovation Labs

http://managewell.net http://slideshare.net/managewell http://twitter.com/tathagatvarma

Tathagat Varma

Sr. Member IEEE and ACM,

SPC, CSP, CSPO, CSM,

PMP, PRINCE2

Page 2: Deliver Awesome Product Experiences
Page 3: Deliver Awesome Product Experiences

How Apple does it?

Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?".

Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.”

h"p://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html    

Page 4: Deliver Awesome Product Experiences

h"p://blog.comsysto.com/2012/08/13/conAnuous-­‐delivery-­‐of-­‐waste/    

Page 5: Deliver Awesome Product Experiences

h"p://blog.comsysto.com/2012/08/13/conAnuous-­‐delivery-­‐of-­‐waste/      

Page 6: Deliver Awesome Product Experiences
Page 7: Deliver Awesome Product Experiences

In reality…

Page 8: Deliver Awesome Product Experiences
Page 9: Deliver Awesome Product Experiences

If you’re not embarrassed by your first product release, you’ve released too late – Reid Hoffman

Page 10: Deliver Awesome Product Experiences

Top 12 Product Management Mistakes

Confusing  Customer  Requirements  with  Product  Requirements  

Confusing  InnovaAon  with  Value    

Confusing  Yourself  with  Your  Customer  

Confusing  the  Customer  with  the  User  

Confusing  Features  with  Benefits    

Confusing  Building  Right  Product  with  Building  Product  Right    

Confusing  Good  Product  with  Good  Business  Model  

Confusing  Inspiring  Features  with  “Nice-­‐to-­‐Have”  Features  

Confusing  Adding  Features  with  Improving  Product    

Confusing  Impressive  SpecificaAons  with  an  Impressive  Product  

Confusing  a  Complete  Product  with  a  Sellable  Product    

Confusing  Product  Launch  with  Success  

h"p://www.khoslaventures.com/wp-­‐content/uploads/2012/02/toppmmistakes.pdf    

Page 11: Deliver Awesome Product Experiences

h"p://www.capgemini.com/technology-­‐blog/2011/06/paving-­‐path-­‐scrum-­‐adopAon-­‐product-­‐people/    

Page 12: Deliver Awesome Product Experiences

h"ps://onlineashu.wordpress.com/2012/05/18/a-­‐framework-­‐for-­‐waterfall-­‐vs-­‐agile-­‐vs-­‐lean-­‐startup/    

Page 13: Deliver Awesome Product Experiences

Getting cool ideas

Be  your  first  Customer!  

Make  a  prototype  quickly  

Be  willing  to  adapt  

h"p://www.entrepreneur.com/arAcle/226666    

Page 14: Deliver Awesome Product Experiences

h"p://www.forbes.com/sites/alanhall/2013/01/29/10-­‐simple-­‐product-­‐ideas-­‐that-­‐made-­‐billions-­‐infographic/    

Page 15: Deliver Awesome Product Experiences

Nurturing new ideas

h"p://www.innovaAons.ahrq.gov/uploadedFiles/2009-­‐11-­‐Slide12.JPG    

3M:  15%  Time    Google:  20%  Time    Atlassian:  FedEx  Days    Yahoo!:  Hackathons    P&G:  Connect  &  Develop    Facebook:  Done  is  be"er  than  perfect!  

“It  takes  a  village  to  raise  a  child”    

Page 16: Deliver Awesome Product Experiences

h"p://steveblank.files.wordpress.com/2010/11/two-­‐assumpAons.jpg    

Guaranteed  90%  Failure!!!  

Page 17: Deliver Awesome Product Experiences

Problem with traditional product development model

From:  Running  Lean  –  Ash  Maurya  The  Startup  Owners  Manual  –  Steve  Blank  

“In  large  companies,  the  mistakes  just  have  addi7onal  zeroes  in  them”  –  Steve  Blank  

Page 18: Deliver Awesome Product Experiences

9 Deadly Sins of New Product Introduction

Assuming  “I  know  what  the  customer  wants”  

The  “I  know  what  features  to  build”  flaw  

Focus  on  launch  date  

Emphasis  on  execuAon  instead  of  hypotheses,  tesAng,  learning  and  iteraAon  

TradiAon  business  plans  presume  no  trial  and  no  errors  

Confusing  tradiAonal  job  Atles  with  what  a  startup  needs  to  accomplish  

Sales  and  MarkeAng  execute  to  a  plan  

PresumpAon  of  success  leads  to  premature  scaling  

Management  by  Crisis  leads  to  “Death  Spiral”  

From:  Startup  Owner’s  Manual  

Page 19: Deliver Awesome Product Experiences

“A startup is NOT a smaller version of a large company” – Steve Blank

Page 20: Deliver Awesome Product Experiences

Are all Startups the same?

Lifestyle  Startups  

Work  to  live  their  passion  

Small  business  Startup  

Work  to  fee  the  family  

Funded  from  savings  

Barely  profitable  

Not  designed  for  scale  

Scalable  Startup  

Born  to  be  big  

Founders  have  a  vision  

Require  risk  capital  

Buyable  startup  

AcquisiAon  targets  

Social  Startup  

Driven  to  make  a  

difference  

Large-­‐company  Startup  

Innovate  or  Evaporate  

Page 21: Deliver Awesome Product Experiences

3 Stages of a startup

“Do  I  have  a  problem  worth  solving?”  

“Have  I  built  something  people  want?”  

“How  do  I  accelerate  growth?”  

From:  Running  Lean  –  Ash  Maurya  

Page 22: Deliver Awesome Product Experiences
Page 23: Deliver Awesome Product Experiences

h"p://newentrepreneurship.nl/business-­‐model-­‐canvas/    

Page 24: Deliver Awesome Product Experiences

h"p://torgronsund.com/wordpress/wp-­‐content/uploads/2011/04/Slide1.jpg    

Page 25: Deliver Awesome Product Experiences

GET OUT OF THE BUILDING…

Page 26: Deliver Awesome Product Experiences

So, what is your product?

From:  Running  Lean  –  Ash  Maurya  

Page 27: Deliver Awesome Product Experiences

The Customer Development Insight Cycle

Page 28: Deliver Awesome Product Experiences

A Pivot is a structural course correction to test a new fundamental hypothesis about the product, strategy and engine of growth. It is not a failure!

h"p://steveblank.files.wordpress.com/2010/11/pivot-­‐the-­‐model.jpg    

Page 29: Deliver Awesome Product Experiences

MVP A  strategy  used  for  fast  and  quanAtaAve  market  tesAng  of  a  product  or  product  feature      A  Minimum  Viable  Product  has  just  those  features  that  allow  the  product  to  be  deployed,  and  no  more.  The  product  is  typically  deployed  to  a  subset  of  possible  customers,  such  as  early  adopters  that  are  thought  to  be  more  forgiving,  more  likely  to  give  feedback,  and  able  to  grasp  a  product  vision  from  an  early  prototype  or  markeAng  informaAon.  It  is  a  strategy  targeted  at  avoiding  building  products  that  customers  do  not  want,  that  seeks  to  maximize  the  informaAon  learned  about  the  customer  per  dollar  spent.  "The  minimum  viable  product  is  that  version  of  a  new  product  which  allows  a  team  to  collect  the  maximum  amount  of  validated  learning  about  customers  with  the  least  effort."  The  definiAon's  use  of  the  words  maximum  and  minimum  means  it  is  decidedly  not  formulaic.  It  requires  judgment  to  figure  out,  for  any  given  context,  what  MVP  makes  sense.    An  MVP  is  not  a  minimal  product,[3]  it  is  a  strategy  and  process  directed  toward  making  and  selling  a  product  to  customers.  It  is  an  iteraAve  process  of  idea  generaAon,  prototyping,  presentaAon,  data  collecAon,  analysis  and  learning.  One  seeks  to  minimize  the  total  Ame  spent  on  an  iteraAon.  The  process  is  iterated  unAl  a  desirable  product-­‐market  fit  is  obtained,  or  unAl  the  product  is  deemed  to  be  non-­‐viable.    

Page 30: Deliver Awesome Product Experiences
Page 31: Deliver Awesome Product Experiences

Build-Measure-Learn Loop

Page 32: Deliver Awesome Product Experiences

Pivot now, Optimize later

From:  Running  Lean  –  Ash  Maurya  

Page 33: Deliver Awesome Product Experiences

Pivot

Page 34: Deliver Awesome Product Experiences

Make the transition only after you have a ‘scalable startup’

Page 35: Deliver Awesome Product Experiences

How to optimize?

From:  Running  Lean  –  Ash  Maurya  

Page 36: Deliver Awesome Product Experiences

When to raise money?

From:  Running  Lean  –  Ash  Maurya  

Page 37: Deliver Awesome Product Experiences
Page 38: Deliver Awesome Product Experiences

Product Canvas

h"p://www.romanpichler.com/blog/agile-­‐product-­‐innovaAon/the-­‐product-­‐canvas/    

Page 39: Deliver Awesome Product Experiences

Product Canvas Sections

Page 40: Deliver Awesome Product Experiences

Product Canvas

•  The Product Canvas is an alternative to a traditional, linear product backlog. It describes the product’s target group together with the needs addressed, paints a rough picture of the desired user experience (UX), and it provides the details for the next iteration. The canvas uses personas, scenarios, storyboards, design sketches, workflows, user stories, and constraint cards.

•  The Product Canvas contains the key pieces of information necessary to create a new product or product update. As its name suggests, it intends to paint a holistic picture of the product. 

Page 41: Deliver Awesome Product Experiences

From Business Model Canvas to Product Canvas

Page 42: Deliver Awesome Product Experiences

Learning and Emergence

Page 43: Deliver Awesome Product Experiences

New Product Development

Page 44: Deliver Awesome Product Experiences

h"p://www.infoq.com/resource/news/2008/01/iteraAng-­‐and-­‐incremenAng/en/resources/Pa"on_Incremental_IteraAve_MnaLisa.jpg    

Page 45: Deliver Awesome Product Experiences

h"p://itsadeliverything.com/wordpress/images//iteraAve-­‐incremental-­‐mona-­‐lisa.png    

Page 46: Deliver Awesome Product Experiences

h"p://www.targetprocess.com/blog/wp-­‐content/uploads/2009/06/agile_waterfall-­‐792810.png    

Page 47: Deliver Awesome Product Experiences

Waterfall vs. Agile

h"ps://en.wikipedia.org/wiki/File:Agile-­‐vs-­‐iteraAve-­‐flow.jpg    

Page 48: Deliver Awesome Product Experiences

Product Runways

Strategic  Vision  

Set  by  the  CEO  /  Board  and  consists  of  Strategic  DirecAon,  SoluAon  Strategy,  Technology  IniAaAves  and  Themes  Reviewed  annually  as  part  of  annual  strategic  planning  and  revised  as  needed  Serves  as  a  strategic  input  for  product  vision  

Product  Vision  

High-­‐level  overview  of  product  requirements  owned  by  respecAve  PMs    Acts  as  true  north  for  the  product  in  long  term  (2-­‐3  years)  Serves  as  the  input  for  overall  product  roadmap  in  medium  term  (1-­‐2  years)    

Product  Roadmap  

Calls  out  the  high-­‐level  themes  and  release  Ameline  in  next  1-­‐3  years  Consists  of  swimlanes  (strategic  prioriAes  vs.  lights  on,  client  requests,vs.  compeAAve  intel,  technical  debt  vs  innovaAon  ideas,,  etc.)  Reviewed  each  quarter  

Product  Backlog  

PrioriBzed  list  of  features  idenAfied  for  the  next  1-­‐3  releases  Owned  and  maintained  by  respecAve  PMs  based  on  relaAve  prioriAzaAon  of  each  feature  request    Revised  constantly  based  on  evolving  inputs  and  refined  weekly  in  grooming  sessions  with  scrum  team  

Sprint  Backlog  

Consists  of  highest-­‐priority  /  highest-­‐value  features  agreed  upon  for  development  in  the  current  sprint  (1-­‐4  weeks)  Product  Owner  responsible  to  prioriAze  the  features,  while  scrum  team  responsible  for  planning,  esAmaAon,  planning,  execuAon  and  compleAon  of  those  features  in  a  sprint  Once  the  sprint  has  started,  any  new  requirements  or  change  request  must  wait  unAl  the  next  sprint  planning    

Page 49: Deliver Awesome Product Experiences

Adaptive Planning

Prod

uct  B

acklog  

Prod

uct  R

oadm

ap  

Sprin

t  Backlog  

Prod

uct  V

ision  Futuris'c  

picture  of  the  product  Based  on  technology  evolu7on,  market  development,  industry  trends,  etc.  Reviewed  annually,  and  revised  as  needed  

High-­‐level  wish  list  of  themes  and  epics  for  a  long-­‐term  Reviewed  on  a  quarterly  basis  Typically  revised  annually  

Priori'zed  list  of  Themes,  Epics  and  User  Stories  Gets  constantly  revised  and  groomed  on  a  weekly  basis  

Well-­‐groomed  User  Stories  Can’t  be  changed  once  the  sprint  is  underway  

Current  Sprint   3-­‐6  months   12-­‐24  months   1-­‐3  years  

Small  Storie

s,    

Firm

 Req

uiremen

ts,    

Large  Stories  /

 Epics  /  The

mes,    

Fuzzy  /  Evolving  Req

uiremen

ts  

Predictable delivery of Features

Flexibility to accommodate Changes

Page 50: Deliver Awesome Product Experiences

Product Management Artifacts

IniAaA

ves    

Epics  

Them

es  

Sprin

t  Backlog  

Prod

uct  B

acklog  

Prod

uct  R

oadm

ap  

Prod

uct  V

ision

 

Tasks…

 

Stories  

Scen

arios  

Page 51: Deliver Awesome Product Experiences

Product Vision

•  Shared by All •  Desirable and Inspirational

•  Clear and Tangible

•  Broad and Engaging

•  Short and Sweet

Page 52: Deliver Awesome Product Experiences

Product Vision – Elevator Pitch

For  (target  customer)  

Who  (statement  of  the  need  or  opportunity)  

The  (product  name)  is  a  (product  category)  

That  (key  benefit,  compelling  reason  to  buy)  

Unlike  (primary  compeAAve  alternaAve)  

Our  product  (statement  of  primary  differenAaAon)  

h"p://www.joelonsovware.com/arAcles/JimHighsmithonProductVisi.html    

Page 53: Deliver Awesome Product Experiences

Product Vision Box

•  As the name suggests…

•  Describes the top 2-3 features of product

Page 54: Deliver Awesome Product Experiences

Product Roadmap

h"p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    

h"p://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png    

•  High-­‐level  plan  that  describes  how  the  product  will  evolve  

•  Refers  to  •  Product  version  •  FuncAonality  •  Release  date    

Page 55: Deliver Awesome Product Experiences

Benefits of Product Roadmap

•  Helps communicate how you see the product develop. •  Helps align the product and the company strategy. •  Helps manage the stakeholders and coordinate the

development, marketing, and sales activities. •  Facilitates effective portfolio management, as it helps

synchronise the development efforts of different products.

•  Supports and complements the product backlog. This allows the backlog to focus on the tactical product development aspects.

h"p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    

Page 56: Deliver Awesome Product Experiences

Product Backlog

Page 57: Deliver Awesome Product Experiences

Product Backlog •  The agile product backlog is a prioritized

features list, containing short descriptions of all functionality desired in the product.

•  When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements.

•  Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

•  http://www.mountaingoatsoftware.com/scrum/product-backlog

Page 58: Deliver Awesome Product Experiences

Product Backlog

•  A combined list of all desired work, including user focused stories, technical work, features & ideas

•  Everything is expressed in User Stories

•  List is prioritized by the Product Owner

•  Product Owner keeps it organized with the team’s help

•  Anyone can add items to the backlog

•  Evolves over time

•  Always in progress

Page 59: Deliver Awesome Product Experiences

….should be DEEP

•  D: Detailed Appropriately

•  E: Estimated

•  E: Emergent •  P: Prioritized

Page 60: Deliver Awesome Product Experiences

Sprint Backlog

•  User Stories selected by The Team

•  Will be built in next Sprint

•  Fully Estimated

•  Divided into Tasks

Page 61: Deliver Awesome Product Experiences

Sprint Planning

•  Happens on Day 1 of every Sprint. •  Decide what user stories will be attempted based on dependencies,

priority, resources, time •  Define what Done means for this iteration. Checked in software, tested,

documented and demonstrable. •  Team plans iteration by decomposing user stories into estimated tasks

describing the work that needs to be done to complete the story. •  Task should be in the order of 1-16 Hrs •  Everyone agrees on what to do and commits to completing the work. •  Team signs up for tasks on Sprint backlog.

Page 62: Deliver Awesome Product Experiences

Themes, Epics, User Stories and Tasks

Page 63: Deliver Awesome Product Experiences

User Story

h"p://www.leadingagile.com/wp-­‐content/uploads/2012/07/post-­‐it-­‐note-­‐user-­‐story.jpg    

h"ps://code.google.com/p/econference-­‐planning-­‐poker-­‐plugin/wiki/PlanningPoker    

Page 64: Deliver Awesome Product Experiences

As  a  frequent  flyer,    I  want  to  be  able  to  view  current  offers  in  terms  of  mileage  points    so  that  I  can  redeem  them.  

Page 65: Deliver Awesome Product Experiences

The Three C’s of a User Story

• The  story  itself  • A  promise  to  have  a  conversaAon  at  the  appropriate  Ame  

Card  

• The  requirements  themselves  communicated  from  the  Product  Owner  to  the  Delivery  Team  via  a  conversaAon  

• Write  down  what  is  agreed  upon  ConversaAon  

• The  Acceptance  Criteria  for  the  story  • How  the  Delivery  Team  will  know  they  have  completed  the  story  

ConfirmaAon  

Page 66: Deliver Awesome Product Experiences

Why not ‘PRDs’?

Page 67: Deliver Awesome Product Experiences

Why User Stories?

h"p://www.agilebuddha.com/wp-­‐content/uploads/2012/05/User-­‐Stories.jpg    

Page 68: Deliver Awesome Product Experiences

Why work with small tasks?

h"p://agilescrum.foundaAontraining.nl/img/slide-­‐horizon.jpg    

Page 69: Deliver Awesome Product Experiences

Iterative Estimation

h"p://www.sandywalsh.com/2011/04/iteraAons-­‐and-­‐Ame-­‐boxing-­‐are-­‐mostly.html    

Spiral   IteraAve  

Page 70: Deliver Awesome Product Experiences

Scenarios, User Case, User Story Use  Case:    Customer  walks  to  the  restaurant  Customer  enters  the  restaurant  Customer  finds  a  seat  at  the  bar  Customer  scans  the  menu  Customer  selects  a  beer  Customer  orders  selected  beer  Bartender  takes  order  Bartender  pours  beer  Bartender  delivers  beer  User  drinks  beer  User  pays  for  beer  

User  Story:    A  user  wants  to  find  a  bar,  to  drink  a  beer.  

h"p://www.cloudforestdesign.com/2011/04/25/introducAon-­‐user-­‐stories-­‐user-­‐personas-­‐use-­‐cases-­‐whats-­‐the-­‐difference/    

Scenario:    Josh  is  a  30  something  mid-­‐level  manager  for  an  ad  agency,  metro-­‐sexual  and  beer  aficionado.  He  likes  to  try  new  and  exoAc  beers  in  trendy  locaAons.  He  also  enjoys  using  a  variety  of  social  apps  on  his  smart  phone.  He  reads  a  review    on  Yelp  of  a  new  burger  &  beer  joint  downtown  with  over  100  beers  on  tap,  and  decides  to  go  walk  over  aver  work  and  check  it  out.      

Page 71: Deliver Awesome Product Experiences

What makes a good User Story?

Independent  of  all  others  

NegoAable  not  a  specific  contract  for  features  

Valuable  or  ver7cal  

EsAmable  to  a  good  approxima7on  

Small  so  as  to  fit  within  an  itera7on  

Testable  in  principle,  even  if  there  isn’t  a  test  for  it  yet  

h"p://guide.agilealliance.org/guide/invest.html    

Page 72: Deliver Awesome Product Experiences

Splitting User Stories

Page 73: Deliver Awesome Product Experiences

Kano Model

Page 74: Deliver Awesome Product Experiences

Minimal Marketable Feature

•  A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

•  An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete.

•  An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own.

•  A MMF can be represented as a User Story — a short, one-sentence description.

Page 75: Deliver Awesome Product Experiences

MVP, MMF, Stories

MVP  

MMFs  

User  Stories  

Page 76: Deliver Awesome Product Experiences

MoSCoW

•  M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

•  S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

•  C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

•  W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Won't" is substituted for "Would" to give a clearer understanding of this choice.

Page 77: Deliver Awesome Product Experiences

From Product Roadmap to Product Backlog

h"p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    

Page 78: Deliver Awesome Product Experiences

Who owns Product Backlog?

h"p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    

Page 79: Deliver Awesome Product Experiences

Sprint Backlog

Page 80: Deliver Awesome Product Experiences

Themes, Epics, Stories, Tasks

Page 81: Deliver Awesome Product Experiences

Design Thinking

Page 82: Deliver Awesome Product Experiences

User Personas •  In marketing and user-centered design, personas are fictional characters created to

represent the different user types within a targeted demographic, attitude and/or behavior set that might use a site, brand or product in a similar way. Marketers may use personas together with market segmentation, where the qualitative personas are constructed to be representative of specific segments. The term persona is used widely in online and technology applications as well as in advertising, where other terms such as pen portraits may also be used.

•  Personas are useful in considering the goals, desires, and limitations of brand buyers and users in order to help to guide decisions about a service, product or interaction space such as features, interactions, and visual design of a website. Personas may also be used as part of a user-centered design process for designing software and are also considered a part of interaction design (IxD), having been used in industrial design and more recently for online marketing purposes.

•  A user persona is a representation of the goals and behavior of a hypothesized group of users. In most cases, personas are synthesized from data collected from interviews with users. They are captured in 1–2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.

Page 83: Deliver Awesome Product Experiences
Page 84: Deliver Awesome Product Experiences

Rapid Iterative Testing and Evaluation (RITE)

h"p://uxmag.com/arAcles/the-­‐rite-­‐way-­‐to-­‐prototype    

Page 85: Deliver Awesome Product Experiences

Standard vs. RITE

h"p://www.slideshare.net/macieklipiec/rapid-­‐iteraAve-­‐tesAng-­‐and-­‐evaluaAon    

Page 86: Deliver Awesome Product Experiences

Product Management Spectrum

h"p://enlogica.com/uncategorized/what-­‐is-­‐a-­‐product-­‐manager/    

Page 87: Deliver Awesome Product Experiences

Too many roles?

h"p://www.romanpichler.com/blog/roles/the-­‐single-­‐product-­‐owner/    

Page 88: Deliver Awesome Product Experiences

“There can only be one”

h"p://www.romanpichler.com/blog/roles/the-­‐single-­‐product-­‐owner/    

Page 89: Deliver Awesome Product Experiences

Why?

•  Reduce hand-offs

•  Ensure continuity

•  Ownership

•  Enables long-term thinking

Page 90: Deliver Awesome Product Experiences
Page 91: Deliver Awesome Product Experiences

Product Owner The  product  owner  has  responsibility  for  deciding  what  work  will  be  done.  This  is  the  single  individual  who  is  responsible  for  bringing  forward  the  most  valuable  product  possible  by  the  desired  date.  The  product  owner  does  this  by  managing  the  flow  of  work  to  the  team,  selecAng  and  refining  items  from  the  product  backlog.  The  product  owner  maintains  the  product  backlog  and  ensures  that  everyone  knows  what  is  on  it  and  what  the  prioriAes  are.  The  product  owner  may  be  supported  by  other  individuals  but  must  be  a  single  person.  

Certainly  the  product  owner  is  not  solely  responsible  for  everything.  The  enAre  Scrum  team  is  responsible  for  being  as  producAve  as  possible,  for  improving  its  pracAces,  for  asking  the  right  quesAons,  for  helping  the  product  owner.  

Nonetheless,  the  product  owner,  in  Scrum,  is  in  a  unique  posiAon.  The  product  owner  is  typically  the  individual  closest  to  the  "business  side"  of  the  project.  The  product  owner  is  charged  by  the  organizaAon  to  "get  this  product  out"  and  is  the  person  who  is  expected  to  do  the  best  possible  job  of  saAsfying  all  the  stakeholders.  The  product  owner  does  this  by  managing  the  product  backlog  and  by  ensuring  that  the  backlog,  and  progress  against  it,  is  kept  visible.  

The  product  owner,  by  choosing  what  the  development  team  should  do  next  and  what  to  defer,  makes  the  scope-­‐versus-­‐schedule  decisions  that  should  lead  to  the  best  possible  product.  

h"p://www.scrumalliance.org/why-­‐scrum/core-­‐scrum-­‐values-­‐roles    

Page 92: Deliver Awesome Product Experiences

Traditional vs. Agile PM  Responsibility   TradiBonal   Agile  

Understand  customer  needs   Up  front  and  conAnuous   Constant  InteracAon  

Document  requirements   Fully  elaborated  in  MRD/PRD   Coarsely  documented  in  Vision  

Scheduling   Plan  one-­‐Ame  delivery  way  later   ConAnuous  near-­‐term  roadmap  

PrioriAze  requirements   Not  at  all,  or  one-­‐Ame  only  in  PRD  

ReprioriAze  every  release  and  iteraAon  

Validate  requirements   NA  –  Qa  responsibility?   Accept  every  iteraAon  and  release.  Smaller  more  frequent  releases  

Manage  change   Prohibit  change  –  weekly  CCB  meeAngs  

Adapt  and  adjust  at  every  release  and  iteraAon  boundary  

Assess  status   Milestone  document  review   See  working  code  every  iteraAon  and  every  release  

Assess  likelihood  of  release  date   Defect  trends,  or  crystal  ball,  developer  words?  

Release  dates  are  fixed.  Manage  scope  expectaAons.  

h"p://scalingsovwareagilityblog.com/responsibiliAes-­‐of-­‐agile-­‐product-­‐owner-­‐vs-­‐enterprise-­‐product-­‐manager/    

Page 93: Deliver Awesome Product Experiences
Page 94: Deliver Awesome Product Experiences
Page 95: Deliver Awesome Product Experiences

UCD + Agile

h"p://johnnyholland.org/2009/12/how-­‐ucd-­‐and-­‐agile-­‐can-­‐live-­‐together/    

h"p://www.syntagm.co.uk/design/arAcles/agilerecord_11_hudson.pdf    

h"p://boonious.typepad.com/ux2/2011/03/agile-­‐user-­‐interface-­‐development.html    

Page 96: Deliver Awesome Product Experiences
Page 97: Deliver Awesome Product Experiences

Recap

•  Think BIG!

•  Deliver Small

•  Iterate

•  Learn

•  Refine