1. 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
2.
3. 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
9. If you’re not embarrassed by your first product release,
you’ve released too late – Reid Hoffman
10. 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
17. 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
18. 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
19. “A startup is NOT a smaller version of a
large company” – Steve Blank
20. 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
21. 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
28. 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
29. 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.
40. 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.
48. 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
49. 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
51. Product Vision
• Shared by All
• Desirable and Inspirational
• Clear and Tangible
• Broad and Engaging
• Short and Sweet
52. 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
53. Product Vision Box
• As the name
suggests…
• Describes the top
2-3 features of
product
55. 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/
57. 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
58. 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
59. ….should be DEEP
• D: Detailed Appropriately
• E: Estimated
• E: Emergent
• P: Prioritized
60. Sprint Backlog
• User Stories selected
by The Team
• Will be built in next
Sprint
• Fully Estimated
• Divided into Tasks
61. 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.
64. As
a
frequent
flyer,
I
want
to
be
able
to
view
current
offers
in
terms
of
mileage
points
so
that
I
can
redeem
them.
65. 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
70. 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.
71. 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
74. 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.
76. 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.
77. From Product Roadmap to Product
Backlog
h"p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
78. Who owns Product Backlog?
h"p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
82. 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.
83.
84. Rapid Iterative Testing and Evaluation
(RITE)
h"p://uxmag.com/arAcles/the-‐rite-‐way-‐to-‐prototype
91. 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
92. 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/