Practical Product Management for new PMs Amarpreet Kalkat Co-founder & Chief Technologist @ Ciafo
Agenda <ul><li>Session 1: Introduction </li></ul><ul><ul><li>Usefulness of Product Management function </li></ul></ul><ul>...
Session 1 Introduction
Usefulness of PM Function Understanding an end-user’s pain points, and solving them through the  product features. Balanci...
Key Aspects of PM Function Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pr...
Session 2 Learning the Key Concepts
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pro...
Know Your Stakeholders <ul><li>Any  person who has a professional interest or say in your product. </li></ul>Customers End...
Stakeholder Continuum Low Need Low High High Influence Key  Stakeholders Stakeholders Others
Case Study Exercise <ul><li>Identify the stakeholders from the case study and map them on the Stakeholder Continuum </li><...
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the use...
Strategic Roadmap Objective Define a future for the product that  key stakeholders know  and agree upon . Provide an  appr...
Creating a Strategic Roadmap <ul><li>While the roadmap is a commitment, it is not carved in stone. </li></ul><ul><li>If yo...
Creating a Strategic Roadmap <ul><li>Roadmap under 1 year is not strategic enough, more than 2 years is probably not reali...
Strategic Roadmap Template 1H 2011 2H 2H Mission 1H Goals Key Needs & Challenges Mission Goals Key Needs & Challenges Miss...
Case Study Exercise <ul><li>Create Strategic Roadmap for the case study </li></ul><ul><li>Case Study Link:  http://www.sli...
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pro...
Product Backlog Objective Have a prioritized list of  possible  features for the product. Make details available for those...
<ul><li>Backlog will  generally  have primary and secondary items. </li></ul>Creating the Product Backlog Primary Feature ...
Creating the Product Backlog <ul><li>There is no stakeholder request that does not belong in the backlog. It just needs th...
Product Backlog Template Release Score Priority Commit- -ment Need Time--line User Story By PM Comment Requester Inputs Im...
Case Study Exercise <ul><li>Create Product Backlog for the case study </li></ul><ul><li>Case Study Link:  http://www.slide...
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pro...
Feature Prioritization Objective Know and let know what is the best for the product. Stagger all stakeholder requests in a...
<ul><li>PLC could be either Product Engineering Life Cycle (PLC) or Product Marketing Life Cycle (PLCM) </li></ul>Importan...
Prioritizing Features <ul><li>Features cannot be prioritized unless their impact is known. </li></ul><ul><li>Stakeholders ...
Prioritizing Features <ul><li>Pure rankings could become complex. 3 or 5 scale ratings are simpler. </li></ul><ul><li>‘ In...
Prioritization Matrix Yes Partial No Workaround Very Low Low High Low Feature Medium Medium Medium Sub-system High Low Hig...
Alternate Prioritization Matrix Score (sum of all) Effort (1-3) Work- around (3-1) Impact (3-1) Scope (3-1) Criti-cality (...
Prioritized Backlog Template Release Score Priority Commit- -ment Need Time- -line User Story By PM Comment Requester Inpu...
Case Study Exercise <ul><li>Prioritize Product Backlog for the case study </li></ul><ul><li>Case Study Link:  http://www.s...
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pro...
Release Roadmap Objective Make  detailed roadmap  available for those who are  interested. Define a ‘state path’ for the p...
Creating a Release Roadmap <ul><li>Circumstances change, plans stay static. </li></ul><ul><li>It is important to work clos...
Creating a Release Roadmap <ul><li>Have frequent releases. 2-4 times a quarter is good, 4-6 times is not too bad either. I...
Case Study Exercise <ul><li>Create Release Roadmap for the case study </li></ul><ul><li>Case Study Link:  http://www.slide...
Release Roadmap Template 1Q 3Q 1Q 3Q Release 3 Customers Release 1 Customers Release 2 Customers Release 2 Release 1.1 Rel...
Learning the Key Concepts Working with the stakeholders Planning a strategic roadmap Building the backlog Defining the pro...
Product Requirements Objective Specify product features for your developers and  testers   in an easy to understand manner...
Creating Product Requirements <ul><li>Reach out to the real user. He probably lays embedded two layers below the level you...
Creating Product Requirements <ul><li>Use a PRD/MRD as the stage might be, FSD/User Story as the methodology might be. </l...
Feature Spec Template   Benefits   Acceptance Criteria   Dependencies   Wireframes   Interfaces   Specifications   Stakeho...
Case Study Exercise <ul><li>Create FSD for one feature for the case study </li></ul><ul><li>Case Study Link:  http://www.s...
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 use...
Why is UX important  UX is the prism through which users sees your product.  Same product is different things to different...
Improving UX Start with the basics – become a user of your product first! Not everybody uses the product the same way as y...
Product UI Product UI is critically important – and it is a PM’s  responsibility to make a good UI available. HCI/UX desig...
Product without a UI UX for a product without a UI needs a different paradigm –  it needs alternate ways to communicate wh...
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 met...
Measurement of Business Impact Business impact is primarily measured economically. In  terms of revenues and profits, usin...
Session 4 Case Study Analysis
Extra Slides
Useful Stuff <ul><li>Reading </li></ul><ul><ul><li>http:// www.goodproductmanager.com /   </li></ul></ul><ul><ul><li>http:...
The Cathedral And The Bazaar – 19 Rules <ul><li>Every good work of software starts by scratching a developer’s personal it...
Upcoming SlideShare
Loading in...5
×

Practical Product Management for new Product Managers

10,456

Published on

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.

Published in: Business, Technology
0 Comments
44 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,456
On Slideshare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
750
Comments
0
Likes
44
Embeds 0
No embeds

No notes for slide
  • Examples: Technical Changes (use a different framework) Maintenance activities (automate log file analysis) Project activities ( create pending test cases)
  • Transcript of "Practical Product Management for new Product Managers"

    1. 1. Practical Product Management for new PMs Amarpreet Kalkat Co-founder & Chief Technologist @ Ciafo
    2. 2. Agenda <ul><li>Session 1: Introduction </li></ul><ul><ul><li>Usefulness of Product Management function </li></ul></ul><ul><ul><li>Key aspects of Product Management </li></ul></ul><ul><ul><li>Walk through of the Case Study </li></ul></ul><ul><li>Session 2: Learning the Key Concepts </li></ul><ul><ul><li>Working with the stakeholders </li></ul></ul><ul><ul><li>Planning a strategic roadmap </li></ul></ul><ul><ul><li>Building a backlog </li></ul></ul><ul><ul><li>Feature prioritization </li></ul></ul><ul><ul><li>Planning a release roadmap </li></ul></ul><ul><ul><li>Defining the product requirements </li></ul></ul><ul><li>Session 3: Product Experience </li></ul><ul><ul><li>UI, Usability and UX </li></ul></ul><ul><ul><li>Measurement of impact </li></ul></ul><ul><li>Session 4: Case Study Analysis </li></ul><ul><ul><li>Comprehensive analysis of the Case Study </li></ul></ul>
    3. 3. Session 1 Introduction
    4. 4. 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.
    5. 5. 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
    6. 6. Session 2 Learning the Key Concepts
    7. 7. 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
    8. 8. Know Your Stakeholders <ul><li>Any person who has a professional interest or say in your product. </li></ul>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.
    9. 9. Stakeholder Continuum Low Need Low High High Influence Key Stakeholders Stakeholders Others
    10. 10. Case Study Exercise <ul><li>Identify the stakeholders from the case study and map them on the Stakeholder Continuum </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    11. 11. 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
    12. 12. 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.
    13. 13. Creating a Strategic Roadmap <ul><li>While the roadmap is a commitment, it is not carved in stone. </li></ul><ul><li>If your product is your dream, then there is no harm in dreaming big. </li></ul><ul><li>Architectural & technical limitations can not be dreamt away. </li></ul><ul><li>Any milestone more frequent than quarterly might be more appropriate for the release roadmap. </li></ul>Remember Avoid <ul><li>Being too short-term-ish </li></ul><ul><li>Getting stuck with operational issues at this stage </li></ul><ul><li>Getting too carried away and dreaming unrealistic dreams </li></ul>
    14. 14. Creating a Strategic Roadmap <ul><li>Roadmap under 1 year is not strategic enough, more than 2 years is probably not realistic enough. </li></ul><ul><li>Degree of commitment against the proposed timeline should visibly come down in a non-linear manner. </li></ul><ul><li>BIG assumptions should be clearly called out. </li></ul>Tips
    15. 15. 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
    16. 16. Case Study Exercise <ul><li>Create Strategic Roadmap for the case study </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    17. 17. 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
    18. 18. 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.
    19. 19. <ul><li>Backlog will generally have primary and secondary items. </li></ul>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.
    20. 20. Creating the Product Backlog <ul><li>There is no stakeholder request that does not belong in the backlog. It just needs the right priority. </li></ul><ul><li>Asking questions when a new request comes is an entirely right thing to do. </li></ul><ul><li>The backlog does not need to have detailed descriptions. </li></ul>Remember <ul><li>Use a template to get details about each new request. Separate templates for functional/non-functional requests are not a bad idea. </li></ul><ul><li>Not all requests would always come from customers. PM has to act like that customer who is still to turn up. </li></ul>Tips
    21. 21. Product Backlog Template Release Score Priority Commit- -ment Need Time--line User Story By PM Comment Requester Inputs Import- -ance Request
    22. 22. Case Study Exercise <ul><li>Create Product Backlog for the case study </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    23. 23. 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
    24. 24. 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’.
    25. 25. <ul><li>PLC could be either Product Engineering Life Cycle (PLC) or Product Marketing Life Cycle (PLCM) </li></ul>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.
    26. 26. Prioritizing Features <ul><li>Features cannot be prioritized unless their impact is known. </li></ul><ul><li>Stakeholders just request priority. PM decides about it. </li></ul><ul><li>Priorities that do not get buy-in make for the least productive goals. </li></ul><ul><li>There is always a running battle between the long term plans and the short term needs. </li></ul><ul><li>Conflicting requests are normal, as stakeholders work in silos. The goal should be to do what is the best for the product. </li></ul>Remember Avoid <ul><li>Prioritizing based on who it came from (refer influencer/need matrix). </li></ul><ul><li>Prioritizing everything too high or too low. </li></ul><ul><li>Ignoring the value of non-functional requests. </li></ul><ul><li>Sacrificing long-term for the short-term. </li></ul>
    27. 27. Prioritizing Features <ul><li>Pure rankings could become complex. 3 or 5 scale ratings are simpler. </li></ul><ul><li>‘ Influential stakeholder’ priorities need to be fit into the ‘Needy stakeholder’ priorities. </li></ul><ul><li>Do not fight long-term or short-term. Trick is to create a balance of both. </li></ul><ul><li>When you cannot fulfill stakeholder requests, communicate, communicate and communicate. </li></ul><ul><li>Prioritization matrix can be used to understand impact and gauge value. </li></ul>Tips
    28. 28. 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
    29. 29. 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
    30. 30. Prioritized Backlog Template Release Score Priority Commit- -ment Need Time- -line User Story By PM Comment Requester Inputs Import- -ance Request
    31. 31. Case Study Exercise <ul><li>Prioritize Product Backlog for the case study </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    32. 32. 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
    33. 33. 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 .
    34. 34. Creating a Release Roadmap <ul><li>Circumstances change, plans stay static. </li></ul><ul><li>It is important to work closely with your engineering teams and managers. </li></ul><ul><li>Dependency overheads are usually underestimated. </li></ul><ul><li>Effort estimates are usually bloated. </li></ul>Remember Avoid <ul><li>Equating individual contribution to isolated contribution. </li></ul><ul><li>Over-committing in the release plan and roadmap. </li></ul><ul><li>Making invalidated assumptions, especially about technology. </li></ul>
    35. 35. Creating a Release Roadmap <ul><li>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. </li></ul><ul><li>Have a balance of major and minor releases. </li></ul><ul><li>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. </li></ul><ul><li>Only the items required to deliver stated goals should be marked committed, others should be marked appropriately. </li></ul>Tips
    36. 36. Case Study Exercise <ul><li>Create Release Roadmap for the case study </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    37. 37. 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:
    38. 38. 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
    39. 39. 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.
    40. 40. Creating Product Requirements <ul><li>Reach out to the real user. He probably lays embedded two layers below the level you interact at. </li></ul><ul><li>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. </li></ul><ul><li>If you are not sure about something, then do not be afraid to ask again. Somebody out there would have some idea about it. </li></ul><ul><li>Your testers are as important as your developers. Probably more. </li></ul>Remember Avoid <ul><li>Making assumptions when you don’t have to. </li></ul>
    41. 41. Creating Product Requirements <ul><li>Use a PRD/MRD as the stage might be, FSD/User Story as the methodology might be. </li></ul><ul><li>Break features down if you have to, but they still need to be finite and complete sets with clear requirements. </li></ul><ul><li>Get your developers/testers in a room with you/PO and make sure they clearly understand what you are documenting. </li></ul><ul><li>Definitely find time to review Acceptances tests written by your testers. Unit tests too, if possible. </li></ul>Tips
    42. 42. Feature Spec Template   Benefits   Acceptance Criteria   Dependencies   Wireframes   Interfaces   Specifications   Stakeholders   Feature Title
    43. 43. Case Study Exercise <ul><li>Create FSD for one feature for the case study </li></ul><ul><li>Case Study Link: http://www.slideshare.net/amarpreetkalkat/software-product-management-case-study </li></ul>
    44. 44. Session 3 Product Experience
    45. 45. Product Experience UI, Usability and UX Measurement of impact
    46. 46. 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.
    47. 47. 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.
    48. 48. 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.
    49. 49. 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.
    50. 50. 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.
    51. 51. Product Experience UI, Usability and UX Measurement of impact
    52. 52. 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.
    53. 53. 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.
    54. 54. Session 4 Case Study Analysis
    55. 55. Extra Slides
    56. 56. Useful Stuff <ul><li>Reading </li></ul><ul><ul><li>http:// www.goodproductmanager.com / </li></ul></ul><ul><ul><li>http:// crankypm.com / </li></ul></ul><ul><ul><li>http://37signals.com/svn/ </li></ul></ul><ul><ul><li>http:// productmanagementtips.com / </li></ul></ul><ul><li>UI Design </li></ul><ul><ul><li>http:// www.flairbuilder.com / </li></ul></ul><ul><ul><li>https:// gomockingbird.com / </li></ul></ul>Links Tools <ul><li>Accept360 </li></ul><ul><li>JIRA </li></ul>
    57. 57. The Cathedral And The Bazaar – 19 Rules <ul><li>Every good work of software starts by scratching a developer’s personal itch. </li></ul><ul><li>Good programmers know what to write. Great ones know what to rewrite (and reuse). </li></ul><ul><li>“ Plan to throw one away; you will, anyhow.” </li></ul><ul><li>If you have the right attitude, interesting problems will find you. </li></ul><ul><li>When you lose interest in a program, your last duty to it is to hand it off to a competent successor. </li></ul><ul><li>Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. </li></ul><ul><li>Release early. Release often. And listen to your customers. </li></ul><ul><li>Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. </li></ul><ul><li>Smart data structures and dumb code works a lot better than the other way around. </li></ul><ul><li>If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. </li></ul><ul><li>The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. </li></ul><ul><li>Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. </li></ul><ul><li>“ Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.” </li></ul><ul><li>Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. </li></ul><ul><li>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! </li></ul><ul><li>When your language is nowhere near Turing-complete, syntactic sugar can be your friend. </li></ul><ul><li>A security system is only as secure as its secret. Beware of pseudo-secrets. </li></ul><ul><li>To solve an interesting problem, start by finding a problem that is interesting to you. </li></ul><ul><li>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. </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×