Practical Product Management for new Product Managers

Practical Product Management for new PMs

Amarpreet KalkatCo-founder & Chief Technologist @ Ciafo

Agenda• Session 1: Introduction

– Usefulness of Product Management function– Key aspects of Product Management– Walk through of the Case Study

• Session 2: Learning the Key Concepts– Working with the stakeholders– Planning a strategic roadmap– Building a backlog– Feature prioritization– Planning a release roadmap– Defining the product requirements

• Session 3: Product Experience– UI, Usability and UX– Measurement of impact

• Session 4: Case Study Analysis– Comprehensive analysis of the Case Study

Session 1

Introduction

Usefulness of PM Function

Understanding an end-user’s pain points, and solving them through the product features.

Balancing out the usually conflicting product expectations of stakeholders.

Creating a ‘State Path’, with each state being a local business value maxima.

Maximizing the overall business value, given the constraints.

Getting buy-in, and creating an in-house (and sometimes outside) market for the product.

Key Aspects of PM Function

Working with the stakeholders

Planning a strategic roadmap

Building the backlog

Defining the product requirements

Planning a release roadmap

Feature prioritization

Session 2

Learning the Key Concepts








Know Your Stakeholders

Any person who has a professional interest or say in your product.

CustomersEnd-usersManagers

Decision Makersetc…

ColleaguesSenior ManagersBusiness Owner

Sales Team Engineering Team

QA Teametc…

Not all stakeholders are equally important. Or have the same priorities.

At all points of time.

Know who are the needy stakeholders and who are the influential ones.

Stakeholder ContinuumL

ow

NeedLow High

Hig

hIn

flu

ence Key

Stakeholders

Stakeholders

Others

Case Study Exercise

• Identify the stakeholders from the case study and map them on the Stakeholder Continuum

• Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study

http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study






Defining the user stories



Strategic Roadmap Objective

Define a future for the product that key stakeholders know and agree upon.

Provide an approximate direction for the product.

Communicate product future to all stakeholders.

Creating a Strategic Roadmap

• While the roadmap is a commitment, it is not carved in stone.• If your product is your dream, then there is no harm in dreaming big.• Architectural & technical limitations can not be dreamt away.• Any milestone more frequent than quarterly might be more

appropriate for the release roadmap.

Remember

Avoid• Being too short-term-ish• Getting stuck with operational issues at this stage• Getting too carried away and dreaming unrealistic dreams

Creating a Strategic Roadmap

• Roadmap under 1 year is not strategic enough, more than 2 years is probably not realistic enough.

• Degree of commitment against the proposed timeline should visibly come down in a non-linear manner.

• BIG assumptions should be clearly called out.

Tips

Strategic Roadmap Template

1H

2011

2H 2H

Mission

1H

Goals

Key Needs & Challenges

Mission

Goals


Mission

Goals


Mission

Goals


2012

Case Study Exercise

• Create Strategic Roadmap for the case study











Product Backlog Objective

Have a prioritized list of possible features for the product.

Make details available for those who are interested.

Track all the requests made by various stakeholders.

Backlog will generally have primary and secondary items.

PrimaryFeature RequestsChange Requests

Technical ChangesBugs/Defects

SecondaryMaintenance Activities

Project Activities

Generate Product Backlog out of stakeholder requests.Your own plans are equally important.

Backlog is your input pipeline for the product.

Creating the Product Backlog

Creating the Product Backlog

• There is no stakeholder request that does not belong in the backlog. It just needs the right priority.

• Asking questions when a new request comes is an entirely right thing to do.

• The backlog does not need to have detailed descriptions.

Remember

• Use a template to get details about each new request. Separate templates for functional/non-functional requests are not a bad idea.

• Not all requests would always come from customers. PM has to act like that customer who is still to turn up.

Tips

Product Backlog Template

Request By Need Time--line

Import-

-ance

Requester Inputs

User Story

Score Priority Release Commit-

-ment

PM Comment

