Practical Product Management for new Product Managers
-
Upload
amarpreet-kalkat -
Category
Business
-
view
9.348 -
download
4
description
Transcript of Practical Product Management for new Product Managers
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
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
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the product requirements
Planning a release roadmap
Feature prioritization
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.
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
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the user stories
Planning a release roadmap
Feature prioritization
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
Key Needs & Challenges
Mission
Goals
Key Needs & Challenges
Mission
Goals
Key Needs & Challenges
2012
Case Study Exercise
• Create Strategic Roadmap for the case study
• Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the product requirements
Planning a release roadmap
Feature prioritization
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:
http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the product requirements
Planning a release roadmap
Feature prioritization
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
• Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the product requirements
Planning a release roadmap
Feature prioritization
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
• Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-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
Learning the Key Concepts
Working with the stakeholders
Planning a strategic roadmap
Building the backlog
Defining the product requirements
Planning a release roadmap
Feature prioritization
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
• Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study
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.
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.
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
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.