Practical Product Management for new Product Managers
Upcoming SlideShare
Loading in...5
×
 

Practical Product Management for new Product Managers

on

  • 5,531 views

This presentation provides tips and tools for a professional who is new to Product Management function (in software). ...

This presentation provides tips and tools for a professional who is new to Product Management function (in software).
It does not cover the full lifecycle of a product and primarily focuses on the product development/product building phase. As such, it is more usable for professionals working on existing products than for those in the process of building new products from scratch.

Statistics

Views

Total Views
5,531
Views on SlideShare
5,494
Embed Views
37

Actions

Likes
18
Downloads
320
Comments
0

7 Embeds 37

http://searchutil01 13
https://twitter.com 11
http://192.168.6.179 7
http://staging.slideshare.com 2
http://192.168.6.56 2
http://twitter.com 1
http://192.168.33.10 1
More...

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Examples: Technical Changes (use a different framework) Maintenance activities (automate log file analysis) Project activities ( create pending test cases)

Practical Product Management for new Product Managers Practical Product Management for new Product Managers Presentation Transcript

  • Practical Product Management for new PMs Amarpreet Kalkat Co-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
  • 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.
    Customers End-users Managers Decision Makers etc… Colleagues Senior Managers Business Owner Sales Team Engineering Team QA Team etc… 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 Continuum Low Need Low High High Influence 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
  • 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.
    Creating the Product Backlog Primary Feature Requests Change Requests Technical Changes Bugs/Defects Secondary Maintenance 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
    • 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 Release Score Priority Commit- -ment Need Time--line User Story By PM Comment Requester Inputs Import- -ance Request
  • 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 for each ‘state’.
    • PLC could be either Product Engineering Life Cycle (PLC) or Product Marketing Life Cycle (PLCM)
    Importance of PLC PLC Conceive Design Manufacture Service & Disposal PLCM Introduction Growth Maturity 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.
  • 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 High Low Feature Medium Medium Medium Sub-system High Low High System Showstopper Effort Impact Scope Criticality
  • Alternate Prioritization Matrix Score (sum of all) Effort (1-3) Work- around (3-1) Impact (3-1) Scope (3-1) Criti-cality (5-1) Backlog Item
  • Prioritized Backlog Template Release Score Priority Commit- -ment Need Time- -line User Story By PM Comment Requester Inputs Import- -ance Request
  • 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
  • Release Roadmap Template 1Q 3Q 1Q 3Q Release 3 Customers Release 1 Customers Release 2 Customers Release 2 Release 1.1 Release 1.2 Customer 1 Customer 2 Release 3 2010 2011 4Q 2Q 4Q 2012 2Q 4Q Existing Customer Confirmed New Customer Unconfirmed New Customer Release 1 Mission: Key Features: Release 2 Mission: Key Features: Release 3 Mission: Key Features:
  • 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   Benefits   Acceptance Criteria   Dependencies   Wireframes   Interfaces   Specifications   Stakeholders   Feature Title
  • 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
  • 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 PM must 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
  • The Cathedral And The Bazaar – 19 Rules
    • Every good work of software starts by scratching a developer’s personal itch.
    • Good programmers know what to write. Great ones know what to rewrite (and reuse).
    • “ Plan to throw one away; you will, anyhow.”
    • If you have the right attitude, interesting problems will find you.
    • When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
    • Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
    • Release early. Release often. And listen to your customers.
    • Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
    • Smart data structures and dumb code works a lot better than the other way around.
    • If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
    • The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
    • Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
    • “ Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
    • Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
    • 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!
    • When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
    • A security system is only as secure as its secret. Beware of pseudo-secrets.
    • To solve an interesting problem, start by finding a problem that is interesting to you.
    • 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.