Deliver Awesome Product Experiences Vice
President, Strategic Process Innovations, 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
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 Beneﬁts 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 SpeciﬁcaAons 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
9 Deadly Sins of New
Product Introduction Assuming “I know what the customer wants” The “I know what features to build” ﬂaw 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
Are all Startups the same?
Lifestyle Startups Work to live their passion Small business Startup Work to fee the family Funded from savings Barely proﬁtable 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 diﬀerence 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
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.ﬁles.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 eﬀort." The deﬁniAon's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to ﬁgure out, for any given context, what MVP makes sense. An MVP is not a minimal product, 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 ﬁt is obtained, or unAl the product is deemed to be non-‐viable.
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, workﬂows, 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.
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 idenAﬁed 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 reﬁned 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 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
Product Vision – Elevator Pitch
For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key beneﬁt, compelling reason to buy) Unlike (primary compeAAve alternaAve) Our product (statement of primary diﬀerenAaAon) h"p://www.joelonsovware.com/arAcles/JimHighsmithonProductVisi.html
Beneﬁts 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 • 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 ﬁrst 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
Sprint Planning • Happens on
Day 1 of every Sprint. • Decide what user stories will be attempted based on dependencies, priority, resources, time • Deﬁne 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.
As a frequent ﬂyer,
I want to be able to view current oﬀers 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 ConﬁrmaAon
Scenarios, User Case, User Story
Use Case: Customer walks to the restaurant Customer enters the restaurant Customer ﬁnds 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 ﬁnd a bar, to drink a beer. h"p://www.cloudforestdesign.com/2011/04/25/introducAon-‐user-‐stories-‐user-‐personas-‐use-‐cases-‐whats-‐the-‐diﬀerence/ Scenario: Josh is a 30 something mid-‐level manager for an ad agency, metro-‐sexual and beer aﬁcionado. 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 speciﬁc contract for features Valuable or ver7cal EsAmable to a good approxima7on Small so as to ﬁt within an itera7on Testable in principle, even if there isn’t a test for it yet h"p://guide.agilealliance.org/guide/invest.html
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.
MoSCoW • M - MUST: Describes
a requirement that must be satisﬁed in the ﬁnal 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 satisﬁed 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.
User Personas • In marketing and user-centered design, personas are
ﬁctional 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 speciﬁc 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 ﬁctional 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.
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 ﬂow of work to the team, selecAng and reﬁning 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 ﬁxed. Manage scope expectaAons. h"p://scalingsovwareagilityblog.com/responsibiliAes-‐of-‐agile-‐product-‐owner-‐vs-‐enterprise-‐product-‐manager/