Deliver Awesome Product Experiences


Published on

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

Published in: Business, Technology
1 Comment
  • 'If you are a website owner then let’s face it – all you need is a best quality references from the pages which contain the most ethical and helpful information of your industry. Yes Search engines love link from the pages which contains quality content and I'll providing the best quality links pointing towards your site. Article submission service is the best to way to generate more and more references which boost your search engine ranking and provide you the unlimited opportunities to mark new sales as it drive the maximum potential costumers towards your site. Articles are the most lethal tool for website promotion, as an ethical campaign it can have extraordinary long term effect in sales. Effective article marketing is an investment in your business!'
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Deliver Awesome Product Experiences

  1. Deliver Awesome Product Experiences Vice President, Strategic Process Innovations, [24]7 Innovation Labs Tathagat Varma Sr. Member IEEE and ACM, SPC, CSP, CSPO, CSM, PMP, PRINCE2
  2. 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://    
  3. h"p://­‐delivery-­‐of-­‐waste/    
  4. h"p://­‐delivery-­‐of-­‐waste/      
  5. In reality…
  6. If you’re not embarrassed by your first product release, you’ve released too late – Reid Hoffman
  7. 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://­‐content/uploads/2012/02/toppmmistakes.pdf    
  8. h"p://­‐blog/2011/06/paving-­‐path-­‐scrum-­‐adopAon-­‐product-­‐people/    
  9. h"ps://­‐framework-­‐for-­‐waterfall-­‐vs-­‐agile-­‐vs-­‐lean-­‐startup/    
  10. Getting cool ideas Be  your  first   Customer!   Make  a   prototype   quickly   Be  willing  to   adapt   h"p://    
  11. h"p://­‐simple-­‐ product-­‐ideas-­‐that-­‐made-­‐billions-­‐infographic/    
  12. Nurturing new ideas h"p://­‐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”    
  13. h"p://­‐assumpAons.jpg     Guaranteed  90%  Failure!!!  
  14. 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  
  15. 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  
  16. “A startup is NOT a smaller version of a large company” – Steve Blank
  17. 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  
  18. 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  
  19. h"p://­‐model-­‐canvas/    
  20. h"p://­‐content/uploads/2011/04/Slide1.jpg    
  22. So, what is your product? From:  Running  Lean  –  Ash  Maurya  
  23. The Customer Development Insight Cycle
  24. 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://­‐the-­‐model.jpg    
  25. 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.    
  26. Build-Measure- Learn Loop
  27. Pivot now, Optimize later From:  Running  Lean  –  Ash  Maurya  
  28. Pivot
  29. Make the transition only after you have a ‘scalable startup’
  30. How to optimize? From:  Running  Lean  –  Ash  Maurya  
  31. When to raise money? From:  Running  Lean  –  Ash  Maurya  
  32. Product Canvas h"p://­‐product-­‐innovaAon/the-­‐product-­‐canvas/    
  33. Product Canvas Sections
  34. 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. 
  35. From Business Model Canvas to Product Canvas
  36. Learning and Emergence
  37. New Product Development
  38. h"p://­‐and-­‐incremenAng/en/resources/Pa"on_Incremental_IteraAve_MnaLisa.jpg    
  39. h"p://­‐incremental-­‐mona-­‐lisa.png    
  40. h"p://­‐content/uploads/2009/06/agile_waterfall-­‐792810.png    
  41. Waterfall vs.Agile h"ps://­‐vs-­‐iteraAve-­‐flow.jpg    
  42. 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    
  43. Adaptive Planning Product  Backlog   Product  Roadmap   Sprint  Backlog   Product  Vision   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  Stories,     Firm  Requirements,     Large  Stories  /  Epics  /  Themes,     Fuzzy  /  Evolving  Requirements   Predictable delivery of Features FlexibilitytoaccommodateChanges
  44. Product Management Artifacts IniAaAves     Epics   Themes   Sprint  Backlog   Product  Backlog   Product  Roadmap   Product  Vision   Tasks…   Stories   Scenarios  
  45. Product Vision •  Shared by All •  Desirable and Inspirational •  Clear and Tangible •  Broad and Engaging •  Short and Sweet
  46. 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://    
  47. Product Vision Box •  As the name suggests… •  Describes the top 2-3 features of product
  48. Product Roadmap h"p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/     h"p://     •  High-­‐level  plan  that   describes  how  the   product  will  evolve   •  Refers  to   •  Product  version   •  FuncAonality   •  Release  date    
  49. 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://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  50. Product Backlog
  51. 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. • scrum/product-backlog
  52. 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
  53. ….should be DEEP •  D: Detailed Appropriately •  E: Estimated •  E: Emergent •  P: Prioritized
  54. Sprint Backlog •  User Stories selected by The Team •  Will be built in next Sprint •  Fully Estimated •  Divided into Tasks
  55. 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.
  56. Themes, Epics, User Stories and Tasks
  57. User Story h"p://­‐content/uploads/2012/07/post-­‐it-­‐note-­‐user-­‐story.jpg     h"ps://­‐planning-­‐poker-­‐plugin/wiki/PlanningPoker    
  58. As  a  frequent  flyer,     I  want  to  be  able  to  view  current   offers  in  terms  of  mileage  points     so  that  I  can  redeem  them.  
  59. 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  
  60. Why not ‘PRDs’?
  61. Why User Stories? h"p://­‐content/uploads/2012/05/User-­‐Stories.jpg    
  62. Why work with small tasks? h"p://­‐horizon.jpg    
  63. Iterative Estimation h"p://­‐and-­‐Ame-­‐boxing-­‐are-­‐mostly.html     Spiral   IteraAve  
  64. 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://­‐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.      
  65. 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://    
  66. Splitting User Stories
  67. Kano Model
  68. 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.
  69. MVP, MMF, Stories MVP   MMFs   User  Stories  
  70. 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.
  71. From Product Roadmap to Product Backlog h"p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  72. Who owns Product Backlog? h"p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  73. Sprint Backlog
  74. Themes, Epics, Stories,Tasks
  75. Design Thinking
  76. 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.
  77. Rapid Iterative Testing and Evaluation (RITE) h"p://­‐rite-­‐way-­‐to-­‐prototype    
  78. Standard vs. RITE h"p://­‐iteraAve-­‐tesAng-­‐and-­‐evaluaAon    
  79. Product Management Spectrum h"p://­‐is-­‐a-­‐product-­‐manager/    
  80. Too many roles? h"p://­‐single-­‐product-­‐owner/    
  81. “There can only be one” h"p://­‐single-­‐product-­‐owner/    
  82. Why? •  Reduce hand-offs •  Ensure continuity •  Ownership •  Enables long-term thinking
  83. 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://­‐scrum/core-­‐scrum-­‐values-­‐roles    
  84. 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://­‐of-­‐agile-­‐product-­‐owner-­‐vs-­‐enterprise-­‐product-­‐manager/    
  85. UCD + Agile h"p://­‐ucd-­‐and-­‐agile-­‐can-­‐live-­‐together/     h"p://     h"p://­‐user-­‐interface-­‐development.html    
  86. Recap •  Think BIG! •  Deliver Small •  Iterate •  Learn •  Refine