Case Study Exercise

• Create Product Backlog for the case study• Case Study Link:











Feature Prioritization Objective

Know and let know what is the best for the product.

Stagger all stakeholder requests in a workable order.

Maximize Business Value generated by the product foreach ‘state’.

PLC could be either Product Engineering Life Cycle (PLC) or Product Marketing Life Cycle (PLCM)

PLCConceiveDesign

ManufactureService & Disposal

PLCMIntroduction

GrowthMaturity

Saturation & Decline

Priorities could be different depending upon the product stage.

More focus on features earlier, stability and maintenance later.

Does not however mean a direct relationship.

A stable, usable, working product should always be the first priority.

Importance of PLC

Prioritizing Features

• Features cannot be prioritized unless their impact is known.• Stakeholders just request priority. PM decides about it. • Priorities that do not get buy-in make for the least productive goals.• There is always a running battle between the long term plans and

the short term needs.• Conflicting requests are normal, as stakeholders work in silos. The

goal should be to do what is the best for the product.

Remember

Avoid• Prioritizing based on who it came from (refer influencer/need matrix).• Prioritizing everything too high or too low.• Ignoring the value of non-functional requests.• Sacrificing long-term for the short-term.

Prioritizing Features

• Pure rankings could become complex. 3 or 5 scale ratings are simpler.

• ‘Influential stakeholder’ priorities need to be fit into the ‘Needy stakeholder’ priorities.

• Do not fight long-term or short-term. Trick is to create a balance of both.

• When you cannot fulfill stakeholder requests, communicate, communicate and communicate.

• Prioritization matrix can be used to understand impact and gauge value.

Tips

Prioritization Matrix

Yes

Partial

No

Workaround

Very Low

Low

HighLowFeatureMedium

MediumMediumSub-systemHigh

LowHighSystemShowstopper

EffortImpactScopeCriticality

Alternate Prioritization Matrix

Backlog Item Criti-cality

(5-1)

Scope

(3-1)

Impact

(3-1)

Work-

around

(3-1)

Effort

(1-3)

Score

(sum of all)

Prioritized Backlog Template

Request By Need Time-

-line

Import-

-ance

Requester Inputs

User Story

Score Priority Release Commit-

-ment

PM Comment

Case Study Exercise

• Prioritize Product Backlog for the case study











Release Roadmap Objective

Make detailed roadmap available for those who are interested.

Define a ‘state path’ for the product, with each state representing a product release.

Have a plan for the product that key stakeholders know and approve of.

Creating a Release Roadmap

• Circumstances change, plans stay static.• It is important to work closely with your engineering teams and managers.• Dependency overheads are usually underestimated.• Effort estimates are usually bloated.

Remember

Avoid

• Equating individual contribution to isolated contribution.• Over-committing in the release plan and roadmap.• Making invalidated assumptions, especially about technology.

Creating a Release Roadmap

• Have frequent releases. 2-4 times a quarter is good, 4-6 times is not too bad either. It is important to see what suits your product.

• Have a balance of major and minor releases. • Each release should have a clear cut focus and 1-2 stated goals.

Major releases can be more externally focused, minor releases more internally focused.

• Only the items required to deliver stated goals should be marked committed, others should be marked appropriately.

Tips

Case Study Exercise

• Create Release Roadmap for the case study




1Q 3Q 1Q 3Q

2010 2011

4Q 2Q 4Q

2012

2Q 4Q

Release Roadmap Template

Release 3

Customers

Existing Customer

Confirmed New Customer

Unconfirmed New Customer

Release 1Customers

Release 2

Customers

Release 2

Release 1.1

Release 1.2

Release 1

Mission:

Key Features:

Release 2

Mission:

Key Features:

Release 3

Mission:

Key Features:

Customer 1 Customer

2Release

3








Product Requirements Objective

Specify product features for your developers and testers in an easy to understand manner.

Give your users and customers a chance to validate that the correct product is being built.

Creating Product Requirements

