Product Management (Product Development Process
Product Development Process
- Product ideation and requirement gathering process
- Repeat tasks -> automate thing
- What is the pain of other people
- What is your own pain
- Development team to build the product
- Sometimes you need to work with engineering team to see if the product features can be supported.
- Lot of coordination between team:
- Customer support to introduce new features
- Announce to customer
- Product announcement email outline the new features and FAQ was sent to entire company to help people fill question from clients.
- Public facing materials and marketing: screenshot, release notes, PR release, PR articles, blogs.
- Whole product team to monitor the new features in 48 hours
- Product never ever launch bug free
- Measure performance on platform, venue, event, types of customers
How to generate good product ideas
- Product failed because they don't solve problem
- The best product managers build products solve problems
How to discover your product:
Best product manager builds product that solve problems
- Customer discovery
- Problem solution Fit
- Proposed MVP
- Proposed funnel
Find ideas by looking for pain
How to measure pain:
GO TALK TO YOU USERS TO UNDERSTAND THEIR PAIN.
Good product solve low pain with high frequency (Yelp)
Good product also solve pain in high magnitude and low frequency (Insurance)
Great product solve problem with high magnitude and high in frequency in pain.
Frame work to refine ideas (NFB tables)
Many product manager failed since they are so in love with their ideas and saw it as the ultimate solution that every will use.
- Needs (A void or gap of what people like to do and able to do)
- Features ( a product specification or specific function that allows a user to accomplish a task)
- Benefits ( what the feature allow you to do, the missing piece that complete the users need)
Great product managers are scientists that are humble, skeptical and data informed..
Process to filter out ideas
- Write all your ideas down (10-15 of thems)
- Ask your self what kind of problem is this idea solving. If they are just nice to have but not solving any problem then cross them out. You need to fall in love with the problem, not the ideas
- Rank the left over ideas in order of pain
- Bring ideas whose pain in both in high magnitude and high in frequency to the top
- Bring the ideas with pain is high in magnitude to the middle
- Bring the ideas with pain is high in frequency to the bottom
- Take the top three ideas and create a NFB tables for each idea
- If you stuck on one of the column, sleep on it to see if new insight come our or not that this could be a signal of a weak product.
Finding market fit
using SWOT to see market analysis
- Strengths (data, scale, reputation, copyrights, flexibility)
- Weaknesses (financials, market awereness, and rebuild)
- Threats (lawsuit, ....)
Feature tables - Look at crunch base
Size the market
Trend in the market
There are 2 types of trends
- Wait for the right time to enter the wave
- Change in customer value, priority or lifestyle (diet, workout, ...)
- Change in the law, for example law on marijuana
- Shift in demo graphic or change in wealth distribution
Empathy maps for users
Brief description ( what they want to get out the the services)
Pick a persona
- Key people
- Offer exposed to Problem they face
- Friends and family
- Professional Environment?
- Say and Do:
- Do they Influences?
- Think and feel
- What matters?
How to validate Ideas:
To strengthen your hypothesis you need two types of validating qualitative and quantitative
You need to talk to and understand the users:
- Qualitative is in the form of user interviews
- Quantitative is in the form of tests
UNDERSTAND YOUR USERS
- Lead to better design decisions
- You will build a product that truly address their need
- Stand up in a room of fully stakeholder and say: I talk to the user and this is what they said.
If you don't talk to the user then:
- Create the wrong product
- Create a right product for the wrong audience
- Create a product that not address the need and has no place in the market.
- What are my users? Ages?
- What are their habit? Do they use phone a lot, when do they use them?
- When do they use the product?
- Who else is using the product?
- How do they access the product?
- Open questions, dont ask yes no questions
- What kinds of app you are using in the past? What kinds of experience you have with those apps
Process to understand users:
- For top 3 apps, compose the questions that you can use to interviews users to validate your ideas
- Impact of the problem to find out about the magnitude of pains
- Remember to ask question about habit to understand about the frequency of pains
- Interview 3 users for each idea
- If you find out new ideas during the interview, create NFB tables for it.
- Narrow down to 1 ideas to focus on
Validating your product idea
Lean product development
- Feed back loop:
Not just failing fast but failing well.
MVP is not a functional product that solve a problem. MVP is to accelerate learning
An Experiment composed of:
Run a few experiment and ask yourself:
what do we learn from them? If the team agree on the result => Yes, that's what we need.Bad:
Have to modify experiment if hit some bad points
- Disagreement with interpretation
- Experiment running too long
- Not studying critical information
- Has to be risky: good, more learning, hypothesis always valid then you are not testing anything.
- Hypothesis can be about user, product or feature
- Good hypothesis indicate a casual relationship with a persona
- Good: "If we add soccer photos to our landing page, it will convey trust to Athletic Alvin, and he will sign up"
- Bad: " Some people will sign up if we add a landing page" Why?
- This is a fact, there will always be user sign up if we add a landing page
- Bad: "We think users will like this product". Why?
- We supposed to test reality, not beliefs. Believe carry very little value if you trying to gather learning on a project.
- "Users" is vague. Which persona are you taking about?
Survey and Focus Group are bad.
- Quantitative and Qualitative
- Vanity metric (not as useful as actionable metrics)
- Time on Page
- Registered users
- Actionable metrics
- Confirm Order
- Abandon Cart
If the experiment will last longer than a week then you might not be aggressive enoughTesting on friend and family are bad idea
- One Page Landing page that describe the product and request visitor to sign up to a mailing list.
- Changing the product description and measure the convert rate.
- Create FB ads or Google ads target your products demographic to the users.
- Well target ads are convert around 3% so if the ads beat 3% then there is a market for the product ideas.
Create a video
- Good demo videos can draw thousand of people ...
Test using a concierge method
- Ask a few customer to try out a service product which you will manually do all the labor work to server the order. Find out what people order and build a product that automatically order.
- The price is right?
- Ex: Zappos order shoes
Shaping the product
Refine product Idea
Create a product statement ideas:
- Brainstorm a list of features user might be interested in
- Determine who you user, what is the most important for them? Decide on 3 characteristic that define your users
- Filter the feature lists to focus on the users
Craft the product statement on defined information:
- Ex: A back to school shopping app for thrifty college students who hates researching what the needed supplied are.
Create a feature backlog
Black log should focus on product capability other than work tasks. Focus on "what're you building" rather than "how I'm building it"
- Capturing request
- Give prioritized work
Focus on what other than how
Items should be (INVEST):
- User stories (should be small enough for the team to complete within an iteration)
- Chores: no direct value
- Epic: Big user stories that take more than 1 sprint to complete
Characteristic of backlog
MVP is the subset of the backlog with intention to launch
- Backlog should be transparent and visible to everyone.
- Single source of truth
- Backlog is dynamic
Backlog should never be empty. Item on the top of the backlog should be work on first and should be broken down to stories for the development team to work on.Items that cant be build will go into the "ice box"
- Start with the product definition statement which should include products main purpose and its intended persona.
- Aim to create a backlog with 10-20 items
- Features not sure -> icebox
Ex: "Show map of nearby stores" or "Buy book from online store"
Ready for wireframe if we have a product statement and features backlog2 kinds of wireframe
Focus on communicating the understanding and usability of the product over how pretty the product is. The rest have the visual designer take care of.Using mocks to create interactive prototype that can be clicked through.
- low fidelity
- high fidenilty
- low fidelity is good for communicating with the developer to see if product is possible to build
- high fidelity wireframe is good for
- What the button are and what they do
- What the content are and where they appears
- What kind of data you want to show the users
- Ask developer: are you sure you'll be able to get this data on this screen?
Use it for user testing:
Question to ask:
- "How would you complete this task?" Watch out for delay, hesitation, whether user making decisions on what to click on -> signal that the user interface is confusing and need to be improve
- "What do you think this word do?" Great for labeling button
- "If you tapped on this button, what do you expect to happen?" - An intuitive is an app that will seem familiar to the user and behaves up to their expectations even though they have never seen the app before.
Write Great User Stories
Ready to write your User stories if have
How to write a great user stories:
- Product definition Statement
- Feature Backlog
NEVER THE "HOW":
- Title: what is the feature is all about (should be around 10 words)
- Description: (should fit in an index card) If it is too long then it should be split up into multiple stories. Should follow INVEST and testable.
User (who), Goal(what), Reason(why).
Acceptance Criteria or condition of satisfaction
- Attach wireframe and mocks
Acceptance Criteria or condition of satisfaction
- Dev own the "how"
- We dont want to wait time. It's not our jobs to do so
- We dont want to be wrong. We will have the finger pointing if the solution is wrong.
Example of good user stories:
Title: Search by first and last name
Description: As a cashier, I want to search for my customers by their first and last names so I can quickly access their purchase history.
"Given the cashier has typed a first name, last name, and clicked the search button, show list of customers." -> where logic and rules often go.The stories will start the conversation between product manager and developers -> discussion will lead to details that are missing.The only thing constant in this world is "change"
There are 3 ways of prioritizing stories
- Assumption Testing
1. Assumption Testing
Build the most important feature that you're least sure about first. Front low the risk so you can save time later.
To do this:
- First assign an assumption value to each user story. The less confident you are about the assumption, the higher the value.
- Assign the important value to each user story. The higher the importance, the higher the value.
- Add the two value to the stories and sort the back low.
2. MoSCoW (Must, Should, Could, Wont)
To to implement:
- Must: stories that must be satisfied in the final product for it to be consider as success.
- Should: High priority stories that should be included in product if it is possible. Critical requirement but one which can be satisfied in other ways if strictly necessary
- Could: stories which is considered desirable but not necessary. This could be included if time and resources permit.
- Wont: represent a story that stake holder have agreed will not be implemented for this release but will be in the future release.
Is this story dependent on other stories? The must have cannot depend on the delivery of anything other than a must have because the risk of it not being there.Get the definition on the must have, should have, could have and wont have with the stakeholders before you even write the user stories.
- Start all the stories as "Won't" and justify why they need to be given a higher priority.
- For each story that is justified as a must have, ask: "What happens if this story is not completed?" If the answer is "cancel the product" then we need to have this, there is no point in building a product that does not meet this story, then it is a must have story.
- "Is there is workaround" -> if there is then this is not a must have stories. Compare the cost the work around and the cost of the stories including the cost of any associated delays.
3. BUC methods: Business benefit, User benefits, Cost
How to created a weighed average value for each feature across three categories. One of the limited is that it hard to come up with the accurate benefit and cost number.
- Business: what the benefits for the business, does it drive revenue, does it decrease cost?
- User: What is the impact on the user satisfaction or user experience
- Cost: how much time and cost this story take.
However this process can still be good for validating hunched and looking for overlooked features.
The framework is also great approach for more complex business model serving multiple master.Figure out BUC for each stories then use the formula: Business + User - Cost.
After all stories have their BUC value then sort them highest first.
How to estimate the stories
Normally leave to developer but it is good to know the process:
Break down a features into many stories as possible to implement and test them. Should be estimate on complexity instead of time.
The definition of done: comprehensive understanding of everything required to say that a story is done and releasable including items like user documentation translation and advertising.
After the definition of done then the team can take the sample stories and calculate the effort require
From that we can have a rough estimate on timing for release planning and enough understanding to assist in story prioritization.
Using pivotal tracker, we can use velocity to estimate when is the release time.
Working with developer:
Give them more details
Commonly asked questions:
Think of the as the thought partner that think of all the use case that you have not think of.Product manager is the users voice, need to focus on
- What will happen when the screen is in this state?
- What is the logic power the interaction?
- What will the error message say when this happens?
UsersDo not want the developer to guess.Four area where the developer might need to ask for more details:
Product manager normally thinking about the happy path, developer normally thinking about the unhappy path.Talk to them early on when shaping the product and when having a feature backlog. Need to get a feel of which feature is easy, hard, impossible. Which feature can be build into your MVP
- Internationalization. What is the design look like in another language.
- Error states: connectivity lost, crash.
- Edge cases: If the user using this has no information or activity. When the timeouts happen for transitions.
- Transition: What is the precise way that screen A become screen B. Slide in from the last, rise up from the bottom?
5 Tips to work with developers:
- Be prepare: be clear of what you need in your feature or product plan and healthy timeline and expectations. Developer should clearly know what is needed from the product and what all he is free to improvise on. Have to have a backup plan if the developer is facing too many issues or surprises
- Be a great listener and have empathy
As a product manager you can trade 3 things:
Never trade quality. If the management want to launch sooner, Pair up with developer and persuade to trade on scope but never quality
Make sure the feature or product is there to stay.
- Have a clear vision and inspire
Work with designer to come up with stuffs looks beautiful to everyone especially the developers. They should be proud of what they making.
Throwing developer work is extremely painful for him or her.
- Proactively improve moral.
Keep the team happy and motivated. Keep good relationship with them.
- Work closely with them while they're building
Sit in the same room.
You own the product, if something is wrongly implement, that is your fault. Ask them to show you when the implementation is done.
Anything is possible. Need to guide them onto the proper way.Hand them the high fidelity wireframe that have:
Layout, functionality, and data that much.
Focus more than the look and feel.
Give the details or post the screenshot and the styles that you like
Give them a starting point. Give them
Facilitate the discussion between them and developer.
- Photo with color scheme
The designer should tell the developer what is the dimension and the file format.
3 Tips to work with designer:
Bad: "We can't hurt our metrics with this change"
- Be clear about the problem, not what they need to do to fix it. Clearly communicate the problem and the constraint.
Bad: "This confirm order button needs to be green because it will be less confusing than red"
Good: "Can we pick different color than red because read normally communicates a destructive action"
- Talk about user experience: Designer normally think and operate in the mindset of a user. Communicate with them on the UX, not the number
Bad: "Can we increase the click through rate of this button?"
Good: "How can we make suer users know about this cool new features and that it's easy to use?"
Good: "We need to make sure this change doesn't make it harder for users to get their tasks done"
- Talk to your designers about the abstract
Designer tend to overvalue user but not the entire network or experience.
Designer might user their own experience as a metric however they are not the target demographic. Show them the personas and empathy map you made.
Designer value are hard to measure like:
- User trust
- Comprehension and clarity
- Long term sentiment
Influence from Stakeholder can make or break your product.
- Your boss
Their main need is "So what?"
They normally intercept when there is ideas for a feature or a desire for a certain style of look and how this matter.
They want to know about the bottom line and how it impacts the business.To communicate effectively with the stake holder, bring out the metrics.
Bad: "We want to build this button this way because it's cool and easy to use"
Good: "We want to build this button because it will increase the click-trough rate to check out and increase our total revenue"Find out the preferred communication style is and adapt to it:
- Short emails
- Phone call
- In person
- Dont want them to learn a new tool or a new process just to communicate with you.
- Make it easy for them to make decisions by giving them options.
- Give them the situation in straightforward term don't overwhelm them with lots of information.
- Cut to the chase
- Prepare to do a deeper dive if they ask questions
- If state holder need to take actions to move the product along, dont assume it will be obvious. State it to them.
- State the actions in list form and when do you need them by.
5 tips to work with state holders
1. Build trust early with willingness to learn: they should trust you will understanding their concern and trust that you will keep them informed of important decisions or changes => They will give you the room to come up with the best product solutions possible, even when your solutions are very different from theirs.
This trust can be built by demonstrating that you have a deep understanding of:
Without the knowledge, they dont trust you.
- You customer
The willingness to learn and spend time one on one with each key stakeholder. Explain with them the better you understanding the constraint, the better the solution will be. Ask lot of questions, be open and be transparent.
Commit to previewing your decision, design with the key stakeholder before you put this in the product backlog.Take three to four hours a week to meet for half an hour meet with each stake holder to keep them prized and to get their feedback on new ideas.
- Inform stakeholders of product decisions.
Common mistake is now showing the stakeholder the solution until it's built. This is critical since if the product does not met the skateholder's expectation and constrained, the product need to be rework => frustrating developer + designer.
- Have number to backup your decision as a product manager
Most of the time it boil down to your opinion versus the skateholders. In most case the stakeholder win because they are more senior The key is moving the discussion away from the opinions and onto data. How to get data to back up your decision: running tests and collect some evidence. Share what you are learning very openly. Maybe none of us is right. That is what the discovery track is for.
- Don't schedule big stakeholder group meetings
Thing will get out of control. Let them five the feedback individually.
Definition and Roles
A valuable product is:
- Used by millions of users
- Generate millions $ in revenue
Product Life Circle
Provide cross functional leadership
Lead product without authority
UX product manager
Technical product manager
Analytical product manager
- Product Manger
- Project Manager
Product Marketing Manager
- QA Engineer
- Executive skateholder