Product Management Flashcards
agile vs scrum
agile is a philosophy
scrum is a methodology
tips for communication
- update everyone on developments as much as possible - internal blog they can read if they want to
- if communicating externally, tell stakeholders the why of the solution, tell them the other solutions you considered and why they weren’t the best
tips for working with designers
- give them all the design limitations early so they don’t go out of scope
- make sure they can always give you feedback on everything
- show them data to support why you need to build something
- don’t tell them what to do - you tell them what and why, not how
- always talk about user problems first, solutions second
tips for working with engineers
NAME?
tech debt
the future work you build up because you didn’t get something right the first time
methods to prioritise tasks
assumption testing
MOSCOW method
MOSCOW method
method for prioritising tasks based on identifying which is a
must have
could have
should have
would have
how to do assumption testing
when trying to prioritise what tasks to work on
- identify the biggest riskiest assumption you are making for each potential task
- rank it out of 1 - 10 for how big/risky the assumption is, so 10 being v risky
- rank it out of 1 - 10 for how important it is, so 10 is it will make a huge impact
- add the two scores together
- sort all the tasks based on this score
assumption testing
a method for prioritising what to work on
what can be more useful than roadmapping for company planing
establishing short, mid and long-term goals
this way the top priorities get worked on and the less urgent things get looked at later
not set to a calendar date so more flexible
why are roadmaps not always v helpful
they aren’t agile - you can’t plan months in ahead what will be best for your team to work on
they provide a nice rough guide but company plans change much more quickly
why use a roadmap
- for executives and investors to see quarterly plans
- you have an external company deadline e.g. investors need a certain function by a certain date
roadmap
a long term plan for the company set into quarters (seasons of the year)
average sprint velocity
the average velocity your team has over time (weeks, months) to help predict how long tasks might take in future
what is the best way of predicting how long a task/ticket will take your software team to build?
- ask multiple engineers to predict how long it will take and how many story points it is (how hard the task is)
- use this to create the velocity (number of tasks completed + how hard they were)
- over a few weeks, create an average sprint velocity to help predict future work timelines
purpose of story points
to help with guaging the amount of work a task/ticket will take
story points
ranking of how hard it is for a software team to do something
e.g. 1 - 5 where 5 is really hard
velocity (in product management)
number of story points that were completed in one sprint
backlog
the place where we hold things we plan to do later but aren’t working on just yet
acceptance criteria
written inside a ticket, it is a very specific description of what the ticket should accomplish
e.g. “Given I am a user who has succesffully uploaded a photo from my computer, when I click send, the image is sent to my friend through the direct message and it appears in the chat”.
what should a ticket include
NAME?
is a user story the same a ticket?
No, a ticket is the task itself that the team needs to action to create the desired functionality, but the ticket should be written as a user story if possible so the team knows why the ticket is needed
what is the format of a user story
as an X i want to do Z, so that I can do Z
user story
a description of the functionality we want to build e.g. “as a user, I want to send pictures in direct messages so I can share them with my friends”
what needs to be covered in the product requirements section of an epic specs sheet
NAME?
what needs to be covered in the introduction of an epic specs sheet
- what the features you’re building are for
- why you’re building it
- what metrics you are trying to improve
- early wireframes and ideal look in future
- links to additional documents (legal requirements, etc.)
4 parts of an epic specs sheet
- introduction
- product requirements
- design requirements
- engineering requirements
epic specs sheet
document that allows anyone in your company to understand what you’re building
guide for your team to build it
(kind of like a protocol)
what’s the difference between an epic and a feature?
a feature is an epic, the term feature just only applies to aspects that the product that are rolled out publicly
so epic is a broader term for all funactionalities built
epics
a group of functions and features that a PM wants to build
usually 3-5 epics are rolled out in a quarter
takes longer than 1 sprint to build
e.g. translate the app to Spanish
or
implement photo sharing in messages
releases
when a company roles out a bunch of new features to the public
usually specified in the company initiatives
initiatives
what the company does to achieve their vision goals
e.g. translate the app into three different languages this year
tools for tracking metrics
google analytics
crazy egg (shows heatmap of users)
kissmetrics
mixpanel
optimizely - A/B testing tool
segment - services hub for overview of all other tools
what type of metrics is the HEART framework for?
reporting
NPS
net promoter score - way to measure user happiness through likert scale
what are the 3 columns in the HEART metrics framework
goals, signals, metrics
what order should the HEART framework be in?
- adoption
- task success
- engagement
- retention
- happiness
HEART metrics framework acronym
Happiness - how happy is your user?
Engagement - how engaged are they in the short term?
Adoption - how many users have tried your product?
Retention - how many do you retain longterm
Task success - how successful are you at allowing users to perform the most valuable task?
what makes a good metric?
- simple e.g. tracks just one action
- rate or ratio e.g. active users / total users
- measures actual impact - doesn’t assume correlation is causation
- changeable e.g. tracks per week to allow time to see changes
difference between exploratory and reporting metrics
exploratory - data points for your specific team to improve the product e.g. how many people click this button
reporting - metrics your company cares about over a long period of time e.g. number of new users
example of revenue metrics
NAME?
MRR and ARR
monthly recurring revenue
annual recurring revenue
How much are we making with all our customers combined?
CAC / CCA
Cost of acquistion of customer
aka
Cost of customer acquistion
How much do we have to spend to acquire a customer?
LTV
life time value
e.g. over 1 year, on average, how much does each customer generate us?
example of engagement metrics
NAME?
example growth metrics
NAME?
when wireframing, what should you ask yourself?
- what is the point of this page?
- users should be able to…x,y,z.
difference between wireframe, mockup and prototype
wireframe is initial step of conceptualisation, low fidelity
mockup is where the design elements (typeface, photos, etc.) are added
prototype is when functions are added (e.g. buttons work)
prototype tools
keynote
pop
axure
prototype
the initial product mockup but with usability
test user flow
the step after mockups
who is in charge of mockups?
designers
mockup
a static display of what the product will eventually look like
comes after the wireframe stage
list some mockup tools
photoshop
sketch
adobe illustrator
list some wireframing tools
figma
balsamiq
axure (pronounced “azure”
wireframe
a blueprint, initial plan, for developers and designers for a product
low-fidelity wireframe
first broad and basic wireframe
landing page
single webpage you are taken to after clicking on a link (usually for purchasing or email sign-ups)