PM Notes
Was this helpful?
Was this helpful?
https://www.youtube.com/watch?v=OsMptnZZr4M&feature=emb_logo
https://www.youtube.com/watch?v=VquT7fG7668&feature=emb_logo
Strategy is about how you are going to realize your vision and takes the following things into account:
User needs
Key Features
Competitors & Differentiation
Business Goals
Trends
When you create strategy, you want to make sure that it’s:
A balance between features, user and market needs, and business goals
Creating building blocks for how to get to your vision
High level, but with a little more detail
Goal oriented, and preferably measurable
https://www.youtube.com/watch?v=9_yLq1vgWxs&feature=emb_logo
The business model canvas includes the following components:
Key Partners - help build or deliver the product to users
Key Activities - what you need to do to build and deliver the product
Key Resources - things that you need to build the product
Cost Structure - cost of building the product
Value prop - why people would want your product
Customer Relationships - how you build relationships
Channel - how you get the product to customers
Customer Segments - different types of customers
Revenue Streams - how you get money from customers
Revenue models: https://www.youtube.com/watch?time_continue=5&v=JjwngEs0JlI&feature=emb_logo
Competitive Analysis
https://www.youtube.com/watch?time_continue=171&v=IdCb8VFhM7Q&feature=emb_logo
An MVP, or minimum viable product, has just enough features to get early adopters excited. After launching an MVP, you’ll get a lot of feedback that will help you understand if you have product market fit and what areas you should invest in next
To create an MVP:
Start with the business model canvas
Weigh against competing solutions
Make sure it’s aligned with business objectives
Translate to requirements
Identify KPIs
https://www.youtube.com/watch?time_continue=36&v=tez-pUdN86Q&feature=emb_logo
https://mlsdev.com/blog/minimum-viable-product-examples
https://www.youtube.com/watch?time_continue=15&v=hSwXnrDFtAU&feature=emb_logo
pld: Zoom
https://www.youtube.com/watch?time_continue=75&v=fcBKmn0d27w&feature=emb_logo
https://www.youtube.com/watch?time_continue=11&v=MOLthh86cbQ&feature=emb_logo
Sprint methodology: https://www.thesprintbook.com/how
https://designsprintkit.withgoogle.com/
Phase 1: Understand: https://designsprintkit.withgoogle.com/methodology/phase1-understand
Phase 2: Define: https://designsprintkit.withgoogle.com/methodology/phase2-define
SPRINT BRIEF
SPRINT CHALLENGE: …………………………………………………..…………………………………………………
What is the challenge that you want to solve in the sprint?
Here are 4 things that make a great challenge:
- The challenge is something real that the team needs to deliver
- It’s stated in a way that sounds inspiring - something to solve for
- It’s clear and concise
- It includes a time frame (next quarter? 3 years from now?)
Example: Redesign the future of self-driving cars as a service, focusing on two future milestones: 2014 and 2016.
DELIVERABLES:
…………..………………………………………………………..
What do you want the team to create during the sprint? Example: user journey flows for X and Y. Vision video… Website prototype.
- Aim for the highest quality deliverables possible. Digital polished work, videos, interactive prototypes.. win over sketches.
- List all platforms that we need to design for (web, mobile, tablet) / (physical product + website) / (environment)
LOGISTICS:
Who: ………………..……
When: ………………..……
Where: ………………..……
Sprint Master: ………………..……
APPROVERS & RESOURCES:
Stakeholders: ………………..……
Who needs to sign off on the project so it can launch? We want to include this person’s view in the sprint so we can plan a path to launch that’s fast and smooth.
WIP: Stakeholders
For short term sprints: Assignment development team, if any: ………………..……
It’s recommended that you start a design sprint by having assigned development resources to carry the work after the sprint. This is easier in the case of short-term focused sprints.
For long-term / vision sprints: Plan to secure resources: ………………..……
Vision sprints take a long-term view of planning. In order to succeed, your team needs to have a plan of approvals for how to integrate the sprint within the organizational roadmap.
PROJECT TIMELINE:
1. Current state of the project
What’s been created already? If this is a new project with no history, just say so. If this is a 4 year project with lots of history, summarize.
2. Roadblocks
What stands in your way?
3. Early wins, if any.
Has our team demonstrated any wins or learnings in your space already?
4. Estimated launch plan
When is the projected launch for the piece we are designing? What is this likely to be at launch - a website, campaign, service, physical product… Make sure to list that in the challenge statement as well.
SPRINT SCHEDULE - 3 Days
DAY 1
9:00 Arrival and registration
9:30 Welcome & Introductions
Overview of Sprint and rules - (5 min)
Ice Breaker/Meet the team (15 min)
Introduce the Challenge - (3 min)
Directions for HMW’s - (2 min)
10:00 Understand: Lightning Talks
Business Perspective -
Voice of the User -
User Journeys and Pain Points
Design Evolution/Product Audit
Competitive Landscape
Technological Opportunities
11:30 HMW’s and Affinity Mapping
12:30 Lunch
13:30 Review existing User Journey
Map out an improved journey
Success Metrics
14:30 Comparable Problem in Parallel Space
15:00 Boot up
Crazy 8’s Sketching
16:00 Solution Sketch
17:00 End of day Team check-in
DAY 2
9:30 Open with a Daily Inspiration & Recap of Day 1
Present Solution Sketches
Assumptions & Sprint Questions
Vote and decide on what to Prototype
11:00 Begin Storyboarding
12:30 Lunch
13:30 Finish Storyboard
14:00 Assign tasks & Start Prototyping
17:00 End of Day Check in
DAY 3
9:30 Opening with Recap of Day 2
Finish Prototype
Prepare script for user sessions
12:15 Lunch
13:00 User testing session 1/2
13:45 Debrief
14:00 User testing session 3/4
14:45 Debrief
15:00 User testing session 4/5
16:00 Debrief & Share back to the team
17:00 End of Sprint!
https://www.youtube.com/watch?time_continue=13&v=15zpdvzg4kk&feature=emb_logo
Challenge Statement
Creating a challenge statement for a Design Sprint is a great way to help everyone understand the purpose of the sprint. The best challenge statements are:
Short and easy to understand
Something with urgency that needs to be delivered
Contain a timeframe
Are inspiring and get people excited
An easy format to follow is:
[ACTION] + [OUTPUT] + FOR [USER] + TO [PROBLEM] + BY [TIMEFRAME]
Sprint Team
About 6 people
If more than that, split the group into smaller teams that work through exercises in parallel and then share with the whole group
You will want to identify people whose work is directly related to the sprint challenge
Agenda
Build a rough agenda for your sprint
Select methods for each phase (which we’ll discuss in the following lessons) that will provide insights for the problem you are trying to solve. Keep in mind the composition of your sprint team-- if people are more familiar with the problem space, it likely will make more sense to spend more time on ideation whereas if people are less familiar it would make sense to spend more time on understanding the problem space.
Space
Secure a space for the sprint to take place, preferably somewhere away from distractions
Tons of space for everyone who is participating
Whiteboards or lots of wall space for posting stickies
Supplies
Post it notes
Dry erase markers for whiteboard (multiple colors)
Sharpies
Pens
Paper
Giant post it notes (if no whiteboard)
Logistics
Send a calendar invite to the sprint team
Coordinate getting some light snacks / refreshments for each day
Arrive earlier to make sure that the room is arranged in a way that is conducive for collaboration (ex: a U shape around a whiteboard)
Send a reminder the day before, with any pre-work that the team needs to do (like reviewing user research or trying competing products
https://www.youtube.com/watch?time_continue=100&v=NMujpkcADw8&feature=emb_logo
If your Sprint team hasn’t worked together before, it’s a good idea to spend a little bit of time getting the group comfortable with each other. At a minimum, this means that each member should know every other member’s name and role.
It can also be beneficial to do a quick icebreaker exercise, although you won’t want to spend too much time on this -- no more than 20 minutes. These are short exercises designed to get people to open up and connect with others. Two quick icebreakers you can use are:
Two truths and a lie - each team member introduces themselves and includes three facts about themselves. Two of them are true and one is false. The team must figure out which one is false.
Superpower - each team member introduces themselves along with the superpower that they are bringing to the team
https://www.sessionlab.com/blog/icebreaker-games/
https://www.youtube.com/watch?time_continue=10&v=VlG3CApWuXc&feature=emb_logo
Tips when working with designers
You are not a designer. Acknowledge that designers have expertise when talking about UI and flows
When critiquing a design it’s often more effective to ask about the intention of a choice
Design is a critical partner for Product Managers. It’s important to cultivate strong relationships and understand and acknowledge the perspective of your Designer(s). Your style of communication goes a long way. When critiquing a design, keep in mind that it’s often more effective to ask about the intention of a choice rather than saying you don’t like something.
For example, asking "What was the reasoning behind placing the button in the right corner?" can then develop into further conversation where you can share that you are worried that users might be confused and not able to find the button due to its placement. This is a much more effective way to work with Designers than saying "I don’t like where the button is placed." or "The button is placed in a confusing location."
The first phase of the Design Sprint is Understand. The goal with this phase is to create a shared understanding of the problem space across all sprint team members. There are a number of different ways that this understanding can be captured and shared, but we’ll focus on just a few in this course.
You’ll want to set up inputs that highlight and demonstrate different viewpoints and perspectives across a multitude of dimensions. You can do this using the following techniques:
Lightning talks
User research
Business goals/needs
Technology
and more
Interviews
User interviews
Stakeholder interviews
Expert interviews
Competitive analysis
You’ll guide the team through responding to these inputs and capturing their responses through the following methods:
How Might We
Rose Bud Thorn
Affinity Mapping
https://www.youtube.com/watch?time_continue=3&v=Ai98zAysnF4&feature=emb_logo
Lightning Talk
A lightning talk is a short presentation, usually about 20 minutes, focused on a specific topic.
User research
Who is the user?
What are their needs and goals?
Why does this problem matter to users?
Business goals
What are we trying to solve?
Why does it matter?
What have we tried in the past?
What’s worked well and not so well?
Technology
What are our technical capabilities?
What are the limits and constraints or limitations on our existing tech?
https://www.youtube.com/watch?time_continue=103&v=kULpnL1eNK0&feature=emb_logo
Interviews
Interviews allow you to gain perspectives from a number of different vantage points. There are lots of types of interviews you can set up including:
User interviews
Build empathy for users
Get a deeper understanding of user needs and pain points
Stakeholder interviews
Dive deeper into some of the reasoning, rationale, and context of why this specific problem is important to solve
Topics can include any previous efforts to solve this or a similar problem
Expert interviews
Provide specialized insights around a specific problem, population, or technology
Can be either internal or external
Példa: https://www.youtube.com/watch?time_continue=10&v=aAYH70vyhUo&feature=emb_logo
https://www.youtube.com/watch?v=zfWRTvBuU6U&feature=emb_logo
How Might We” is a method to capture problems and frame them as opportunities that can be solved. Each statement should be captured on its own sticky note.
“How Might We” statements always start with the same three words, which creates a positive solution oriented framing.
How - acknowledges that we don’t know the answer yet but believe this problem can be solved
Might - acknowledges there can be more than one solution and that we shouldn’t stop at the first idea. “Might” also acknowledges that not every solution will work, but it’s still ok to discuss and explore ideas that might not pan out
We - acknowledges that the team is invested in solving this problem together
Things to Remember
Write one “How Might We” statement per sticky note
Each statement should be open ended
Statements should focus on open ended opportunities, rather than a specific solution. Try to avoid statements that are too narrow.
példa: https://www.youtube.com/watch?time_continue=1&v=O7QUbcet82o&feature=emb_logo
tools:
https://www.innovationchampions.com.au/toolkit/hmw-statements
https://www.designkit.org/methods/3
https://www.youtube.com/watch?time_continue=12&v=b61fB870Pd0&feature=emb_logo
You can use the Rose, Bud, Thorn method to classify aspects of a topic and visualize good aspects, opportunities, and negative aspects.
Roses are positive things. For example roses could be things that are going well or seen as a successful. Roses can also represent things or parts of a product that people enjoy.
Buds are things that could turn into roses, if given the right attention. They represent areas of opportunity.
Thorns are negative things. For example thorns could be problems or shortcomings. They also can represent broken product experiences.
https://www.youtube.com/watch?v=T0HAVZRvGsg&feature=emb_logo
Affinity mapping is a way to visually sort related ideas together into categories and themes.You’ll go through each idea/insight, quickly discuss, and then place onto the board. As similar or related ideas are discussed their respective sticky notes should be placed next to each other. Over time you will see that clusters of related sticky notes have started to form. Make sure to label each cluster. Once all sticky notes have been placed on the board and you have a couple different clusters, look to see if any of those clusters are related. Related clusters will create themes If so, rearrange those clusters so that they are next to each other. Draw a circle around those clusters and create a label for the theme that you discovered
https://www.youtube.com/watch?time_continue=12&v=p6LkxePq3Aw&feature=emb_logo
https://www.youtube.com/watch?v=ffO8nPiWytA&feature=emb_logo
Things to Remember
The HEART framework is a user-centered method to define metrics that measure the quality of the user experience. It’s simple and easy to understand and can help with decision making in later phases. There are five dimensions:
Happiness - user attitude towards your product
Engagement - how users are using the product in terms of frequency or number/types of features used
Adoption - how many new users start using your product
Retention - how many users keep coming back
Task Success - ability for users to complete critical tasks in order to be successful with the product
Across these dimensions, you will then want to start by identifying goals, then signals, and finally metrics to measure how well your product is doing.
A goal is something the user is trying to do or something you are trying to help them to do
A signal is a change in user behavior that indicates that the user is achieving the goal
A metric is a way to measure signal and quantify how much user behavior has changed
Keep in mind that it’s ok for goals to have multiple signals and metrics. It’s also not necessary to have metrics for every dimension. It’s more important to pick things that are relevant to the problem you are trying to solve.
példa: https://youtu.be/qO5y1sokvY4
https://www.dtelepathy.com/ux-metrics/
Design principles are guidelines that should craft how you think about building your product. By aligning on design principles with your team, it also makes decision making easier because you can frame questions in the context of your design principles.
When you are writing design principles with your team, you should capture each principle with a word or two and a short explanation that explains the intent in more detail. When you refer to your design principles later you can just refer to the short version.
http://the-amazon-way.com/blog/future-press-release/
https://www.toptal.com/designers/ux/guide-to-ux-sketching
példa: https://youtu.be/VzDJD_BeKsU
Assumptions
Questions
Consumers buy the same items
Do consumers buy the same items?
Are there factors that affect item choice (ie: will some people just buy what’s cheapest)
Consumers buy some items on a regular cadence
What factors affect how often consumers purchase an item?
Consumers are comfortable with a set it and forget it type of subscription for some types of goods
Are consumers comfortable with a subscription?
What types of goods would consumers be comfortable subscribing to?
Questioning assumptions is a good way to make sure that you are exploring all angles of a solution
Things to Remember
A decision matrix allows you to visualize the trade offs between different ideas when comparing across two criteria.
Ideas generally worth pursuing will be high value & low effort or high value & high effort
Ideas that are low value & high effort are generally not worth pursuing unless value increases or effort decreases in the future
Ideas that may not make sense to pursue now, may be worth pursuing later if the value of the idea increase or the effort to pursue the idea decreases
példa. https://youtu.be/z3BiUc9f_98
The Thinking Hats exercise allows you to make sure that different perspectives are being discussed and pushes people to be open to different perspectives since everyone will have to represent multiple, differing views..
The team discussion focuses on one hat at a time. The order can vary, but you'll want to start and end with the blue hat (process). This order works well when comparing ideas:
Blue hat - process (align on goals and order of hats)
White hat - data
Green hat - creativity
Yellow hat - benefits
Black hat - judgment
Red hat - intuition
Blue hat - process (summary of discussion)
Here's my take on the Grocery Store Chain app idea wearing the four Thinking Hats.
Blue Hat - Process
What goal do we want to pursue?
What sequence for the hats?
White Hat - Data
We know:
Consumers visit grocery stores ~1.6x week
The average consumer spends 30 minutes in our store each visit (not including travel time) and purchases 13 items
Our stores each carry around 50k items
Green Hat - Creativity
Digital vs. in store experiences
What should the interaction of purchasing an item look like?
Yellow Hat - Benefits
Navigate:
Makes it super easy to find items in the store
High tech factor
Similar to getting driving directions
Suggestions:
Can be super helpful to surface products consumers will enjoy
Helps if consumers forgot a specific product
Super simple and lightweight interaction
Autopilot
Removes the need for consumers to create/manage shopping lists
Options for store pick up or delivery
Flexible re-ordering that has the potential to be based on purchase data
Navigate:
Really hard to do well
Overkill
Many people won’t want to have an app open in order to navigate through a store
Suggestions:
This would really only work for online purchases
Do we have enough data to build this in a meaningful way?
Autopilot
Are consumers comfortable giving up this much control?
What if pricing increases for an item? But the item is still auto-purchased?
Giving choices between schedules and pick up/delivery creates additional complexity
Navigation seems cool, but not sure we could execute on this with high quality
Suggestions makes sense and seems like there’s little downside
Autopilot seems the most exciting and has the opportunity to transform our business
Move forward with Autopilot!
Thinking hats is a method that allows you to make sure other perspectives are being represented and discussed when deciding on which idea to move forward to prototyping
NEXT
Storyboard maps out the problem facing your user and the journey they go through with your product to solve it
A storyboard is composed of frames that depict events along the user journey
Each frame should have a caption that explains what is happening and why
The first frame should explain how the user found themselves in this scenario and what is the problem they are trying to solve
The storyboard will become the blueprint for the prototype
https://www.smashingmagazine.com/2017/10/storyboarding-ux-design/
Write your script first, and then create images for each frame
The first frame should articulate the problem
The last frame should show how your product helped the user solve the problem
The frames in between the first and last frame should show how the user gets from the problem to the solution
You created a storyboard using theplot.io
You started by creating your first frame and describe the problem the user is facing
Then you created your last frame and described the value of what your product allowed the user to do
And then you created frames in between to explain how the user got from the problem they were facing to the solution using your product!
Theplot.io is a great tool for building storyboards, but there are lots of other tools out there as well!
By hand on paper
Things to Remember
Stay focused. Identify the screens/flows that you need to build in order to test your idea
Use a template. Build a base screen that you can duplicate to use as the foundation for additional screen
Keep it real. Avoid using placeholder assets and copy. This will change the way that users interact with and provide feedback about your prototype
Test it. Click through your prototype once your done to make sure everything is workin
Type
Effort
Pros
Cons
Video
high
Very powerful, exciting, shows end to end user journey
Takes a long time to make even short videos, Can get people too excited
Paper
low
Fast, cheap, and easy to iterate. Also works great as a team building exercise since everyone can be involved
Won’t resemble a digital product, can sometimes be difficult for participants to imagine it as if it were a digital software experience
Type
Effort
Pros
Cons
Presentation Software
med
Relatively easy to build and gets pretty close to mimicking what the real experience could feel like
Need to pay lots of attention around alignment, lots of importing mocks and checking alignment
High fidelity
med
Super realistic, can quickly be updated, can be used as a spec that engineers build off of
Sometimes the prototype is too good… And doesn’t reflect what will actually be built (ie: latency)
Prototyping is a cheap way to get feedback on an idea without having to build out the whole idea. There are a number of different types of prototypes that you can build depending on the specifics of the problem you are tackling and the timelline involved.
After you run your prototype through user testing, you’ll get helpful feedback to let you know that you are on the right track or that you need to course correct.
Other tools for high fidelity prototypes:
Prototyping with Figma
Start by creating a base template
Once your template is complete, you can copy that frame to use as a starting point for your other screens
When your mocks are done, go into prototyping mode and create connections between your frames
Test your prototype to make sure everything is working correctly
Here is the prototype I created.
Validation is a super important part of the Design Sprint process. It allows you to test your ideas and get feedback without having to invest in fully building out the idea. You’ll validate your idea by talking directly to your target users to learn more about them and then ask them to try out your prototype and provide feedback.
In addition to getting feedback from users, it’s also important to validate that your idea can actually be built by the engineering team in a reasonable amount of time.
Things to Remember
When planning for a user study, you’ll want to think through these things beforehand:
Who is your target user?
How many interviews will you have?
What do you want to find out?
Background information about the user
Specific questions around your idea
Tasks to complete with a prototype
How much time you will need to complete each interview
Create a research plan to make sure that you are tracking all these pieces of information and capturing all the questions you want to ask.
példa: https://youtu.be/v45DC1RP6qQ
Target Users:
Split between power shoppers and casual shoppers
Split between one person households and multi-person households
Slightly skewed towards people who have not purchased groceries online in the last 30 days Number of Interviews: 7 x 60 minutes Research Objectives (the questions we want to answer):
Have you ever shopped for groceries online?
What was that experience like?
Are there specific items you wouldn’t consider purchasing online?
How would you feel about groceries being automatically ordered for you?
Are there any concerns that you would have?
A lot of work goes into running a user study before the interview even starts! It will be important to correctly identify and invite your target users to participate in the interview. At the same time, it’s also important that you identify clear questions that you hope to answer through the study, along with the more specific questions you will ask the user in order to answer the larger overarching question.
exercise: https://youtu.be/sYR04mS6AxI
Introduction and overview of the study My name is Alex and I’m a Product Manager here at Grocery store. The team’s been working on some exciting new ideas about the shopping experience and we wanted to share them with you and get your feedback.
The way that this interview will run is… I have a few background questions to get to know you a little bit better and some of your shopping habits. Then, we’ll switch gears and I’ll show you a prototype that the team has been working on and ask you for your feedback.
Before we get started, please review this NDA and sign it. It’s important that the things we show you and the ideas that we discuss today stay confidential.
Do you have any questions before we get started?
No questions… Great! Is it ok if I record this session? The recording is only going to be used internally by the team to refer back to our conversation. It also helps make sure that we don’t miss anything in the notes.
General questions about the user's background (as related to the product)
Can you tell me a little bit about yourself?
How long have you been living in this city?
Can you tell me a little bit about your living situation?
When was the last time you went to a grocery store? How often do you go?
More specific questions about the user's experiences getting groceries
Have you ever purchased groceries online? Why or why not?
What types of items would you consider purchasing online? Why?
Do you have any concerns about purchasing groceries online? Why?
If you were to purchase groceries online, how would you like items to get to you? Why?
Tasks for the user to complete in the prototype Now I’m going to show you a prototype that the team has been working on. Keep in mind that this isn’t a test… And there’s no right or wrong answer. We’re trying to understand how well this idea works for you. And because it’s a prototype, not everything you see in the app may work.
One more thing… As you start using the prototype, I’m going to ask you to think out loud. I’m interested in hearing what you are seeing on the screen, how you are interpreting it, and what you expect things to do.
Go ahead and take a look around. Can you describe what you see?
How would you go about finding items that you ordered in the past? Can you show me?
Let’s say that you wanted to purchase more paper towels. How would you do that?
What are the different options for getting the product to you? Which one do you prefer? Why?
User's feedback about the prototype Awesome! Thanks so much for going through all of that with us. Just a few more questions
Do you think this is something you would use? Why or why not?
Is there anything you think could be improved?
Is there any other feedback you want to share with the team?
Thank you message to the user for participating Thanks so much for coming in! We really appreciate you taking the time to share your thoughts about what we’ve been working on.
It’s important to have a good structure for the user study. This can be achieved by starting with an introduction and then asking broad questions, which become more focused and then switching to asking the user to complete tasks using the prototype.
When creating your research plan and running the study, it’s also very important to keep your questions open ended and avoid leading questions. This helps to make sure that you are getting unbiased, honest answers back from the user.
You can have the best idea, but if it can’t be built in a reasonable timeline you won’t get very far.
It’s not your job to know how to build it, but it’s important that you can have a technical conversation to understand complexities and make tradeoffs
You can use a prototype to help facilitate the conversation by walking through user facing flows
You should also come prepared with some questions around what data is needed to generate the UI, where user entered data will be stored, and any causes for latency
példa: https://youtu.be/1D0x5EB2RyQ
Having a technical feasibility conversation allows you to better understand what level of effort will be required to build your idea. It also allows you to identify and potentially mitigate technical challenges and complexities early on.
The other big benefit is that it helps engineering to understand the specifics of what you want to build early on. Engineering will also have the chance to provide feedback about the overall design and suggest ideas for how it could be simplified to mitigate against risks.
Iteration: https://youtu.be/PhvkK5689h8
We’re off to a good start, but there are some areas we need to push harder on:
Optimizing sign up flow -- The sign up flow for subscriptions could be better optimized to reduce user confusion around the concept. We also can do a better job articulating the value to users.
Managing active subscriptions -- There’s currently no way for users to cancel a subscription. We need to address this before the product can launch
Prices changes -- We need to figure out how to handle price changes
At the end of a Design Sprint you will have a number of great artifacts that you can share to explain the problem, process, and approach that the team took. Sharing a summary of the Design Sprint more broadly will help to create buy into the project and the Design Sprint process.
The most powerful artifact you can share will likely be the prototype since it will clear communicate your idea from the perspective of how a user would interact with it
példa: https://youtu.be/tw1z-CjwAro
Creating an evangelizing plan is a great way to share what you learned in the Design Sprint. Now that you've made one, go share your team's great product!
Things to Remember
A Product Requirement Doc captures the problem the team is trying to solve, the goals of the project, how success will be measured, and the requirements for how features should work along with associated priority.
A PRD typically has the following sections:
Background
Problem
Goals
Success metrics
Features
For each feature, you'll want to include a priority level:
P0 = launch blocker. Product will not launch without this feature
P1 = desirable for launch, but not required. Fast follow after launch
P2 = nice to have
P3, P4 = unlikely to get built
Here's the PRD I wrote.
Things to Remember
The PRD is the most important document that you will create as a Product Manager. It serves as an input to a handful of other teams. There’s a variety of different formats that you can use, but you’ll always want to make sure that you have the following sections:
Background
Problem
Goals
Success metrics
Features (including priority)
Background
Problem
Goals
Success Metrics
Key Features & Scope
Core UX Flow
Background
Over the years, we’ve seen a big increase in the number of online retailers and the types of goods sold online. Historically, ordering items online would take some between when the order was placed and the item was delivered. But, in recent years the amount of time between these two events has significantly decreased. In some cases, items are delivered same day!
Problem
This trend is starting to emerge for groceries. This represents a huge threat to our business! Our competitors are starting to roll out services that provide a better experience and more convenience for our customers. There’s been a 6% decrease in the number of unique customers we see year over year.
In order to stay competitive, we need to bring our business into this new technology era by offering a digital experience in an app that can complement our brick and mortar stores. We really need to make it easy for customers to purchase items and minimize the amount of take that it takes to get an item to a customer.
Goals
Build an app that allows customers to purchase groceries
Increase the number of items that are purchased through automated subscriptions
Reduce the amount of time that users spend finding items
Success Metrics
Launch an app that has at least 4.5 stars on the app store
Increase items sold by 15%
Reduce the amount of time users spend finding items by 50%
Key Features & Scope
Priority
Feature
Description
P0
Sign-in with loyalty card
The user can log into the app by entering the phone number associated with their loyalty card.
No password is required. Instead, the user will be sent a text message with a 4 digit code that they can use to sign in.
P1
Automatic SMS entry
When the SMS is sent to the user, their phone should prompt them to use the code from that SMS message. The user should not have to copy and paste the code from their SMS messages.
On iOS, this means that we need to construct the content of the message in a way that will be recognized as a one time code.
On Android, we should use the SMS User Consent API, which will prompt the user to let us retreive the code from the text message when it arrives
P0
Purchase History
Users should have the ability to see their purchase history, including previous purchased that are linked to their loyalty card.
Items that were most recently ordered should appear at the top of the list.
P2
History Ordering
Users should be able to order their purchase history by date, count, or price
P0
Search
Users should have the ability to search for an item by entering text. The user should be able to search by item name as well as description.
An item’s name should have more weight than the item’s description when ranking.
P1
Search ordering
On the search results page, users should have the ability to further refine and order the results. Users should be able to order search results in the following ways:
Popularity
Price
Alphabetical
P0
Subscriptions
Users should have the ability to create subscriptions to automatically purchase items at given intervals. The intervals that we should support are:
Once a week
Once every two weeks
Once a month
Once every two months
Once every three months
Once every six months
The default option should be once every two week.
P1
Suggested interval
If the user has purchase history, we should set the default interval based on the frequency of past purchases for that item.
P0
In store pickup
When users purchase an item-- either one time or through a subscription-- they should have the ability to pickup their item in store.
P0
Delivery
When users purchase an item-- either one time or through a subscription-- they should have the ability to have the item delivered to their home
Core UX Flow
0. Set the Stage
You will start a PRD that can be shared with the team to set the stage about why this problem matters. The first part of the PRD will include:
Any relevant background information
A problem statement which communicates the scope of the problem
Initial goals, which can continue to evolve throughout the project
1. Understand
Create a shared understanding of the problem space and identify opportunities through a “How Might We” exercise.
Create at least 20 virtual stickies that ask questions following the "How Might We" model
Opportunities. Not solutions.
Not too broad, and not too narrow
One idea per sticky
Get input from other members of your digital "team"
Open the Google Slides deck that corresponds with your project
Copy three slides back into your deck
Sort and group the stickies
Place any stickies that do not follow the "How Might We" model into an "other" cluster
Group similar stickies together into clusters and label each cluster
Group similar clusters together into themes -- one per slide -- and label the title of the slide with the theme
Pick one theme that you want to move forward with and explain your rationale for selecting that theme
2. Define
By defining and focusing on the desired outcomes, you’ll be able to more clearly understand how to get there.
Define success metrics - Identify goals along with the signals and metrics that can be used to measure them using the HEART framework. This will be helpful later on, as you’ve already outlined what your project needs to do in order to be successful.
Start by identifying at least two user-centered goals
Then identify what signals from user behavior will affect reaching each specific goal
Finally, create metrics derived from those signals can be measured
Write a future press review
Think about how you want users to respond to your product:
Who is it for?
What problem does it solve?
How does it change a customer’s life?
Why should customers love it?
Use that information to draft a review from the perspective of the user
3. Sketch
Generate ideas for possible solutions based on the theme that you selected.
Create 8 quick sketches to quickly generate a few ideas.
Take a sheet of paper and fold it into 8 sections
Sketch an idea in each of the 8 sections
Spend about 1-2 minutes per sketch
Pick two to develop into more detailed flows that clarify how the solution would work.
Spend about 30 minutes per sketch
Sketch your idea in more detail than the last exercise -- use text annotations if needed
Create at least 3 frames that show how the user progresses through the flow
Include a title
4. Decide
Pick the final concept that you want to develop into a prototype
Pick your most compelling solution sketch
Explain why it’s the most compelling
5. Prototype
Turn your concept into a realistic, interactive prototype that you will use to validate your assumptions and ideas
Storyboard - Create a storyboard based on your best solution sketch. We’ll use the storyboard as the blueprint to create the prototype.
The storyboard should:
Be high fidelity enough to build a prototype:
Detail the steps a user goes through and how they progress from one step to the next
Detail the layout of the software experience (wireframe level detail)
Cover the entire user journey (ie: things that can happen outside the software experience)
What prompts the user to use this?
Prototype - Create an interactive prototype to showcase your concept
Create mocks based on your storyboard using the Figma prototyping tool
Use the prototype tool to define the flows
Describe the concept that your prototype captures
Describe the flows/tasks a user can complete in your prototype
6. Validate
Users will go through your prototype and provide feedback on your concept. This is also an opportunity to have an engineering feasibility discussion
Create a Research Plan
Create a research plan
Identify your target user
Map out the flow of the interview
Intro
Background information
Tasks
Wrap Up
Run User Studies - Inviting users in to participate in studies is a great way to get feedback if you are on the right track. Additionally, it’s also easier to course correct at this point before any code has been written. We’re going to invite 2 users to try out the prototype that you built. You’ll use the research plan you created to guide the study and will record the audio from the session. You should also plan to take notes during the session.
Schedule two meetings with people you can interview about your prototype
Note: It might not be possible to someone who meets your target user criteria-- and that’s ok for the sake of this exercise
Run through your interview script in the research plan.
You will ask some background questions to the participant and then ask them to complete several tasks
Make sure to take notes during the interview (you can use the research plan as a template for notes)
You should record the audio of the interview
You should plan to spend about 30 minutes per interview
Prepare for a feasibility conversation - Now that you’ve created an interactive prototype of your concept, it’s important to make sure that it can actually be built. Engage with engineering early on, to make sure you understand the tradeoffs of how design decisions can impact timelines. Prepare to have a feasibility conversation with your engineering team or lead.
Map out dynamic elements that are displayed in your UI
Identify where you assume the underlying data is coming from
List questions you have around these assumptions
Map out what data you collect from your users (ie: text input field) and how it will be used
Identify where you assume this data is being stored
List questions you have around these assumptions
Map out your expectations around latency
Identify things that you think might increase latency
List questions you have around these assumptions
Leverage learnings from your first two user interviews to make changes to your prototype. Then run another round of user interviews.
Course correct
Pick the top two issues that you identified in the previous user interviews
Explain your rationale for wanting to address those two issues
Update your Figma file to address those two issues
More user studies
Schedule one meeting with people you can interview about your prototype (not the same people as before)
Note: It might not be possible to someone who meets your target user criteria-- and that’s ok for the sake of this exercise
Run through your interview script in the research plan.
You will ask some background questions to the participant and then ask them to complete several tasks
Make sure to take notes during the interview (you can use the research plan as a template for notes)
You should record the audio of the interview
You should plan to spend about 30 minutes per interview
Refine the problem and goals section (if needed)
Complete the Key Features and Scope section
Link your mocks to the PRD
Influencing without authority
Knowing your company goes beyond the mission, vision and strategy. It is about knowing the details that go into defining the strategy to support the company’s mission and achieving the vision.
Who is the target customer?
What are the customer’s unmet needs?
Who are the competitors?
How does the company create value?
How does the company grow?
I highly recommend spending the initial 2-6 weeks of joining as a Product Manager to acquire the above knowledge to believe in your own message, define the problem to solve and identify the solutions.
példa: https://youtu.be/Xu-2qLObCTc
Becoming a storyteller means moving away from requirements, numbers and graphs and focusing on the user, their problems and the impact to make it more engaging for the audience to believe in the problem, the proposed solution and impact of solving it.
What problem is being solved?
How does it impact the user?
What is the impact of solving the problem on product strategy and goals?
What is the solution?
Here are a few additional readings that discuss Kanban in further detail:
summary: https://youtu.be/KwDbuxrcfww
JIRA management: https://youtu.be/1wBKt6WYCYc
What happens during this period?
The development team uses a version control system to track all the changes made to the codebase, manage and view the changes made in a specific part of the codebase easily. It also allows the development team to restore the codebase to a stable version when undesirable or unstable changes are added to the code base.
Developers always start with the most current and stable version of codebase called the master or main trunk and make a copy (called as a branch) to their local environment.
Once the developer adds new features or makes modifications to an existing feature, they write and execute test cases to ensure their modified code passes. This is called unit testing.
When developers merge their unit-test verified code directly, conflicts may occur. Many teams adopt continuous integration, where the modified codebase is validated by running automated tests. This helps the development team identify and resolve conflicts earlier and improve delivery speed
Continuous delivery is an extension of continuous integration, where the latest version of the master is deployed automatically to an internal environment called staging.
QA team conducts comprehensive and exhaustive manual testing in the staging environment. The product manager conducts user acceptance testing, feature demo and sign-off with internal stakeholders here.
In most companies deployment to production is manual
After deploying the latest version of the codebases to production, smoke tests are run to verify whether basic functions and critical features are working as expected
For the feature review phase (discussed in Lesson 1), the requirements document captures the initiative scope, its impact on product goals and metrics and the feature details at a high-level. The Scrum team that is involved in developing and testing the product typically refers to the product backlog (discussed in Lesson 2), which contains the prioritized list of features with detailed information to build a feature. It is critical for the feature details from the requirements document to be broken down into manageable chunks that are clear, concise and written from a user perspective. This allows the development and QA team to collaborate with the Product Manager and Designer to discuss the details of how to support the feature based on the proposed design that was shared during project kick-off and updated based on feedback from stakeholders and feasibility input from the development team ( Refer to Coordination Activities Map in Lesson 1)
Although user stories are mostly written by Product Manager, the scrum team members, and Product Designer can contribute to writing them as well. However, the Product Manager confirms the details of the user story and acceptance criteria (to be discussed soon) to ensure details are captured for the product backlog correctly. True to the definition of Agile-Scrum methodologies (discussed in Lesson 2), user stories are written and added to the product backlog throughout the feature development.
A user story is a short and concise feature description written from the user perspective. The template for writing a user story is
As a < type of user >, I want to < some goal > so that < some reason >
Refers to the person who wants the new capability. It is typically the end-user of the product but depending upon the product for which you are writing user stories, the end-user could be internal to the company such as customer service manager
Captures the user's intent (or) need that they are trying to satisfy (or) job to be done. It does not cover details of 'how' the need is satisfied i.e doesn't refer to the UI design
What is the reason or motivation behind the user's need (or) intent (or) job to be done? This conveys the benefit that user gains when we help them achieve their goal or solve their problem.
Examples:
As an exercise, I want to create a custom workout so that I can use it to workout regularly as it meets my specific fitness goal, exercise preferences, and /or body limitations
As an internal customer support manager, I want to view the custom workout of a specific user so that I can understand their issue better to assist in solving their problem
A product has business-driven and system-level requirements that are not user-focused and seems like a misfit for the user-story format. In such scenarios, it is effective to write non-user stories that are simple and focuses on detailing what needs to be done. For example:
Track every single user interaction on every page at the browser and/or device level for Mixpanel tracking
Are all stories customer-centric?
Characteristics of a user-story
Acceptance Criteria: https://youtu.be/nmgsVjydUVs
How to write acceptance criteria: https://youtu.be/tAV_Pt-kE2U
A user story’s goal can be met in different ways similar to how a problem can be solved in real life in many ways if constraints, context, and other inputs are not taken into consideration. The most effective way of solving the user's problem or meeting the user's need is captured using acceptance criteria. Acceptance criteria capture a feature behavior in detail from user-perspective
It helps the scrum team understand what to develop to mark the story as DONE. This minimizes the opportunity for scope creep where the requirements that need to be developed increase mid-sprint thereby affecting both sprint velocity and team’s ability to deliver on the sprint goal
Similarly, the acceptance criteria are used by the QA team to confirm whether what has been developed is working as expected
The details captured using acceptance criteria are helpful during sprint planning for the team in determining ‘how to deliver’ the user story and story points estimation In summary, acceptance criteria when captured well helps the PM create alignment with internal stakeholders, customers, and scrum teams on how to solve the user's problem or meet their needs.
Acceptance criteria: https://youtu.be/VJEB3dpKIZ4
As we all know the number of enterprise customer or consumer use multiple products or applications to complete their desired task or job. For companies to thrive in the complex and competitive world and provide seamless customer experience, speed to market is key to success. Companies integrate with third-party APIs to expand into newer product segments while providing better customer experience. API stands for Application Programming Interface and it enables products or applications to talk to each other. API is the code that determines whether a product or application can access the server, and what information is it allowed to access or modify. Companies expose APIs with supporting documentation for other companies (i.e partners) to integrate. Partners utilize these APIs to launch new features or enhance existing features faster to the market instead of taking multiple quarters or sometimes years to develop it from scratch. Any newly developed functionality that is available via the API can be leveraged with minimal effort by the partners. Some popular third-party APIs that are widely used:
Stripe API:
Process payments by charging a credit card or debit card
Charge customers on a recurring basis
Offer discounts to customers for a specific period of time
Whatsapp API:
Companies can provide real-time notifications and include documents or images into their message
Customer can interact with a company or vice-versa
Encourage customers to provide feedback instantly at the end of service
Although the partners can save multiple quarters or years of development and maintenance effort, integration with third-party APIs has its disadvantages as well. It is important to not have the entire product dependent or rely on third-party APIs completely. It adds significant risk and dependency on these companies with third-party APIs. These third-party integrations are usually available at a cost and some APIs charge on a transaction basis or limit the number of transactions. For e.g Stripe offers a standard fee for handling credit card transactions and a discount for large volume transactions. This cost cannot be ignored and needs to be considered as part of the development and maintenance cost by you as Product Manager Understanding the basics of an API will allow you as a Product Manager to engage with internal stakeholders, engineering teams, and customers when third-party API integration is being explored or used to provide new functionality and enhance the user experience.
We will focus on understanding the key details that you need to know about an API as a Product Manager. In the case of Technical Product Manager, it definitely goes beyond the information shared here.
REST: REST stands for representational state transfer. A REST API needs to adhere to a set of architectural principles and characteristics. The REST API architecture describes six constraints and these can be learned from the Become Technical Enough Further Research section -characteristics of A REST API. At a very high-level, a REST API is resource-based. A resource refers to a thing and nouns are used here. For e.g Plan, Subscription, etc. Representation of the resources (which is a thing) in various ways. When an API call is made from the client to the server, the response contains a representation of the resource. JSON is the commonly used format and XML is also used
Authentication: Not all products or applications can access an API. You need to have pre-approved access (just like how you need access code to enter some buildings). In the case of APIs, this access code is called the authentication token. A company like Stripe or Whatsapp will issue the token and credentials for you to access their API. As part of this, the company will also determine what information and actions are you allowed to carry out (for e.g after entering the building using the access code you can access five floors and use all the tools available). The former is authentication which confirms your identity, while authorization will determine what you are allowed to access and carry out as actions or view information. Username, password and authentication token is required for authentication. OAuth framework is adopted by companies to authenticate and authorize partners
Requests and responses: This is communication that happens between the client and the servers. As per the API documentation, a partner can request for information in a specific format and if the partner is authorized to access this information, the server responds with something in return in JSON or XML formation. The API documentation contains information around the different types of requests that are allowed and what can you expect to receive in the response
Headers: Both the request and response will include headers, which contains useful information. The header typically includes authorization details, content type i.e how is the information provided to the partner and what content is included, and date indicates the request or response's date and time
HTTP Methods: Partners request for information using HTTP methods ( think of these as commands or instructions with a clear definition of what needs to be done. There are many methods, but the most common methods used are: create, read, update and delete information (referred to as CRUD). Some commonly used methods are
POST: Used to create a new resource. For e.g company can create a new message using Whatsapp API for a specific customer
GET: Read the information you requested from the representation of a resource. For e.g. Retrieve the invoice for a specific customer using Stripe API
PUT: Update data. For e.g Update the billing address for a specific customer using Stripe API
DELETE: Delete data. For e.g. Delete a customer using Stripe API
Endpoints: It accepts the request from the client to access the API resources. Remember a company can have many endpoints but they need to be exposed for the partners to access. Let's breakdown a Stripe API's endpoint: DELETE v1/customers/: id
HTTPS method is DELETE
Endpoint is v1/customers/: id used to delete a specific customer
Returns * an object with the deleted parameter on success, and an error message if the customer ID doesn't exist
API calls: The request made to API is referred to as API calls. When you connect the different details we discussed above, an API call is used to hit an exposed endpoint and if you are authorized to access the API and the requested API, you will receive the information you need. In the case of Stripe API, you made an API call to the Delete endpoint with a specific customer ID and Stripe will respond with a success message or an error depending upon whether the customer ID is found or not
Payload: Another terminology used to refer to the response from the API is Payload. The payload refers to the important information you receive in the response that you need to pay attention to since the response contains a lot of information. For e.g, the payload from Stripe API to retrieve a specific customer's data will include address, currency, email, and name.
Response Codes: The API response also includes a response code. This code is a numerical value with a specific meaning associated with it. These response codes are meaningful especially to the Product Manager to be able to determine the different scenarios when an API call fails and determine if these failures need to be exposed to the end-user in a more meaningful and actionable format. E.g. if the Stripe API call to process payment using a credit card failed due to payment method declined, then the Product Manager can decide to display an error message to inform the user about the same. Common response codes include:
200: Success. All good!
301: The resource being requested is moved permanently
400: Ran into a client problem. Another common error you may have seen on the website (Oops! 404 Error)
500: Ran into a server problem
Rate limiting: Companies may impose an overall limit on the number of APIs calls a partner can make. This is called Application rate limit/ throttle limit etc. This means in some cases if the partner exceeds the maximum number of requests allowed, then the processing may slow down or in some cases return an error indicating the limit has been exceeded. Some companies have a tier-based pricing model to accommodate partners with differing needs: All the information discussed above and more is captured by companies using API documentation. This documentation will help you and especially the engineering team understand the different functionalities.
As a non-technical Product Manager, you are expected to understand the APIs supported using the API documentation clearly to make trade-off decisions, determine features to build and support in the product
True
False
SUBMIT
As we all know the number of enterprise customer or consumer use multiple products or applications to complete their desired task or job. For companies to thrive in the complex and competitive world and provide seamless customer experience, speed to market is key to success. Companies integrate with third-party APIs to expand into newer product segments while providing better customer experience. API stands for Application Programming Interface and it enables products or applications to talk to each other. API is the code that determines whether a product or application can access the server, and what information is it allowed to access or modify. Companies expose APIs with supporting documentation for other companies (i.e partners) to integrate. Partners utilize these APIs to launch new features or enhance existing features faster to the market instead of taking multiple quarters or sometimes years to develop it from scratch. Any newly developed functionality that is available via the API can be leveraged with minimal effort by the partners. Some popular third-party APIs that are widely used: Stripe API:
Process payments by charging a credit card or debit card
Charge customers on a recurring basis
Offer discounts to customers for a specific period of time Whatsapp API:
Companies can provide real-time notifications and include documents or images into their message
Customer can interact with a company or vice-versa
Encourage customers to provide feedback instantly at the end of service
Although the partners can save multiple quarters or years of development and maintenance effort, integration with third-party APIs has its disadvantages as well. It is important to not have the entire product dependent or rely on third-party APIs completely. It adds significant risk and dependency on these companies with third-party APIs. These third-party integrations are usually available at a cost and some APIs charge on a transaction basis or limit the number of transactions. For e.g Stripe offers a standard fee for handling credit card transactions and a discount for large volume transactions. This cost cannot be ignored and needs to be considered as part of the development and maintenance cost by you as Product Manager Understanding the basics of an API will allow you as a Product Manager to engage with internal stakeholders, engineering teams, and customers when third-party API integration is being explored or used to provide new functionality and enhance the user experience.
As a Product Manager, it is important to collaborate with engineering and build a relationship that places trust in their abilities. This doesn’t mean you as a PM cannot be technically savvy. It simply means you need to utilize the skills to ask clarifying questions, understand trade-offs better, identify potential business opportunities to aid aid decision making. Below is a list of additional resources that can help you become technical enough
Need for Sprint 0: https://www.bmc.com/blogs/sprint-zero/
Web Application architecture: https://www.altexsoft.com/blog/engineering/web-application-architecture-how-the-web-works/
Native app vs. Hybrid app development: https://codeburst.io/native-app-or-hybrid-app-ca08e460df9
Introduction to system architecture design: https://medium.com/backendarmy/introduction-to-system-architecture-design-fcd4f327b6c9
Common software architecture patterns: https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
REST API Characteristics: https://www.restapitutorial.com/lessons/whatisrest.html
An effective prioritization framework helps the Product Manager identify key factors to consider while evaluating a feature request or project. When these factors are then combined methodically to calculate a score for the project or feature request under consideration,different ideas can be compared with each other in a consistent manner. The RICE scoring model developed by Messaging-software maker INTERCOM is one such framework. It is designed to aid Product Managers compare different items (roadmap initiatives, feature requests, new ideas) by scoring them based on four factors: reach, impact, confidence, and effort. The framework enables Product Manager to make objective decisions that are void of personal biases, and defend their rationale (remember Art of Saying “No’) in front of stakeholders
Below is a list of commonly used prioritization techniques:
Prioritization Frameworks enable you as a Product Manager to handle competing priorities and make objective decisions that are void of personal biases and give your team a prioritized backlog to focus while delivering value to customer and building a winning product
What is a bug and why does it matter?
A bug is an issue that prevents the product from behaving or functioning as designed. This is different from the product behaving in a way that the users don't expect it to. Let’s take an example: In the Sworkit app's exercise library each exercise has a video demo in a loop with instructions to read. When the same exercise is part of an active workout, it has audio instructions. It may be designed intentionally this way since exercisers browsing the exercise library can read the instructions while exercises working out cannot. If an exerciser reports an issue that audio is not playing on the exercise details page, I recommend understanding the user's reasoning.
A common misconception is new functionality development trumps bug fixing. This is not the case since Product Managers evaluate the bugs on a case by case basis to determine whether the bug needs to be fixed now vs. later. The first step is confirming whether the reported issue is a bug or a mismatch in user expectations. If the reported issue is a bug, then determine whether it's reproducible every time. Let’s take an example: Imagine using any messaging app and you are unable to include an emoji in the text. When you tap on the emoji it shows as selected but doesn’t appear in the text you typed. This issue is reproducible every time an emoji is selected regardless of whether the user tries to add it at the beginning, mid-sentence or end of the sentence.
We will spend the next few minutes understanding how does an issue's severity determines the priority to fix the bug.
As part of the go-to-market strategy you'll want to work closely with Marketing. You’ll want to start with your product’s value proposition to help you create the product positioning statements. Once you have the product positioning you can create the messaging.
As a reminder the value proposition for the product is created well before launch because it drives how the product that is designed and built.
Product positioning should be:
More specific than your product’s value prop
Focused on a specific target user, audience, or segment
Include differentiation that is meaningful for this specific audience
Combine these three parts into one sentence:
For {Target Audience}, {Product Name} delivers {Product Benefit} better than other products because {Evidence of Superiority}
Example
“For World Wide Web users who enjoy books, Amazon.com is a retail bookseller that provides instant access to over 1.1 million books. Unlike traditional book retailers, Amazon.com provides a combination of extraordinary convenience, low prices, and comprehensive selection.”
This example is from a time when Amazon was just focused on selling books. As the company has grown, Amazon's value proposition and product positioning has evolved.
Once you have determined your product positioning you can write your marketing message. The marketing message should communicate your product positioning in a concise statement that is easy for users to remember. Some tips to keep in mind:
Be clear and concise
Make it memorable
Consider including a call to action
Examples
“AirPods deliver effortless, all-day audio on the go. And AirPods Pro bring Active Noise Cancellation to an in-ear headphone — with a customizable fit. Find the right AirPods for you.” - Apple AirPods
“Venmo is a digital wallet that lets you make and share payments with friends. You can easily split the bill, cab fare, or much more. Download the iOS or Android app or sign up on Venmo.com today.” - Venmo
“Make Your Day. Real People. Real Videos. Text yourself a link to download TikTok” - TikTok
Some excellent examples would be:
a. Buzzfeed/Purina – “Puppyhood” Where you can see the unique relationship between the newly adopted puppy and his human dad. This Ad serves the purpose of getting you hooked into the message of loving rather than advertising their product Puppy Chow directly. https://www.youtube.com/watch?time_continue=97&v=L3MtFGWRXAA
b. Coca-Cola Happiness Machine – This ad succeeded in making the brand name associated with positivity such as smiling, laughing, and having a good time! Coca-Cola's “Choose Happiness” campaign got their consumers to share happy memories and feel special.
további példák: https://blog.bannersnack.com/emotional-advertising-examples/
USP or Unique Selling Proposition is supposed to highlight something about your brand or product that others cannot/do not offer. To create the messaging for this type of ad, you must figure out what sets you apart and if that resonates with the audience.
Apifonica, for example, offers companies an all in one platform where they can build superb customer communication service with SMS, voice, and social messaging.
Every product or offering “should” have a USP, how you get across to people depends on your marketing message.
Not every sale has to come from the advertising you’re offering. In fact, the best way to secure customers and keep them with you for a long time is by creating a psychological connection with your brand.
Using positioning in your message is the best way to compare yourself to your competitor. We talked a lot about positioning before; what we didn’t mention is that it needs to be believable and unique, above all things.
Otherwise, the message will go largely ignored by your target market. Here’s some advice to keep in mind when writing your positioning statement:
• It should be short – ideally fewer than 12 words, not counting your product or brand name
• It should be written in a simple language, devoid of jargons
• Should be adaptable to different types of media
• Should consist of one significant benefit
• The major benefit should be supported by three or four additional claims
• Should be unique, usable, imported, and most importantly, believable!
The generic ad is…well, one of the most obvious and commonly used. It focuses on selling a particular category rather than a specific brand or product. The goal here is to educate and give the audience something to think about; not hard sell.
Pre-emptive marketing is something anyone could use and get great results from. Yet almost no one does! This form of promotion is so simple; it’s almost scary. What you have to do? Just explain to your customers and prospects the processes upon which your business relies.
That’s it! It doesn’t matter if you’re the only person doing it; as long as you get the word out first, you win.
You’ve read a lot about marketing messages, but do you want to know about some great examples? Or the common elements all these examples have? Well, read on further!
In business, it’s never about you. It’s always about the customer. Weak marketing messages speak from the point of view of the seller, which is wrong! What you have to do is get into the minds of your audience and talk how they would.
WRONG: “Our best minds on the job have created this software that can be easily learned and implemented for your changing business needs.”
RIGHT: “It will take you no more than one hour to learn our software and put to use in your business.”
Weak marketing messages talk a lot without ever saying anything. Your message should be crisp and to the point!
WRONG: “In this fast-paced modern world where people barely get any time to cook, our cooktop stove will make your cooking experience more efficient.”
RIGHT: “Our cooktop stove gets your food ready in half the time of a regular stove.”
Weak and ordinary marketing messages sound like you could use them for any other product or service and that people won’t even notice.
WRONG: “With our social media management service, you’ll be able to free up time, save more money, and drive more engagement.”
RIGHT: “We’ll manage your social media so well that you’ll think you’re a rich celebrity.”
Jargons are best avoided as much as possible, barring few cases. You might think using industry-specific terms will give you a leading edge, but that isn’t necessarily true. Take these two examples, for instance.
WRONG: “Our 24x7 customer service team can assist you with web hosting migration and set up the necessary systems that will enable sales with minimal interruption.
RIGHT: “Our 24x7 customer service will migrate and setup your website so fast that you won’t even notice it was down!”
This is kind of obvious… but still needs to be said – don’t get clever with your marketing messages if you can’t make sense! If the average Joe doesn’t understand what you’re trying to say, your messaging has bombed!
WRONG: “We are the caviar to your high-ticket champagne campaign.”
RIGHT: “We will bring you way more leads for your high-ticket course offering.”
Playfulness in promotional messaging can leave a long-lasting impression if done right. And we stress on the “if done right” part.
WRONG: “Our software is so easy to use that even monkeys can do it!” (Seriously, don’t compare your audience to apes.)
RIGHT: “Our software is so easy to use that you’ll wonder if it’s the soulmate you were searching for all along!”
Final words
You might have a lot on your hands and you probably always will, but NOT taking the time out to craft an original marketing message may cost your company dearly! B2B messaging or otherwise.
If you wanted to learn how to convey a message, we believe this guide enough to get you thinking and probably even take the first step to creating a better advertising campaign.
So, go ahead and do your thing right now!
https://medium.com/the-marketing-playbook
Ideal Customer Profile (ICP): How To Create A Comprehensive Customer Profile
https://www.mykpono.com/ideal-customer-profile-icp-how-to-create-a-comprehensive-customer-profile/
https://www.mykpono.com/how-to-conduct-competitive-analysis/
ools and Resources and Techniques
As you conduct your competitive analysis, you can call upon many tools and techniques to get the job done effectively. I’ve mentioned a few throughout this guide, but here’s an at-a-glance list with additional resources.
Technology and techstack:
Datanyze - As mentioned earlier, this tool analyzes millions of websites and finds snippets of code that tell you what integrations, platforms and plugins are behind a company’s product.
Similartech - Similar to Datanyze.
Builtwith - Find out what technologies are being used on specific websites.
Company Profiles:
Crunchbase - Discover industry trends, investments, and news about your competitors.
LinkedIn - Where you can find out a competitor’s “biographical” info. Usually the best source to find an active employee count.
Angel.co - See which startups are hiring and for what positions.
Owler - Similar to Crunchbase.
DataFox - Its database shows which companies use more than 14,000 technology solutions, which you can search through using the Similar Company Algorithm.
Mattermark - See company profiles, key personnel, and growth signals related to your competitors.
Slideshare - Find competitor product or funding slide decks here.
Product reviews:
G2Crowd - The best resource to learn what customers think about your products and competitors.
GetApp - Similar to G2Crowd.
TrustRadius - Similar to G2Crowd.
Quora - See questions or discussions about certain products or topics that might be helpful in your competitive analysis.
YouTube - Find product demos and presentations.
Website traffic:
SimilarWeb - Provides website traffic comparison.
SEO & SEM:
SEMrush - Helps you understand your competitors’ focus in search engine marketing, including best-performing keywords, along with their spend.
https://www.mykpono.com/how-to-track-customer-acquisitions/
David Skok
Customer Acquisition: Maximizing your Funnel
SaaS Metrics 2.0 — A Guide to Measuring and Improving what Matters
Tom Tunguz
Sales Funnel Optimization For SaaS Startups
The Number One Objection In The Sales Funnel
Jason M. Lemkin
The Right Sales Metrics For Your SaaS Startup
Hire the Right Type of VP Marketing
Jacco van der Kooij
https://www.mykpono.com/strategic-communication-how-to-develop-strategic-messaging-and-positioning/
What is a target (or SDR-ready) score and how do you select one?
A target (or SDR-ready) score is a score that shows that a lead has reached a certain level of FIT and PAIN that qualifies that lead to be passed to the SDR team for further qualification.
SDR-ready = Lead Score with probability-to-close in the range of 10%-15%
Reaching an SDR-ready Score
What happens when your target lead score is reached?
When a prospect reaches an SDR-ready score, your SDR team needs to follow up with this prospect in a timely manner. Having a rule in place around how quickly your SDR team has to follow up can make this process more efficient. For example, you may put in place a rule that says that your SDR team has to follow up in the first 48 hours after a prospect has reached an SDR-ready score.
ASIDE: Companies often employ rules around how leads are assigned within the SDR team. For example, one of the more common methods is to assign leads randomly. Occasionally, companies have their sales team structured based on vertical markets, geography, or size of the prospect’s company (SMBs — small businesses vs. large enterprises). So it makes sense to consider these factors when directing SDR-ready leads.
Prospect qualification process leads to three outcomes:
Yes — Qualified: good FIT + high PAIN
Opportunity — Won
Opportunity — Lost
Maybe — Not now: good FIT + low PAIN or bad FIT + high PAIN
No — Never: bad FIT + low PAIN
What are the biggest mistakes when it comes to lead scoring?
Lead nurturing and lead scoring are an essential part of every SaaS company’s strategy, but few are doing it right. Let’s highlight a few main mistakes that teams are making with lead scoring:
Mistake #1 — Not tracking how prospects use your product and interact with your website
As a founder or Head of Marketing at an early stage company, you need to plan ahead and realize that even if your lead volume is extremely low now, tracking how customers use your product will help you conduct more accurate correlation and regression analyses to come up with more accurate lead scores later.
Mistake #2 — Overcomplicating the lead scoring process
You are not going to build a perfect lead scoring strategy from the start. So the best approach is to start simple and consistently adjust your score strategy: add new engagement metrics that show high correlation and remove scores that are too low. And let’s all agree to drop using A, B, C, D categories — it complicates processes and brings unnecessary confusion to the teams. There is very little value in spending time arguing whether a lead belongs to category D or C.
Mistake #3: Scoring too many factors
If your team is using a static approach (one-off) to lead scoring, then scoring over 20–25 engagement factors is over complicated and it is time to review your lead scoring strategy. Try to reduce your list of scored engagements to 15–20. One of the best ways to do this is to select a cut-off probability-to-close below which engagement won’t contribute to overall lead score. For example, if adding a picture to your document (I’m using Pandadoc as an example here) only increases chances for this lead to close by less than 5%, remove this action from your scoring list. Your team will be better off not scoring it at all. However, as we discussed in the previous section, with predictive lead scoring your team can run automated statistical analysis more often and you can expand the list of actions and engagements you score.
Mistake #4: Personal and organizational biases
Most organizations overweight factors based on personal experience and intuition. In order to implement effective lead scoring, teams need to employ at least some basic statistical analysis.
Welcome Drip Campaign
Goal: to complete the signup process and provide a guide to first value delivered to a prospect.
Since the goal of a welcome email campaign is to deliver the first unit of value (aka the ‘Aha’ moment), you can stop this series of emails at any time when user becomes an ‘active user’. At this point, prospects understand your product value proposition and the next step is to teach them how to get maximum value from your product.
User Onboarding Drip Campaign
Goal: to encourage prospect to complete user onboarding process, improve his or her profile and guide prospects through the steps required to receive first unit of value from using your product.
If a welcome drip campaign is concerned with answering why the user should consider using the product, then an onboarding campaign should guide the user on how to get maximum value out of the product by providing more profile information and/or finishing certain user flows.
For example, if a user submits a registration form to create an account on LinkedIn, he/she will receive a welcome email. If the user never comes back, he/she will receive a series of welcome emails to encourage them to come back. On the other hand, if a prospect has registered to LinkedIn and started using it but hasn’t completed their profile details, then LinkedIn’s user onboarding emails will be sent. These explain why and how providing more profile information can enrich a user’s LinkedIn experience.
Nurturing Drip Campaign
Goal: to nurture prospects into reaching an SDR-ready score or into signing up for a trial.
Prospects don’t always come through your free trial gate. Downloading a marketing asset, such as a whitepaper, industry research, case study or signing up to a webinar is another way to start a communication process with a prospect. Depending on your product and customer lifecycle process, nurturing drip campaigns can have two primary goals:
If you have a free trial 1) getting the prospect to sign up to that free trial;
If you don’t have a free trial: 2) getting the customer to an SDR-ready lead score.
If a prospect was disqualified by SDR, then you can pass this lead back to your nurturing campaign if you don’t have another drip email designed specifically for this scenario.
Product Engagement Drip Campaign
Goal: to get prospects back to the product and engage them in the product.
Product engagement campaigns are essential to a SaaS company with a freemium business model. Companies that use freemium models need to ensure that customers who aren’t paying for the product right now are engaged and increasingly use the product.
LEARN MORE: Whether a freemium model makes sense for your company is another conversation. Freemium models are easy for teams to roll out, but difficult to validate since customers don’t place the same value on using a product that they aren’t paying for. I highly recommend these articles by Jason Lemkin on the topic of freemium. The main idea is to figure out if your product has a sufficiently wide appeal to attract enough customers to make it worthwhile, since only a small percentage of free users will convert to paying customers: Why You Need 50 Million Active Users for Freemium to Actually Work Why is the freemium model dying?
Customer Onboarding Drip Campaign
Goal: to fully set up the customer’s team with your product.
Customer onboarding emails should guide your customer through your onboarding process. Does your product need to be integrated with a third party tool in order to provide maximum value?
If your product is more technical and higher priced, then your customer onboarding process will more than likely require a personal touch by your customer success team and implementation sales engineer. In this case, automated customer onboarding emails can be used to help you set up a kick-off meeting with customer success, educate your customers on onboarding expectations or invite new customers to a weekly product training webinar.
On the other hand, if your product is simpler and costs less, your customer onboarding emails should automate as much of the onboarding process as possible. Your team needs to identify the critical steps in the onboarding process and guide prospects through them in a more automated, cost effective way.
https://medium.com/the-marketing-playbook/understanding-customer-experience-in-saas-a9d7550c157e
https://intrinsicpoint.com/ch-8-product-led-go-to-market-strategy-overview-a30847392c6e
#1 Customer (WHO)
Questions:
Who is your ideal customer?
What pains do your customers experience?
Can you describe a day in the life of your target customer?
How does your product fit into the customer’s daily activities and workflow?
Outcomes:
Ideal customer profile (ICP)
Strategic messaging
#2 Market (WHERE)
Questions:
What markets do you want to pursue?
How big is your addressable market? Is it growing, stable, or declining?
Who are the biggest players in the market?
Outcomes:
Market segmentation and analysis
Competitive positioning
#3 Product Offering and Pricing (WHAT)
Questions:
What product are you selling? What is your product’s unique value proposition?
How do you describe your product’s value?
How are you different from your competitors?
What is your product pricing strategy (based on usage, features, capacity, seats, etc.)?
How do you know which features to build next?
Outcomes:
Product offering
Value proposition
Pricing strategy
Product vision
#4 Channels (HOW)
Questions:
What are the most effective channels to reach your target customers?
What are the most popular publications that your target customers read?
What social media channels do your customers use the most?
What channels enable the optimal CAC?
How do your marketing channels correlate with product signup rates and won deals?
Outcomes:
Demand generation strategy
Content and distribution strategy
Paid media strategy
PR plan
8.2 Setting the Foundation for Your Customer Acquisition Process
The previous four elements come together to form your customer acquisition process. Here are the key questions to answer in regard to this.
Questions:
How do you acquire your customers?
How do you retain and grow your customers?
What product delivery method should you use (free trials, freemiums, etc.)?
What details or plays do you need to include in your product, marketing, sales, and customer success playbooks?
How do you scale your customer acquisition process?
How do you consistently keep your CLV above CAC? And how can you keep increasing your CLV?
Outcomes:
Business model, including product delivery (freemium, trial, etc.)
Sales playbook - Selling strategies, including positioning and competitive insights - Objection handling, prioritization, and forecasting
Marketing playbook - Content and nurturing strategy - Customer segmentation
Customer success playbook - Customer onboarding and training - Retention and expansion workflows and strategies
Product playbook - Product vision/road map - Crucial customer journeys - Initial value - User onboarding and product adoption metrics
Goto Market Strategy video: https://www.marsdd.com/news/the-seven-step-go-to-market-strategy/
dia: https://www.slideshare.net/MaRSDD/speaker-slides-jan-30
https://intrinsicpoint.com/ch-11-the-anatomy-of-personalized-customer-engagement-423658ee6b44
https://intrinsicpoint.com/ch-13-saas-metrics-measuring-success-with-a-product-led-gtm-3a4996bc8e38
summary: https://intrinsicpoint.com/mastering-product-experience-in-saas/home
https://www.mykpono.com/how-to-design-marketing-campaigns-the-importance-of-market-segmentation/
Understanding Your Competition's Market Share
Total Addressable Market Review
As you think about your competition and the opportunities for positioning your product, you'll want to have a good grasp on the Total Addressable Market for your product. To help you review this critical skill we brought back Alex King, the Instructor from the Product Strategy course to review TAM.
TAM is a measure of the revenue opportunity for a product by estimating the size of the entire market
A larger TAM indicates a larger opportunity, with more demand for a particular product, but there are many other factors that will affect your product's success, including the strength of the competition.
TAM = Average revenue per user X total number of potential users in the market
There are several approaches to calculating TAM:
Top Down
You start with a high level view of the economy, and then narrow that down based on factors like demographics. For example, you usually will start will everyone in the world and narrow down that audience to people who are interested in your product.
Bottoms Up
This involves using known data points that you have (data from early customers and sales) that you could extrapolate to represent a larger market opportunity. For example, if you are already selling a product in one region and were considering selling it globally.
Value Theory
Generally used for new product categories where you don’t have much information to base estimates on. This involves conducting market research to understand how much people would pay for your product and how many potential customers you have.
Példa: https://youtu.be/RWaKByiHr9Q
Going down the rabbit hole: A reference to the long and chaotic journey of Alice in the book Alice in Wonderland by Lewis Carroll. In this context it means spending too much time following research threads that are increasingly distant from the topic you are trying to understand.
Who are your competitors? : Make sure you create a comprehensive list of competitors for your product. It is especially important if you are entering a new market.
Estimate your competitor's market share: Start by researching the target audience for the competitor. Research as much as you can and read multiple articles. You will probably need to extrapolate the available data to calculate the competitor's market share.
Don't be discouraged by strong competitors Just because there are strong competitors, it doesn’t mean that there is no room for one more, especially if you have better product.
Do your research and move on: Do not go down the rabbit hole and spend too much time doing research. You have a product to launch!
What value does the user get from using the product?
What does the product cost to produce?
What is your company's goal for the product?
What do competitors charge?
The price can't be higher than the value your users get from the product
In most cases, the price can't be lower than the long term cost to produce it
The product's price must be consistent with goals for the product
The price can't be higher than a competitor's price, unless you have a product that does a better job of meeting the user's need
Ad Supported: The product is free, but it generates revenue from advertisers. Cost-based pricing: The cost to produce the product is the base price and a mark-up is added. Dynamic pricing : Price changes reflect changes in supply or demand, e.g. surge pricing. Freemium: The basic product is free but you can purchase additional features or content, e.g. Dropbox. Price discrimination: Different users are charged a different price for the same product, e.g. US airline tickets.
Support oldalt csinálni: https://www.zendesk.com/support/
https://geekflare.com/create-kb-faq-tools/
User guides: https://stepshot.net/how-to-create-a-user-instruction-manual/
Gradual Rollout vs. Immediate Launch
A gradual rollout is the safest choice for a software product:
Allows you to closely monitor performance metrics to identify issues and make any necessary fixes before launching to everyone. Oftentimes you might run into bugs at scale that you could not catch or predict before rolling out
Gives you an early read if the product is on track to achieve goals
Easy to rollback the launch if any major issues arise
A full launch makes more sense for a:
Hardware product. Once a product is on the shelf it has to work for any user who purchases it. You can still do beta testing, but it will be more challenging to get a physical product to your target users. Additionally, you can't just "push" a new feature to an existing physical product like you can with software since you are limited by the capabilities of the hardware.
"No-brainer" product. It is a low-risk launch if your team is confident that the product will be well-received in the market and will work as expected.
It also may make sense to do a full launch to meet a product goal or a legal requirement. There may be times when leadership decides that the need for immediate revenue is worth the risk of launching an imperfect product. Or changes in law, that require product updates for compliance, like GDPR privacy regulations in Europe.
How to Manage a Gradual Rollout
For a new product, a gradual rollout involves launching the product to a small or geographically contained group of users
For a new feature on an existing product, you'll want to make the feature available to a select group of users of the existing product.
You'll want to be strategic about the number of users you start with. You need enough users to get a good read on the users' reception of the project and to make sure any issues are uncovered. You will almost always want to start with 1% on the first day
After launch, monitor KPIs and user feedback
No issues -> release the product to more users.
If KPIs look problematic or issues appear in user feedback, halt the rollout or roll the feature back. Fix it and try again.
So far we have talked about emails you send to your team and others in your company. There is a different type of email that is written to send to people outside your company to increase the buzz for your product.
When to Use: External launch emails can definitely be helpful for bigger product feature launches. they don't always make sense for smaller features or behind the hood launches/improvements that aren’t visible to users.
Purpose: While an internal launch email is more focused on congratulating the team, an external is more focused on driving adoption of the new feature.
Target: External emails are sent to anyone who might be interested in your product. In many cases, this can be your existing user base or users who have joined a waitlist to hear more about your product.
What Should be in an External Launch Email?
External emails should include much more marketing messaging about the product or feature and its value.
What the product or feature is
Why users should care/be excited about it
How users can use it
When users can expect it (if it's not available immediately)
Where to go for more info/help
Learn more about external launch emails here:
