Date post: | 08-May-2015 |
Category: |
Business |
Upload: | tathagat-varma |
View: | 16,620 times |
Download: | 6 times |
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
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
h"p://blog.comsysto.com/2012/08/13/conAnuous-‐delivery-‐of-‐waste/
h"p://blog.comsysto.com/2012/08/13/conAnuous-‐delivery-‐of-‐waste/
In reality…
If you’re not embarrassed by your first product release, you’ve released too late – Reid Hoffman
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
h"p://www.capgemini.com/technology-‐blog/2011/06/paving-‐path-‐scrum-‐adopAon-‐product-‐people/
h"ps://onlineashu.wordpress.com/2012/05/18/a-‐framework-‐for-‐waterfall-‐vs-‐agile-‐vs-‐lean-‐startup/
Getting cool ideas
Be your first Customer!
Make a prototype quickly
Be willing to adapt
h"p://www.entrepreneur.com/arAcle/226666
h"p://www.forbes.com/sites/alanhall/2013/01/29/10-‐simple-‐product-‐ideas-‐that-‐made-‐billions-‐infographic/
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”
h"p://steveblank.files.wordpress.com/2010/11/two-‐assumpAons.jpg
Guaranteed 90% Failure!!!
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
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
“A startup is NOT a smaller version of a large company” – Steve Blank
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
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
h"p://newentrepreneurship.nl/business-‐model-‐canvas/
h"p://torgronsund.com/wordpress/wp-‐content/uploads/2011/04/Slide1.jpg
GET OUT OF THE BUILDING…
So, what is your product?
From: Running Lean – Ash Maurya
The Customer Development Insight Cycle
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
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.
Build-Measure-Learn Loop
Pivot now, Optimize later
From: Running Lean – Ash Maurya
Pivot
Make the transition only after you have a ‘scalable startup’
How to optimize?
From: Running Lean – Ash Maurya
When to raise money?
From: Running Lean – Ash Maurya
Product Canvas
h"p://www.romanpichler.com/blog/agile-‐product-‐innovaAon/the-‐product-‐canvas/
Product Canvas Sections
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.
From Business Model Canvas to Product Canvas
Learning and Emergence
New Product Development
h"p://www.infoq.com/resource/news/2008/01/iteraAng-‐and-‐incremenAng/en/resources/Pa"on_Incremental_IteraAve_MnaLisa.jpg
h"p://itsadeliverything.com/wordpress/images//iteraAve-‐incremental-‐mona-‐lisa.png
h"p://www.targetprocess.com/blog/wp-‐content/uploads/2009/06/agile_waterfall-‐792810.png
Waterfall vs. Agile
h"ps://en.wikipedia.org/wiki/File:Agile-‐vs-‐iteraAve-‐flow.jpg
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
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
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
Product Vision
• Shared by All • Desirable and Inspirational
• Clear and Tangible
• Broad and Engaging
• Short and Sweet
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
Product Vision Box
• As the name suggests…
• Describes the top 2-3 features of product
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
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/
Product Backlog
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
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
….should be DEEP
• D: Detailed Appropriately
• E: Estimated
• E: Emergent • P: Prioritized
Sprint Backlog
• User Stories selected by The Team
• Will be built in next Sprint
• Fully Estimated
• Divided into Tasks
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.
Themes, Epics, User Stories and Tasks
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
As a frequent flyer, I want to be able to view current offers in terms of mileage points so that I can redeem them.
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
Why not ‘PRDs’?
Why User Stories?
h"p://www.agilebuddha.com/wp-‐content/uploads/2012/05/User-‐Stories.jpg
Why work with small tasks?
h"p://agilescrum.foundaAontraining.nl/img/slide-‐horizon.jpg
Iterative Estimation
h"p://www.sandywalsh.com/2011/04/iteraAons-‐and-‐Ame-‐boxing-‐are-‐mostly.html
Spiral IteraAve
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.
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
Splitting User Stories
Kano Model
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.
MVP, MMF, Stories
MVP
MMFs
User Stories
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.
From Product Roadmap to Product Backlog
h"p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
Who owns Product Backlog?
h"p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
Sprint Backlog
Themes, Epics, Stories, Tasks
Design Thinking
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.
Rapid Iterative Testing and Evaluation (RITE)
h"p://uxmag.com/arAcles/the-‐rite-‐way-‐to-‐prototype
Standard vs. RITE
h"p://www.slideshare.net/macieklipiec/rapid-‐iteraAve-‐tesAng-‐and-‐evaluaAon
Product Management Spectrum
h"p://enlogica.com/uncategorized/what-‐is-‐a-‐product-‐manager/
Too many roles?
h"p://www.romanpichler.com/blog/roles/the-‐single-‐product-‐owner/
“There can only be one”
h"p://www.romanpichler.com/blog/roles/the-‐single-‐product-‐owner/
Why?
• Reduce hand-offs
• Ensure continuity
• Ownership
• Enables long-term thinking
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
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/
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
Recap
• Think BIG!
• Deliver Small
• Iterate
• Learn
• Refine