The purpose of the document is to provide an introduction to product management for beginners.

1. Product Management Primer
Subodh R Wasnick | Product Management

2. Product Management | Subodh Content from various internet sources

3. Product Management | Subodh Content from various internet sources

4. 30-60-90 principle for a Product Manager
First 30 days
Product - is PM's baby. FTUX, Get trainer demo product.
People - Schedule time to meet with the engineering, marketing, sales, support. Understand the existing challenges each of these stakeholders have
Process - When in a new land, its important to know the terrain
Tools – Know your tools. Learn if anything is new to you
Second 30 days
Learn – ways can be Retrospectives, Release cycles and Iterations,
Meetings
Assimilate – Mind-mapping, wiki, internal repository, etc.
Ask – Asking is not about getting people to tell us what to do, but
to get people to tell us what they need (Share & Learn)
Third 30 days
Discipline – Themed Days (If you have a 5 -day week, you may
want to consider making one day for any customer visits, one day
for market research, competitive research, etc., one day for
planning engineering release activities, one day for any sales
activities like workshops, sales kit updates, etc.,)
Focus, Focus, Focus – means Focus :)
Bias to Action – It is the ability to act now, and contemplate later
Product Management | Subodh Content from various internet sources

5. Vision Statement using Elevator Pitch
For <end user> who <statement of need or opportunity> the <product name> is a <product category> that <key benefits,
reasons to buy> unlike <primary competitors> our product helps <features that differentiate your product from others>
Example: For ABC employees who need a better way to commute the ABC bus is a pick/drop service that provides a better work-life
balance with pickup/drop from our premises unlike autorickshaw, ola or uber who increases fare during peak hours, rains, etc.
Developing vision by Designing a Box
Product in a Box - <ProductName>
Product in a box gives tangibility to the software products that helps each function within the organisation exactly
what they are building.
Six sides of the box should have the following:
• What is it called and what’s the tagline?
• How does it look? - logo, etc.
• What are the compelling benefits?
• What are the key features ?
• Do you have any testimonials from delighted customers?
• What are the requirements to use your product?
Product Management | Subodh Content from various internet sources

6. Developing vision by Designing a Box
Product Management | Subodh Content from various internet sources

7. Developing vision by creating a Empathy Map
An empathy map is a collaborative tool that teams can use to better understand their customers. It consists of an image of the customer surrounded by
following sections
When to Use Empathy Maps
Empathy maps are most useful at the beginning
of the design process.
Try to complete empathy maps before the
product requirements, but after the initial user
research. Product strategy is about solving
problems, and empathy maps shed light on
which problems to solve, and how. This also
makes them a great tool for redesigns as well.
Product Management | Subodh Content from various internet sources

8. Continuous discovery, Continuous delivery
Product Management | Subodh Content from various internet sources

9. Collaborative Chartering : Impact Mapping
Delivering business goals, not just software features
The map illustrates a milestone of an online gaming platform. The key
business goal for this milestone is to increase the number of active players
to 1 million.
Players are important actors. They can help by recommending games to
their friends, posting about the games on Facebook or inviting friends
directly.
Another group of important actors are advertisers. They can also bring
players by publishing adverts.
https://www.impactmapping.org/example.html
Product Management | Subodh Content from various internet sources

10. User Research:
Building Personas
Customer personas are fictional
characters that product
managers create to represent the
different, common users of a
specific product. They exist to
help product managers
communicate research about
their ideal groups of users — and
give human faces to these
groups. Personas matter because
they represent a product’s core
customer demographics.
Product managers must make
informed decisions about who
their customers are, what they
need, and how their products will
be the solutions. Personas help
product managers make these
decisions.
Product Management | Subodh Content from various internet sources

11. User Research: Building Personas
Product Management | Subodh Content from various internet sources

12. Persona Comparison
User Research: Building Personas
Product Management | Subodh Content from various internet sources

13. User Research: Building Experience Map
Product Management | Subodh Content from various internet sources

14. Product Management | Subodh Content from various internet sources

15. User Research: Building Experience Map
Product Management | Subodh Content from various internet sources

16. User Research: Building Experience Map
Source: Some image of CXD Labs on LinkedIn . The creator deserves a salute 
Product Management | Subodh Content from various internet sources

17. Agile Charter: Theme, Epic, Feature, User Story, Tasks
Mantra: As a <User Type> I want to do <what> so that I can <why>
Product Management | Subodh Content from various internet sources

18. Agile Charter: Theme, Epic, Feature, User Story,
Product Management | Subodh Content from various internet sources

19. Minimum Viable Product
What’s MVP?
Product Management | Subodh Content from various internet sources

20. Minimum Viable Product
What’s Product Market Fit
Product Management | Subodh
Content from various internet sources

21. Minimum Viable Product
User Story Mapping
Product Management | Subodh Content from various internet sources

22. Product Backlog Item, PRD Schema:
Product Management | Subodh
Building Product Backlog
• Target Release,
• Document Owner, Doc. Status, Team
• Goal, Background & Strategic Fit (optional)
• Persona/User Story
• User Experience & Design (UED) Mockups/wireframes
• Data points
• User-flow or logic
• Acceptance criteria
• Out of Scope
• Success Metrics as well as Failure Metrics
Content from various internet sources

