SUCCESSFUL PRODUCT MANAGEMENT

MUNEEB ALI
INTRODUCTION
Agile Coach / Director Product Delivery @ Click Chain

Agile Enthusiast

Over 5 years expertise working with multiple teams

and products using Agile/Scrum.

Certified Scrum Master

Certified Scrum Product Owner

Certified Scrum Professional

2
Agenda
Who is the Product Owner?

Planning and Estimating the product road map

How to build a Minimum Viable Product?

3

Improve productivity through self organized & motivated teams

Manage Technical Debt

Release Management
4
Product Owner: The guardian of the product

Single point of authority

Empowered product owner

5
Key to achieve truly great Scrum

PO key to achieve hyper-performance

Product Owner: Characteristics
Understands the market, customers and users

Has good relationship with stakeholders

Empowered to make decisions, is decisive, is willing to say no

6 Accepts accountability

A leader who is respected by the team

An individual, not a committee

Typically works with one team, maybe two

7
Agile Principle # 04

Business people and developers must work

8
together daily throughout the project.
9
Product Vision
Every Product starts with an idea/vision.

The vision should communicate the essence

of the future product in a concise manner and
describe a shared goal that provides direction
10
but is broad enough to facilitate creativity.

Its important to align scrum team with

the vision to foster self organization.
Product Vision
Most successful products have a

clear and simple value proposition.

11
Buyers typically make their choice

between competing products on the

basis of three or four key factors.

Creating a Charter: Recommended Syntax
For (customer)

Who (statement of need or opportunity)

12
The (product name) is a (product category)

That (key benefit, compelling reason to buy).

Unlike (primary competitor)

Our product (statement of primary differentiation).

 APPLE iPod Vision
For music lovers

Who want their music on the go

The iPod is an MP3 Player

13
That offers intuitive playback functionality

Unlike Sandisk Sansa

Our product is easy to use and synchs with our

integrated music library iTunes
User Personas
User Centric Design

Identify all the types of users roles that are going to use the software.

Identify what and how they use the software for

14

Collaborative process helps deeper understanding of product vision

Multi-level Planning

15
Release Planning: What is Business Value
Our inability to define the true value in real monetary terms drives poor
decisions about what to build and when to build it.

Value is based on product vision and market knowledge.

Types of features:
16
Must have commodities

Differentiators

Spoilers

Cost Reducers
Story Mapping
Mapping the stories allow for teams to look at
bigger picture.

It helps prioritize with entire context of the system.

17
It helps effectively explain the system, prioritize and
plan your releases.
18
Agile Principle # 10

Simplicity--the art of maximizing the amount

19
of work not done--is essential.
Minimum Viable Product

20
Grooming Activities

21
Grooming Activities

22
 Sequential vs Overlapping Development
Requirements Design Code Test

Rather than doing all of

one thing at a time...
...Scrum teams do a little
of everything all the time
Potential Shippable Product
High quality, complete, done, what it
does it does well

Its a state of confidence

24
Potentially shippable shippable

Shipping is a business decision

Scrum Communication Model

25
Agile Principle # 11

The best architectures, requirements, and designs

26
emerge from self-organizing teams.
Definition of Ready & Done

27
Definition of Ready
Story estimated at 13 story points or less

Story written in user story format

Story has at least the happy path test case written

28
Story has a business value estimate

Story has an initial UI sketch mockup

Constraints on story indicated

Definition of Done
Minimum 90% unit test coverage

All acceptance criteria are met and verified

Code review has been performed

29
User acceptance testing has been done.

Test cases have been automated.

Community of
Practices

30
Manage Technical Debt
Going into debt is a conscious decision and not an accident.

Cost of debt (interest) that needs to be repaid.

Debt due to poor design decisions.

31

Debt due to the undone work end of each sprint.

Debt due to compromised solution.

Avoid Technical Debt
Use good technical practices:

Pair Programming, Test Driven Development, Refactoring, Test Automation, Continuous

Integration, Simple Design, Collective code ownership

Strong
32 Definition of done

Make technical debt visible in product backlog

Servicing Technical Debt
Not all technical debt should be repaid

Apply the Boy Scout rule (service debt when you

happen upon it)
33
Repay high-interest technical debt rst

Repay technical debt incrementally

Repay technical debt while performing customer-

valuable work
Release Management
When can we ship these features ?

How much can I get by June ?

How much will this cost ?

Plan
34 must be accurate but get precise over time.

We will be done between April and June.

Stakeholders
Well be done sometime in May.

Well be done on May 15.

Velocity

35
Ranges
For a fixed-date project, use a scope range:

By that date youll have all of these features and some of

those.
36
For a fixed-scope project, use a date range:

It will take us between this and that number of sprints to

deliver all of those features.
Thank You !

37