• Reach out to the real user. He probably lays embedded two layers below the level you interact at.

• Even those users do not always know what they need. You are the product owner, it all has to make sense to you at the end of the day.

• If you are not sure about something, then do not be afraid to ask again. Somebody out there would have some idea about it.

• Your testers are as important as your developers. Probably more.

Remember

Avoid

• Making assumptions when you don’t have to.

Creating Product Requirements

• Use a PRD/MRD as the stage might be, FSD/User Story as the methodology might be.

• Break features down if you have to, but they still need to be finite and complete sets with clear requirements.

• Get your developers/testers in a room with you/PO and make sure they clearly understand what you are documenting.

• Definitely find time to review Acceptances tests written by your testers. Unit tests too, if possible.

Tips

Feature Spec Template

Feature Title

Stakeholders

Specifications

Interfaces

Wireframes

Dependencies

Acceptance Criteria

Benefits

Case Study Exercise

• Create FSD for one feature for the case study




Session 3

Product Experience

Product Experience

UI, Usability and UX

Measurement of impact

What is UI, Usability and UX

Simply put, UX is the art of making your users happy.

UX is the overall experience that a user has interacting with the product – it includes UI and Usability.

Usability is the ability to use the product for the intended purpose without any hassles – it partially includes UI.

UI is the User Interface – the visual part of your product.

Why is UX important

UX is the prism through which users sees your product. Same product is different things to different people, it is the experience of using it that shapes their opinion of it.

Improving UX

Start with the basics – become a user of your product first!

Not everybody uses the product the same way as you do.Try to see the product from many differing perspectives.

Being perceived as a good product is equally important as

being a good product.

Product UI

Product UI is critically important – and it is a PM’s responsibility to make a good UI available.

HCI/UX designers are the best people for the job, but a PMmust have basic level in the area, at the minimum.

Use wireframe creation tools to provide the first level of UI.

Product without a UI

UX for a product without a UI needs a different paradigm – it needs alternate ways to communicate what it is useful for.

Most such products become part of other products – so their users are ‘engineers’ building those other products.

Documentation is usually the equivalent of UI here. Demos, videos etc. can be the other collaterals for such products.

Product Experience

UI, Usability and UX

Measurement of impact

Measurement of User Impact

Build analytics into your product, if you can.

Communicate regularly with users, use formal methods like surveys, A/B testing once in a while.

Track usage of related artifacts – number of downloads, visits, documentation reads for example.

Measurement of Business Impact

Business impact is primarily measured economically. In terms of revenues and profits, using P&L accounts.

Concept of BV (Business Value) is a useful tool too, as it measures business impact across the product value chain.

Session 4

Case Study Analysis

Extra Slides

Useful Stuff

• Reading– http://www.goodproductmanager.com/ – http://crankypm.com/ – http://37signals.com/svn/– http://productmanagementtips.com/

• UI Design– http://www.flairbuilder.com/ – https://gomockingbird.com/

Links

Tools

• Accept360• JIRA

http://www.goodproductmanager.com/



http://crankypm.com/



http://37signals.com/svn/

http://productmanagementtips.com/



http://www.flairbuilder.com/



https://gomockingbird.com/



The Cathedral And The Bazaar – 19 Rules1. Every good work of software starts by scratching a developer’s personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 3. “Plan to throw one away; you will, anyhow.”4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective

debugging.7. Release early. Release often. And listen to your customers.8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly

and the fix obvious to someone.9. Smart data structures and dumb code works a lot better than the other way around.10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most

valuable resource.11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is

better.12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was

wrong.13. “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more

to take away.”14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible-and never

throw away information unless the recipient forces you to!16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.17. A security system is only as secure as its secret. Beware of pseudo-secrets. 18. To solve an interesting problem, start by finding a problem that is interesting to you. 19. Provided the development coordinator has a communications medium at least as good as the Internet, and

knows how to lead without coercion, many heads are inevitably better than one.