23. Product Backlog Refinement
Why
• Large to small
• Prioritize/Reprioritize for mvp
• Incremental delivery…. Kishto mein shipping
• Test assumptions
Product Backlog Prioritisation
• Factors
• Business value
• Opportunity cost
• CSat, feedback
• Risk
• Cost & Time
• Learnings/ experience
• Models
• Kano model
• Relative weighting model – value/cost (http://www.processimpact.com/articles/prioritizing.html) GoogleIt
• Need
• MoSCoW (must have, should have, could have, won’t have/out of scope as of today, agli baar dekhenge)
• Mandatory – client bola! majburi hai!
Product Management | Subodh Content from various internet sources

24. Product Management | Subodh
What’s Business Value
Value = time, money, market reputation, fear of losing major
client, based on customer retention, new customer requirement
Kano Model
RoI = value / cost
Cost of feature = cost per sprint * size of feature / velocity
Value of feature = value of release or theme * size of feature / size of
theme
Story Points Estimation
PBI –> User Story User Story ->Tasks
Who Dev team Dev team
When Prod backlog refinement
meeting
Sprint planning
Unit of measure Story points, use case points,
function pts, etc.
hours
How Planning poker expertise
Content from various internet sources

25. The Scrum Team
Scrum teams are typically composed of 6-8 members and have no team leader to delegate tasks or decide how a problem is solved. The team
as a unit decides how to address issues and solve problems. Each member of the Scrum team is an integral part of the solution and is expected
to carry a product from inception to completion.
There are three key roles in a Scrum team:
The Product Owner
The Product Owner is the project’s key stakeholder – usually an internal or external customer, or a spokesperson for the customer. There is
only one Product Owner who conveys the overall mission and vision of the product which the team is building. The Product Owner is
ultimately accountable for managing the product backlog and accepting completed increments of work.
The Scrum Master
The Scrum Master is the coordinating leader to the Product Owner, Development Team and Organization. With no hierarchical authority over
the team but rather more of a facilitator, the Scrum Master ensures that the team adheres to Scrum theory, practices, and rules. The Scrum
Master protects the team by doing anything possible to help the team perform at the highest level. This may include removing impediments,
facilitating meetings, and helping the Product Owner groom the backlog.
The Development Team
The Development Team is a self-organizing, cross-functional group armed with all of the skills to deliver shippable increments at the
completion of each sprint. Scrum broadens the definition of the term “developer” beyond programmers to include anyone who participates in
the creation of the delivered increment, including QA. There are no titles in the Development Team and no one, including the Scrum Master,
tells the Development Team how to turn product backlog items into potentially shippable increments
Product Management | Subodh Content from various internet sources

26. Scrum Events (Ceremonies)
The Sprint
A sprint is a time-boxed period during which specific work is completed and made ready for review. Sprints are usually 2-4 weeks long but can be as short
as one week.
Sprint Planning [4-8 hrs. or more if reqd]
Sprint Planning team meetings are time-boxed events that determine which product backlog items will be delivered and how the work will be achieved.
The Daily Stand-up
The Daily Stand-up is a short communication meeting (no more than 15 minutes) in which each team member quickly and transparently covers progress
since the last stand-up, planned work before the next meeting, and any impediments that may be blocking his or her progress.
The Sprint Review
The Sprint Review is the “show-and-tell” or demonstration event for the team to present the work completed during the sprint. The Product Owner
checks the work against pre-defined acceptance criteria and either accepts or rejects the work. The stakeholders or clients give feedback to ensure that
the delivered increment met the business need.
The Retrospective
The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what didn’t go well, and how the team can improve in
the next Sprint. Attended by the team and the Scrum Master, the Retrospective is an important opportunity for the team to focus on its overall
performance and identify strategies for continuous improvement on its processes.
Product Management | Subodh Content from various internet sources

27. Scrum Artefacts
Product Backlog
The product backlog is the single most important document that outlines every requirement for a system, project or product. The product backlog can
be thought of as a to-do list consisting of work items, each of which produces a deliverable with business value. Backlog items are ordered in terms of
business value by the Product Owner.
Sprint Backlog
A sprint backlog is the specific list of items taken from the product backlog which are to be completed in a sprint.
Increment
An Increment is the sum of all product backlog items that have been completed since the last software release. While it is up to the Product Owner to
decide on when an increment is released, it is the team’s responsibility to make sure everything that is included in an increment is ready to be released.
This is also referred to as the Potentially Shippable Increment (PSI).
Product Management | Subodh Content from various internet sources

28. Product Management | Subodh
The Scrum Process
What after shipping?
Post deployment
• Feedback from stakeholder during sprint review/demo
• Deploy to preferred clients & validate
• Pilot run on Internal users/MTG & take their feedback
Content from various internet sources

29. Release Planning
Product Management | Subodh
• Release Notes
• Blogs
• Tutorial Videos
• Demo to Sales & Support
Content from various internet sources

30. http://availagility.co.uk/2012/02/02/the-science-of-kanban-economics/Product Management | Subodh
Cost of Delay
Content from various internet sources

31. Tool Purpose
Roadmunk Roadmaps, planning, etc.
Jira Good for engg/tech
Confluence Documentation, PRD
Trello Product/project management, multi-purpose
Balsamiq (preferred), ninjamock, moqups, axure wireframes
Planning poker Story point estimation
draw.io (I love it… must try, it's free)
Flowchart, UML, entity- attribute relationship, many
more..
Lucidchart Flowchart
Xmind Mind mapping
POP 2.0 Prototyping of paper
workflowy
Collapsible bullet-notes: to take notes, make lists,
collaborate, brainstorm, etc.
Slack Communication
InvisionApp for mobile app screen flows, entire prototype, etc.
Lookback.io
User research, to understand mobile app user
behaviour
Product Management | Subodh
Few tools that facilitates product management
Content from various internet sources

32. Product Management | Subodh Content from various internet sources

33. Dhanyawaad
Product Management | Subodh
Note: Content from various internet sources
The purpose of the document is to provide introduction to product management for beginners

34. Thank You
Product Management | Subodh
Note: Content from various internet sources
The purpose of the document is to provide introduction to product management for beginners