THE PRODUCT BOOK SUMMARY

Виталий Бердичевский
2 февраля, 2023
1.2К
25 мин.
0
Автор книги

The product book.

What is Product Management
Strategically understanding the company
Persona
Use cases
Metrics
How to choose a right goal for metrics
How to measure metrics
Roadmap
Creating an opportunity hypothesis
Kano model
MOOVER.IO’S HYPOTHESIS (EXAMPLE)
Validating hypotheses
External validation
Customer development
Interviews
Surveys
MVP
How to prioritize
From idea to action
Defining a minimum viable product
Product requirements document
Breaking Down a PRD
Using a PRD
Example of PRD
Working with design
The design process and skills
User testing with prototypes
Working with design
Dieter Rams’s 10 principles of “good design”
Design Relationship Skills
Working with engineering
Product/engineering relationships
Bringing your product to market
Understanding customers
Product messaging
Finding Your Company’s Voice
Putting the message pieces together
Going to market
Go to market plan (GTM)
4Ps Framework
The Customer Life Cycle
MOOVER’S GTM PLAN (EXAMPLE)
Finishing the product-development life cycle

What is Product Management

Who is a Product Manager
Product manager (PM) represents the customer.

The PM job is to provide clear communication between all stakeholders while keeping the end goal—making the customer awesome—in everyone’s mind

Customers buy and use products because the products address their needs.
Done properly, the products let the customers be awesome.
The end result of representing the customer is that a PM helps the customer be awesome.

The product triangle.

Differences between the roles

  • Project manager owns the schedule and helps ensure the team is on track to meet any deadlines
  • Program managers generally focus more on the “getting it built” side, working closely with Engineering and Operations (”Super Project Manager”)

The product development lifecycle

  1. Finding and planning the right opportunity
  2. Designing the solution
  3. Building the solution
  4. Sharing the solution
  5. Assessing the solution

Strategically understanding the company

One of the first things a great product manager should do before even thinking about a product is to understand the company that makes it.

Why Does the Company Exist?
MUST WATCH: TED TALK: How Great Leaders Inspire Action

Why? How? What?

Apple: “With everything we do, we aim to challenge the status quo. We aim to think differently. Our products are user-friendly, beautifully designed, and easy to use. We just happen to make great computers. Want to buy one?”

  • Why? — challenge the status quo
  • How? — being user-friendly, beautifully designed etc
  • What? — selling great computers

Customers will pay for your product because it makes their lives better, not because they want to give you money.

What product are we building?

Persona

A persona is a fictional, typical customer, and defining key personas lets you segment your customers by highlighting the things your customers care about that are relevant to your product. Personas are tools to help you understand your customers, they are not actual end customers.

Example:
When we say, “Can my mom use it?” we’re actually asking if the product is user-friendly enough that someone in the “mom” persona can use the product to achieve a goal without breaking it and without asking for help.

A way to envision these customer’s priorities is to imagine the customer’s journey.

  • What problem is a given persona trying to solve
  • What does he do when he tries to solve it, and what happens as a result?
  • Tell us a story about the customer.

Focusing on a common problem, pain, or desire yields — is a better segmentation than demographics.

Personas contain demographic information only if it’s relevant.

For example, Airbnb’s “host” personas probably don’t include how much 35 each person makes per year, but they likely do include why a persona is interested in renting her place out.

Example:
Only demographic approach
Jill—a 23-year-old in a major metro who has a roommate, loves travel, and is very into the DJ scene. Jill is thinking about buying her first car.

That’s a great starting point. But it’s barely the tip of the iceberg.

What persona needs approach

  • Does Jill care about what the car says about her, or does she care about fuel efficiency?
  • Is Jill focused on saving money, or on resale value?
  • Does Jill care about the car tech, or just that it gets her places?
  • Further, does Jill enjoy the research process, or does she just want to be pointed in the right direction?
  • Is she going to make a little comparison spread- sheet for herself, or just wing it?

The goal
Ultimately your goal with each persona is to have enough information and detail about that category of customer that you can imagine yourself in this person’s shoes.

This will help you empathize with that customer, understand his pain points, and think about ways your product can solve that pain.

How to start
Just make your personas rough at first, and as you learn more about your customers, refine the personas, perhaps dividing them up and creating a new persona when key differences appear.

Persona’s template:

Persona’s template.

Use cases

Use cases are simply how a company expects each persona to use the company’s product to achieve a goal.

1 problem persona wants to solve = 1 feature

1 problem persona wants to solve = 1 feature.

Metrics

Metrics are the measurement of different aspects of your product

Success metrics = key performance indicators (KPIs), are the key metrics that define how we keep score

Success metrics are defined by current strategy and goals.
Success metrics are supporting goals.
When goals change, what was a success metric one week might just be considered a regular metric the next week.

Example:

  • Your current company success metric is brand awareness, a common initial success metric for startups.
    In that case, your product success metrics will include number of downloads of your app, visits to your website, and so on: metrics that indicate people are aware of your company and products.
  • Later on, your strategy might shift to making your app part of people’s lives, in which case your success metrics will focus on engagement: Of those who downloaded the app, how many complete a core task?

How to choose a right goal for metrics

Phases:

  • engagement
  • retention
  • self-perpetuating

Engagement phase
The goal is to get customers using your product and completing the core action, like posting a photo to Instagram

Retention phase
The goal is how frequently those customers use the product in a given time period

IMPORTANT:
Products that don’t encourage customers to continuously use them are easily replaceable

Example: The bigger the audience you’ve built up on Twitter, the more you’d have to lose by stopping using Twitter and trying to rebuild your audience on another network.

Self-perpetuating
The goal is how often people complete loops to be engaged and to engage other people.
Example: Pins in Pinterest encourage both new customers to pin something and existing users to return to the product

How to use this approach:
Look at the number of weekly users completing the core action and the percentage of weekly active users completing the core action over time. This shows growth from the size of the cohort, engagement from the ratio of users completing the core action, and retention from your performance over time.

Types of metrics

  • Vanity metrics
  • Actionable metrics

Vanity metrics are those that sound useful, and might be great for some other business need, but don’t help us measure product performance.

Example of vanity metric (engagement phase)
When you’re launching a new product, say an app, as a product manager your goal is to have people completing the core task. Maybe 1 million people downloaded your app on the first day—congrats! That sounds awesome, right? While getting someone to be aware of and download your app is the first step, it doesn’t mean they actually opened and used your app—things look very different if only 10 people actually completed your app’s core task.

Actionable metrics are real data we can use to make decisions.

Now that we know only 10 people completed our product’s core task, we can look at other metrics to try and figure out why so few people were engaged with the app.

How to measure metrics

  • Bit of code
  • The Net Promoter Score (NPS)

The Net Promoter Score (NPS) — measure satisfaction (how likely they recommend)

  • Question to customers: “On a scale of 1–10, how likely is it that you would recommend [brand] to a friend or colleague?”
  • Promoters rank your brand 9 or 10 and are “loyal enthusiasts who will keep buying and refer others, fueling growth.” These are the people you want!
  • Passives will rank you 7 or 8 and are “satisfied but unenthusiastic customers who are vulnerable to competitive offerings.”
  • The Detractors score you from 0 to 6 and “are unhappy customers who can damage your brand and impede growth through negative word-of-mouth.”
  • NPS is the percentage of promoters minus the percentage of detractors, giving you a score from –100 to 100

Roadmap

Roadmap — is a document that shows what the company/product is doing now, what the company/product plans to do over the next N months, what the company/product plans to do later, roughly how much effort each high-level task will take, what products the company will create, and what features they will have, etc.

What’s going on around that company:

  • What are other people building?
  • Who are the company’s main competitors?
  • How are their target use cases, personas, and end customers different?
  • How are their products different?
  • How are they winning or losing compared to another company?
  • Are you aware of who’s out there?

5C analysis

  • Company
    • Why Does the Company Exist?
    • How Do We Know If Our Product’s Good?
    • What Else Has Been, Is Being, and Will Be Built?
      Example of the business goals: to find ways to improve customer satisfaction, and to grow the business.
  • Customers:
    • Who are the people buying this product?
    • What are the market segments?
    • How big are they?
    • What are people’s goals with buying this product?
    • How do they make buying decisions?
    • Where do they buy this type or product?
  • Collaborators:
    • Who are the external people who make the product possible, including distributors, suppliers, logistical operators, groundwork support personnel, and so on?
  • Competitors:
    • Who is competing for your customers’ money? This includes actual and potential competitors. You should look at how they position their product, the market size they address, their strengths and weaknesses, and more.
  • Climate
    • These are the macro-environmental factors, like cultural, regulatory, or technological trends and innovations.

Creating an opportunity hypothesis

A key part of your role as a product manager is understanding your customers and their problems and needs, and making sure what you’re building next is right for them, be it a feature or a new product.

You have opinions, not facts — Generally, less than 50% of ideas you’ll execute—even awesome ideas—improve the metrics they’re supposed to improve.

customer development, which essentially says that whatever you come up with at first is an opinion; you might be wrong, and you need to interact with real potential customers to learn the truth ASAP

Great PM needs to help the customer be awesome, and you want to focus your time on building things they need!

How to create the best possible hypothesis about what your customers want

  1. to establish your goal for this product development life cycle iteration. Is your company focused on acquiring new users? Does it want to improve revenue?
  2. to think about how to achieve that high-level goal with an actual product
    • Do you want to iterate on an existing product, finding ways to improve it?
    • Do you want to build something completely new—a blue ocean?

For example, the company might want improved customer satisfaction, which could translate into “getting customers to read more articles”. OR when Facebook changed the Like button to have different types of reactions, such as love, sadness, and anger. If someone’s dog died it’s better to set a sadness reaction instead “like”

two ways to determine what we want to do to achieve our goal:

  1. qualitative reasoning
  2. quantitative reasoning

Qualitative reasoning — involves more abstract concepts like looking at your overall product vision.

Example: Lyft wants to increase customer retention.
We can turn that into a specific product goal by focusing on how to decrease the number of rides cancelled — fewer cancellations means more passengers served and happier drivers, which means more payment.
This will also come by tweaking the current product, rather than building something new.
When you cancel a ride in Lyft, you need to specify a reason. A PM at Lyft could look at the responses and come up with ideas about how to mitigate those reasons.

Quantitative sources are also nice because we can compare the data before and after the change, and determine if it was successful

Quantitative reasoning — involves looking at data, interpreting it, and using that analysis to determine what to do next

Metrics and Analytics

  • When working with metrics, start by asking yourself if you’re happy with where your success metric is—is it at the right level to effectively achieve your product goal, and if not, how can you improve this success metric?
  • Not all metrics are success metrics.
    • If our success metric is how many people complete a purchase, but we’ll also measure how many people add items to a cart and how many people tap the checkout button. Other metrics (tap the checkout button etc) help us better understand what happened in the funnel
  • Analytics — the process of gathering and analyzing these metrics collectively

AARRR acronym metrics:

  • Acquisition: How the user comes to your product.
  • Activation: The user’s first visit to your product and her first happy experience.
  • Retention: The user liked your product enough to use it again
  • Referral: The user likes it enough to tell someone about it.
  • Revenue: The user finds your product valuable enough that she pays for it.

Here are a few common, interesting opportunities you’ll find for mobile and web apps in metrics:

  • A low time on a screen and a high bounce rate—people who leave after viewing this content—on a page that’s supposed to be important likely indicates a mismatch between expectations and reality.
  • The content wasn’t what the customers expected, so they left.
  • A long time on a screen and a high bounce rate could be fine if the page is a long article, but if it’s a page with very little content but lots of links, it could indicate the screen is unclear.
  • A high number of screen views could indicate that this part of the app is important, therefore you need to optimize it well.
  • A low number of views could mean this section is hard to find.

Intercom’ feature audit.
Important to exclude administrative features like recovery password etc.

A sample Intercom feature audit table.

Analysis methods:

  • Segments — browser, age, region etc
  • Cohort — like Segments + time (what have happened after we launched tutorial for new users)
  • Funnel — What happened with a user during the workflow. Some visitors go to the product page, fewer users hit the ”Add to the cart” and fewer users hit ”Pay”.

Analysis methods.

Feature A, with a very low satisfaction, will likely be the first place to focus, instead of Feature B, which is more important but has a moderate satisfaction.

Kano model

Principles

  1. Value attracts customers.
  2. Quality keeps customers and builds loyalty.
  3. Innovation differentiates your product from others and keeps you competitive.

Feature categories.

  • Basic features — what customers expect to have and will be unhappy if they haven’t. Gas pedal in the car, toilet paper included at Airbnb etc. If they have more of a basic feature they won’t be happier if they haven’t — they will be unhappy. It’s hard to define basic features because customers don’t mention them in the interview — we can find out about a lack of basic features from complaint systems, lost-customer surveys, and attrition analysis.
  • Performance features (satisfiers) — customer’s satisfaction with these features will be proportional to how well you execute them. These are fairly easy to find information about by talking with customers, be it through interviews or surveys, because they’re things a customer will often explicitly ask for, compliment, or complain about.
  • Excitement features (delighters). These are the unexpected “wow” features that become product differentiators, innovations, and unique selling points, such as the iPhone’s capacitive touch screen, Android’s notification panel, or Wi-Fi on an airplane midflight. When you do these well they create significant excitement and delight. If they’re missing, customers stay neutral: they don’t know what they’re missing. These features are the hardest to discover and really require an understanding of customer need. They’re often found only qualitatively.

In general, the first version of your product needs to cover the basic features. Each successive generation should focus on a mix of satisfiers and delighters, along with making sure you’re continuing to cover the basic features.

To find feature opportunities answer the questions:

  • What features are about meeting basic expectations?
  • Are they meeting expectations?
  • Have you covered all the basics? If so, move on to a satisfier or a delighter.

MOOVER.IO’S HYPOTHESIS (EXAMPLE)

Introduction to the problem
The moving company does a follow-up call to plan details. Based on customer-satisfaction surveys, it has been found that this is the thing that current customers who give the company a lower NPS complain the most about.

Preparation for solution

  • Company goal: Improve customer satisfaction.
  • Product goal: Reduce friction in the current workflow.
  • Opportunity hypothesis: We can improve satisfaction for Really Busy Rob if we eliminate phone calls with the moving companies and consolidate communication into an in-app messaging tool.
  • Success metrics: Since customer satisfaction is our main goal, we can measure it by tracking our NPS.
  • Other key metrics: Other key factors that indicate if customers areachieving their goals and using this feature are the percentage of customers who complete the bid-to-completed-move funnel and the number of messages sent per customer.

Validating hypotheses

To validate hypothesis ideally to build the product. It’s good if it’s about bug fixing or very small part of the product.

In other situation (complex part of the product or major feature) it’s better to use customer development technics:

  • Directly via interviews
  • Indirectly via surveys

Also we can build MVP of a new feature (even if we need to do manually the workflow for the first time) and run A/B test.

Checklist of questions that will help start validating an opportunity:

  • Is this opportunity in line with our vision?
  • Does it support the product’s vision and core function?
  • Can we do it well with our capabilities (or is it feasible and desirable to expand our capabilities to meet the opportunity)?
  • How does it contribute to our key metrics?
  • Do we have any data, be it from analytics, surveys, or bug reports, to support this opportunity?
  • Is it required to meet a critical business initiative?
  • How does it contribute to our users’ winning?
  • Is it on our roadmap for this year, even indirectly as part of something else?
  • Will it matter in two years? (It’s OK if the feature is to address an immediate need, but you’ll want to limit those, as you want to prioritize things that have a higher value over time.)
  • Will everyone benefit? If it only helps a niche set of customers, is it worth the cost?
  • If it succeeds, can we support it?

The model acts as a reminder that your users already have a perspective on the problem you’re solving, a way in which they measure success, and a means by which they work towards that desired state.

The model acts as a reminder that your users already have a perspective on the problem you’re solving, a way in which they measure success, and a means by which they work towards that desired state.

CURRENT STATE

  • What’s the users perspective of the Problem? How do they think and feel about it?
  • Journey: What are the current steps they take? This is often a flow of the application but might also include taking steps outside of your app or using competitors.

MOTIVATION

  • What about the current solution they not happy with
  • What about the new solution is uniquely appealing?
  • Do they believe that following the journey will get them to the desired state?
  • Do they believe they have the ability to do what will be asked of them at each step?
  • Do they believe they will be supported if they run into the problems

HINDRANCES

  • What about the current solution do they like?
  • What about switching to the new solution worries them?
  • Desired state: how do they measure success? How does getting to this state help them to achieve other larger goals?

External validation

  • Reading industry reports
  • Google trends — to look what people search
  • Researching a specific interaction mechanism of other apps
  • Empathy (be like end user) — but you will need to make sure the way you use product is similar to how your customers use it.

Customer development

What is the customer development:
It’s a way to validate if the people you think are your customers truly are the right customers and confirming you’re on the right path.

This includes:

  • finding out what problems customers are seeking to solve
  • what they’re doing right now that either creates those problems and tries to solve them
  • what they’re able to do (technically, financially, socially, etc.)
  • how they find out about and decide if a new product/feature is worth it.

What is NOT a customer development:

  • a way for people to give you a wish list.
  • It’s not a focus group to only see how people respond to ideas.
  • It’s not a place to observe how customers use your prototype.
  • It’s also not a replacement for product vision.

Interviews

Preparing to interviews

To get started, write down a list of what you know factually and what you’re assuming about our customers, including their needs and how
your product satisfies them.

Canvases to explicit opportunity hypothesis:
I believe that experience when doing because of , and alleviating that pain would let the customer , although she’d have to .

MUST VIEW: Template for interviews

The most valuable thing you can do is to get the customer to tell you about how they currently deal with whatever problem you’re thinking about solving.

Questions example:

  • How often do you go to the gym?
  • What diets have you used in the past six months?
  • Do you pay a handyman or fix things around the house yourself?
  • When did you last order delivery?
  • Did you make a restaurant choice based on who delivered?

Similarly, asking what someone will pay is useless because no one will give you an honest and meaningful answer. But it’s useful to ask what they’ve already paid to try to answer this question.

it’s better to find out about how they deal with the fundamental problem you’re trying to solve. The simplest way to ask a question like this is, “Tell me about how you do today”

  • How often have you dealt with this topic?
  • What were you doing right before this topic came up?
  • Once you finished, what’d you do?
  • How long did it take to deal with the topic
  • What made you buy the product relevant to this topic?
  • How often do you buy the product?
  • Where do you go to buy the product?
  • If you could wave a magic wand and be able to do anything you can’t do today, what would it be? Anything you can imagine is possible. What would you like?
  • To better understand what customers values: If were to happen but it meant that , how would you feel?
  • To find out about any limitations the customer has: I want to tell you a story about how we imagine someone like you using the next version of our product based on what we’ve heard from other customers. Please interrupt me if you have questions, if you disagree with anything I’m saying, or if I’m just plain wrong!
  • At the end of the interview: Is there anything else about that I should’ve asked about?

Important:

  • try to ask open questions to get a context
  • avoid showing any prototypes because the conversation will be about what we have rather what the customer needs

Logistic

  • What’s the last date where interviews can give you useful information?
  • What level of quality and confidence in the results do you need?
  • What’s the right medium for the interviews: in person or on the phone?
    In person is the best, on the phone is easier but without expression emotions, video chat can solve this problem but it depends of customer tech savvy
  • How much time will each interview take?
    20 minutes is better
  • Should you pay your interviewees?
    50-100$ per hour is a normal price. A gift, not cash. For some customers, the value will be product improvement + give them early access to a new version of the product (help them feel special)

Where to find interviewees

  • Look at your connections first. Make your request explicit: tell them why you’re asking, make it clear what the interview would involve (time, format—like on site vs. phone call), and mention how helpful it would be
  • If you’re asking a connection to reach into her network, create an easily forwarded email so that it’s simple for your friend to press “Forward” and send the email to anyone she knows without adding a long note.
  • Social networks — LinkedIn, Quora, subject-relevant forums, Twitter. If there’s a particular physical place your customers hang out, try going there in person and talking with people, or at least posting a notice asking people to contact you if they’d be willing to provide input.

After all schedule the interview. Write clear instructions how to find you (if on-site) and remind the day before interview start.

Conducting the interviews

  1. Make it clear — there are no right or wrong answers
  2. Call by name (do not call “customer”)
  3. Start with simple questions (small talk), then continue
  4. Listen, do not interrupt, ask if you have questions (Customer: “I hate waiting”, You: “Is it OK to wait 1 min and is awful to wait 5 min?”)
  5. Do not defense if customer criticize your product
  6. Make sure to note any non-verbals, and star any emotional utterances (“I hate/love this”). One exception to the verbatim-recording goal is if they say “maybe”; write it down as “no.”

Drawing Conclusions from Interviews
Each interview should help you figure out if your hypothesis addresses a valid pain point the customer has: whether the customer has tried to solve that pain point before, whether the customer cares enough about this pain point to want it fixed, and if there’s nothing that’d stop the customer from using your solution.

Surveys

The data surveys provide isn’t as high quality as that from customer interviews, but it’s a low-cost way to see if our conclusions from customer interviews scale to a large number of people.

  1. Start with goal: to further validate my hypothesis by seeing how many people have this pain, have invested significant resources trying to solve it, are unhappy with the solution, and could implement my solution
  2. Make a survey short — few minutes to answer
  3. Keep questions clear — instead of Q4 (fiscal or calendar) use months
  4. Start with broad questions, move into specifics, and close with a place for the customer to add any extra thoughts. Group related categories together, too, to help the customer with context.
  5. aim for actual instead of ideal-self ques- tions—i.e., ask what customers have done, not what they might do. Also avoid leading and loaded questions. For example, rather than asking if the customer has recently used online billing tools, ask how a customer pays bills, with an option for online billing.
  6. ask a user to rank her thoughts about specific items are useful to figure out how many customers value this potential pain point and how much, and to analyze how trends change over time. For example, “Are you completely dissatisfied, slightly dissatisfied, neutral, satisfied, completely satisfied, or n/a with your ISP’s download speed?”
  7. Ask for specifics when a bucket has a lot of variabilities. For example — age. Instead of 18-25, 26-35 etc, specific ask the age

Executing surveys
Tools for creating surveys: Google Forms, SurveyMonkey, Typeform, etc.

Analyzing Data
Run your survey until you feel you have statistically significant results or until you stop getting new/useful/different results.

Validate data — what to do with incomplete surveys? (ignore or dig deaper — why users stopped answer)

Portioning data — do you want to do any partitioning based on background questions? (People who listen to streaming music daily may have different answers than people who listen once a week)

In general, like with interviews, you’re still looking for anything that validates or invalidates your opportunity hypothesis. But the other aspect you want to look for with a survey is how many people feel this is a pain point, and how significant of a pain point is it.
If everyone agrees it’s a pain point but no one has spent any time or money trying to solve it, your opportunity is likely not worth building unless a solution is very cheap to build or you have reason to believe your solution will make customers realize the pain point is bigger than they thought.

Try focusing only on data that invalidates your hypothesis before looking for data that validates it.

Experiments
A/B testing
Tools for A/B tests — Optimizely

MVP

Different types of MVP:

  • simplest MVP is a preorder MVP: build a product/feature website > button buy > after that note that product/feature are coming soon > take an email to inform when it become ready
  • concierge MVP: build website > let customers interact with website> do all the work manually to figure out what customer really need
  • Wizard of Oz MVP: like concierge MVP, all work manually but like it’s automatic
  • fake door MVP: write about new feature in the feature list > add UX elements to trigger the interaction > text ”feature is coming soon” if someone try to know more about > see how many people use the fake door. If only a tiny percentage do, reconsider if it’s worth pursuing this opportunity, depending on the value of those customers vs. the cost of implementing the feature.

How to prioritize

Values vs cost

Use an exponential series rather than a linear one—i.e., use 1, 2, 4, 8, and 16 rather than 1 through 5.

Next, for each opportunity, figure out a score using score = value/cost. Focus on the highest-scoring opportunities first, as they provide the most value for the lowest cost.

Example:
Value = 10, cost = 5, score = 2 — do first
Value = 5, cost = 10, score = 0.5 — do second

From idea to action

Imagine the future.
Before writing a line of code start writing an internal press release of future product.

  • Structure of internal press release
    Headline:
    In one (max 2 sentences, if so, then headline and sub headline):

    • key target market
    • how it helps them win
    • and a tentative product name that the target market can understand
  • Summary paragraph:
    The first full paragraph in your press release should call out:

    • the most important aspects of the product
    • and how it solves the customer’s problem.
  • Problem and solution:
    The next section should elaborate on the problem and your solution in more detail.

    • Spokesperson quote: Include a quote from you, the product manager, about how this product is great for your customers.
  • Customer quote:
    Include a quote from a fictional customer about how the product fits into his life.
  • Conclusion/how to get started:
    • Explain how new customers can find/sign up/buy/use this product,
    • and pull everything together with a call to action.

Writing an internal product review
Focus on what will customer experience with the product:

  • Be honest about tradeoffs — maybe product will be amazing but also pricier then the competitors
  • Think about features the reviewer will focus on and will ignore
  • The review should be short (not about all features)
  • Mostly importantly, the review should have a conclusion about why a customer should buy your product, especially over a competitor’s or whatever the customer is doing now.

Defining a minimum viable product

The parts of product that we think will deliver the most value to customer (from internal press release and internal review)- should be built first

Important: minimum is NOT bad

Minimum simply means the fewest buttons or features you need to build to deliver the most important value.

How to come up with MVP

  1. Write down the overall thing you’re doing and why you’re doing it.
    • what value will it deliver for your customers
    • and what goal will it help you achieve
  2. List the features you think you need to achieve that top-level goal, along with why that feature’s important
    • Rather than just writing “cloud data store,” write “cloud data store so that customers can access their data from any device.
  3. As you work on this step, you’re not allowed to add any new feature category NOT listed in the press release and product review (you can define features in more details but not to add new major features)
  4. Look through feature list and cross out whatever items customers don’t actually require to address their core need

Product requirements document

Breaking Down a PRD

These are the key sections in a PRD:

  • Title: Give this project a distinct name.
    Unique code name or something like “Moover Web App” for the first version
  • Change history: Provide a description of each important change to the PRD, including who changed it, when, and in what specific way.
    Wiki tools provide change history automatically
  • Overview: Briefly, what is this project about? Why are you doing it? Objectives: What will this let the customer do? What are our high-level internal goals for doing this project?
    • First paragraph from internal press release
    • Bulleted list what we want the customer to get out from the project
    • What internal goals we want to achieve
  • Success metrics: What are the success metrics that indicate you’re achieving your internal goals for the project?
    List of the most important metrics you will need to be able to measure to figure out if you’ve achieved our goals. Example: increase our user base by 10% (or add ???)
  • Messaging: What’s the product messaging marketing will use to describe this product to customers, both new and existing?
    explain the product to a current or new customer in a short sentence
  • Timeline/release planning: What’s the overall schedule you’re working towards?
    Rough estimates. Ask marketing sales team.
  • Personas: Who are the target personas for this product, and which is the key persona?
    define them here so a reader understands what the eventual customers will be like, and their goals.
  • User scenarios: These are full stories about how various personas will use the product in context.
    • Combine personas, customer development, and empathy
    • NOT bullets of text BUT story. This helps to build stronger empathy among the team
    • Focus on customers underlying needs and motivations
    • How will a customer first encounter this product and learn to use it?
    • Be realistic: instead “after using the product she tell all her friends and they buy the product too” use “Because this is an ongoing problem and the customer was so happy with our trial product, she signed up for the monthly plan.”
    • do not define in too much detail — leave the PRD focused on goals and requirements rather than specific solutions to a problem. Example: rather than describing how a customer turns a doorknob on a restroom door to leave, describe how the customer exits the restroom with clean hands

Structure of great story:

  1. Set up the world
    • Describe the persona
    • What situation is he in
    • Why are the key details we need to know (is he in the car, holding a baby…)
  2. Inciting accident. The motivation to use
    • What problem causes the persona to need your product, or to need a specific feature in your product if he was already using it in the setup?
    • Why does he think to use your product?
    • If he’s a new customer, how will he find/buy your product?
  3. Action section
    • When the persona is using the product, what’s he doing?
    • What happens as he tries to use it?
    • What roadblocks or conflicts does he encounter while trying to use the product
    • and what product features help him eliminate those roadblocks?
  4. Result
    • how does his world change?
    • It’s fine if it’s a small change, not every product is sav- ing the world.
    • Example: Having scratched his itch with the Acme backscratcher, Jeff puts his backscratcher down within easy reach, knowing it’s the perfect tool to scratch his back

Using a PRD

  1. Start private draft (Word, Google docs)
  2. Share with small group for feedback
  3. Share for other team members and start discussion. Important: you should approach these discussions from a perspective of “This is what I believe is right. Did I miss anything?” as opposed to “What do you think we should build?”
  4. Start sharing PRD broadly (corporate wiki etc)
  5. If you asked to present the PRD on the board meeting- don’t read the PRD or your user scenarios to the audience verbatim. Instead, distill the PRD down to the essence of what you’re doing and why, and present that information to the group.

Example of PRD

Sample Press Release

Move on Your Schedule With Moover’s Latest Update

The leading app-based moving service now provides easy in-app communication with moving companies.

Moover, the iPhone app bringing moving into the smartphone age, is proud to release its latest update. This update removes the need to exchange phone calls and emails with moving companies, completely digitizing the moving experience. Rather than having to schedule a phone call and email photos back in forth, with Moover you can now message with each moving company in-app, dealing with questions and contracts at your convenience to finish planning your move.

Since its release six months ago, Moover has transformed urban moving. Instead of having to search out moving companies, call them, and deal with an annoying game of phone tag just to get an accurate bid, Moover brings moving companies to you. Enter a few details about your home and when you want to move, and moving companies will compete for your business, with bids appearing in-app.

The latest update simplifies the process by providing in-app messaging with each moving company so that you can share photos and address your home’s unique traits. This new feature ensures accountability and lets Moover guarantee that the bid you receive is the price you pay.

Product manager Jane Doe believes, “in-app messaging is the biggest win for customers since we released Moover. It means you can provide answers to the moving company’s questions when you’re home at night, thinking about the move, instead of having to stress during the day to call the moving company at work between meetings.”

Recent customer John Smith tried a prerelease version of messaging and “started planning the move at 11pm, sent photos of the apartment two days later at 2am, and moved the next weekend.” He went on to share, “This is the third time I’ve moved, and even though I have more furniture now than ever before, this was the first hassle-free move I’ve had.”

Download Moover from the App Store today to get started planning your first hassle-free move.

Sample MVP List

Goal: Add in-app messaging so that customers can stay in-app and don’t have to exchange phone calls/emails with a moving company to get a bid or complete a move.

MVP Requirements

Features We Removed from Moover’s MVP

Sample PRD

Title
In-App Messaging

Change History
First version

Overview
Our mission is to be the Uber of moving companies, making it convenient to book a move on your smartphone. We’ve done a great job bringing the first part of moving to your fingertips—finding vendors and getting initial rough bids—but we’ve found that there’s a second part. Despite using Moover, our customers still have to talk on the phone to figure out details, get exact bids, and finalize their moves. That means move prep still has to take place from 9 to 5. We’re going to bring the second part of the moving process into the smartphone era by adding in- app messaging. This will make it convenient for our moving companies and customers to interact to plan details, allowing the moving company to message from 9 to 5 and the customer to reply when convenient.

Objectives

Success Metrics

Messaging

Timeline/Release Planning

Personas
Our primary target is Ant Moving, our mid-sized moving company. They’re the ones who will have to ask for more information, so we need to make this easier for them than using the phone.

Really Busy Rob is our second target, our persona who doesn’t mind paying a premium to use app services over traditional services. We’ll need to provide an intuitive messaging/notification system so that he doesn’t have to look up a help page about how to talk with the moving company.

User Scenarios

Ant Answers a Bid

Linda is the office manager at Ant Moving. Ant Moving signed up for Moover when it first became available, and it’s given the company a nice bump in its business: Moover is now promoting Ant to potential clients, without Ant having had to do anything more. Linda is happy with Moover and is willing to be a first adopter on new features to help the business keep growing.
Currently, Linda gets an email from Moover when there’s a new bid request. The email has the basic information for the bid and a link to the Moover web dashboard. When Linda clicks the link, she’s taken to a website that lets her reply to the bid, see its status: unanswered, bid sent, or customer accepted/rejected. She can then link back to a master list of all bid requests received and the status.
If the customer accepts the bid, Linda then receives the customer’s contact info, and she can call him to finalize details and give a more accurate bid. Although Linda’s bids are pretty good, sometimes unexpected things happen. Moover has the standard field for how many stairs are in each location, but it doesn’t account for tight staircases you can’t fit furniture down, for example.

Now, with Moover’s latest version, when Linda gets a bid request she still looks over the basic information and clicks a link to open the dashboard. However, there’s a new group on the customer page with messaging information. Since she noticed the customer said he has stairs inside the current unit, Linda uses the messaging tool to ask the customer if he could take a photo of the stairwell and the rooms upstairs, with the furniture inside of them, so that Linda can look for any potential problems.

=====

Rob is the customer booking the move.
He receives a notification that there’s a new question waiting for him in Moover. He checks it and makes a reminder to take photos when he’s home that evening. At home, Rob takes and sends the requested photos to Ant.

The next day, Linda gets an email from Rob, via Moover, with the requested information. The stairwell looks quite large, with no sharp turns, and there’s no obnoxious furniture upstairs that could cause a problem. Linda determines her bid, provides it to Rob via the dashboard, and moves on to the next potential customer. Being an office manager at a moving company keeps Linda busy! She appreciates that the new Moover messaging feature lets her not play phone tag with customers, too!

Moover archives the conversation so that later, should Rob accept the bid and need to reference his photos, he can look them up on his cus- tomer page on the web dashboard. Furthermore, Linda can continue the conversation with Rob since he accepted the bid, finalizing any details. If he’d rejected Ant’s bid, Linda could see the previous conversation but not initiate a new conversation. While that means she can’t reach out later and offer him a coupon, it also provides her incentive to give Rob the best price up front.

Rob Answers Ant’s Questions and Asks for Insurance Information

Living in downtown Metropolis, Rob loves app services. He uses Lyft to get around, Rinse for his laundry, and more. He’s about to move apart- ments downtown, and he’s trying Moover for the first time.
After downloading Moover and answering a few questions about his old and new places, he sits back and waits to receive bids. The next day, he gets a notification from Ant Moving asking to see photos of his stair- case and upstairs rooms. No worries—he takes the photos that night and sends them in-app to Ant. Ant gives him a bid, and it looks good.
However, that afternoon he gets an email from his landlord, reminding him that moving companies have to meet a certain minimum insurance requirement to comply with the homeowner association (HOA) rules, and he has to provide a copy of the company’s insurance certificate unless it’s an HOA-approved mover. Ugh! Ant isn’t on the approved list, but its bid is half the amount of the HOA-approved movers.
Rob goes to the Open Bids section on his app, and creates a new message to Ant. He provides them with the requirements, asks if they meet them, and asks if they’d be willing to provide a copy of their insurance information for the HOA if so.

Linda at Ant gets the new message notification and is prepared. She’s had this request from other clients. She double-checks the numbers, Ant meets them, and she replies with that confirmation. Since she already has a copy of Ant’s insurance as a PDF, she attaches it for Rob, too.
Rob gets a notification about this reply, and when he checks it he sees that everything looks good. He even can open and save the PDF attachment.
He accepts the bid and sends the insurance PDF to his landlord and the building HOA to get the move process started on their end. Linda promptly sends him the contract PDF. He saves it and signs it using a PDF app on his phone, and he sends the completed contract back to Linda via Moover’s message attachment feature. Rob’s excited that this move just got real, and it was easy to organize at a great price thanks to Moover.

User Stories/Features/Requirements

P0
Web Dashboard

Mobile App

P1
Web Dashboard

Mobile App

P2
Web Dashboard

Mobile App

Features Out

Design
None yet!

Open Issues

Q&A
None yet!

Other Considerations
None yet!

Working with design

Product Manager vs Lead Designer

The product manager owns and writes the product requirements and goals:

The lead designer will own the user-experience strategy:

The design process and skills

  1. User research
  2. Information architecture
  3. Interaction design
  4. Prototyping
  5. Visual design
  6. Content strategy

Because of you rarely find one person who’s great at every part of the design process, you usually have a design team with different people specialized in each tactical element, or some combination of elements.

  1. User research
    • The lead designer and a user researcher will often accompany you to customer interviews, and you’ll work together to figure out the user value you want to deliver, business goals to focus on, and the features/ functionality you need to meet those goals and deliver the value.
    • User researchers also help with user testing — how well the customer accomplishes key tasks using your prototype.
  2. Information architecture
    • an information architecture (IA) designer will figure out how to model and organize the data we’re working with
    • Asking what information a user should see first, second, and so on.
    • IA might create a data model, explaining how the underlying product will conceptually be presented to the customer, along with block diagrams expressing in what order to present the information. Example of IA diagram Moover’s messaging feature

    This is a what an IA diagram foe messaging in Moover might be like.
  3. Interaction design
    • Figure out how to present information in the product from information architecture phase
    • Focusing how a customer navigates through the product, what UI controls you use
    • This is also the step where the engineering lead, provide the design team with feedback about the technical feasibility of its designs
    • Result — set of wireframes (series representing various views and key interactions)
      Example of wireframe

    Interaction design.
  4. Prototyping
    • turning static wireframes to interactive prototypes using balsamiq, InVision etc
    • It helps: 1) everybody better understand what you are building, 2) helps Engineering provide more accurate estimates, 3) helps with usability testing
  5. Visual design
    • focus on how product will look
    • Work in parallel with creating wireframes
    • Use wireframes and make them look pixel perfect
    • Need consider usability (font large enough to read, button large enough to tap, etc)
    • Working with Marketing to create a company style

    Example of mock-up

    of mock-up.
  6. Content strategy
    • Right media and texts such as how to word and alert
    • Working closely with Marketing

User testing with prototypes

User researchers and prototypers will work together to perform this testing

Tools:

  • https://www.usertesting.com (which lets you get videos of random people that meet specified criteria performing tasks with your website, mobile apps, or prototype)
  • https://usabilityhub.com/ (which provides data, including heat maps, about how people perform tasks with your static mock-ups across different categories) help simplify the task.

Important:
If you’re testing a new feature in isolation from the main product with a prototype, usability testing won’t test whether existing customers are able to find and use this new feature.

Working with design

The most important criteria we’re going to set is

  • Does this design let the customer to accomplish the key tasks the product promises?
  • Does the design ask for irrelevant information or require complex actions that prevent you from achieving your goals?

Dieter Rams’s 10 principles of “good design”

Good design is innovative.
it’s worth asking if you’re being innovative with your design or applying old design ideas to something new.

Good design makes a product useful.
The design has to make the product functional but also psychologically pleasing. Dental headgear is a great example of a functional product that’s not psychologically pleasing, which means a customer won’t want to use it.

Good design is aesthetic.
Quoting Rams, “The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.”

Good design makes a product understandable.
Design can help make a product’s intended function clear, and great design makes the product usable without any training.

Good design is unobtrusive.
Products exist to help a customer be awesome and achieve a goal, rather than calling attention to itself.

Good design is honest.
A well-designed product doesn’t make the customer believe it does something that it doesn’t actually do or that it is something more valuable than it actually is.

Good design is long-lasting.
While it can be tempting to make something trendy and fashionable, good design will last so that even as styles change, your product won’t go the way of the mullet.

Good design is thorough down to the last detail.
You want to think out every aspect so you make sure that no matter how customers interact with your product, they’re encountering a great experience.

Good design is environmentally friendly.
Design can help us preserve our planet for future generations by minimizing the resources it needs, whether we’re talking about compute cycles that require power or physical design that needs raw materials.

Good design is as little design as possible.
Less, but better. As you evaluate a design, ask yourself if you can eliminate elements. Focus on reducing the design to its essentials, as that purity and simplicity will help make your products aesthetic, understandable, unobtrusive, and honest.

Design Relationship Skills

The biggest source of conflict is that both product and design feel like they represent the customer

Both groups do represent the customer, just in different ways.

  • PMs have to think about the big picture and about different teams’ needs,
  • whereas the design lead will be more tactical and focused primarily on a great design.
  • A handy way to think about the difference is that product managers focus on the ideal customer, whereas lead designers often focus on the ideal user.

The design team will love you as PM if you will be clear with 3 elements:

  1. clear personas
  2. clear requirements
  3. clear goals

Rather than just saying, “We need to improve the onboarding process,” explicitly say:

  1. who the target customers are
  2. what you need the on-boarding process to achieve
  3. and how you measure its success.

Instead of using Balsamiq or InVision tools — it’s better use napkin sketch. But you need to recognize and make clear to others that this sketch is just to convey what you mean, not to imply design answers.

There’s a great story about when President Kennedy visited NASA in 1962. The president asked a janitor what he was doing, and the janitor replied, “Well, Mr. President, I’m helping put a man on the moon.” NASA did a great job making sure everyone knew what they were working towards, and that helped every individual think about how his actions affected that goal.

Working with engineering

Product/engineering relationships

To better understand engineers ask to estimate the task and if the estimate is higher than expected ask if they could explain what goes into that estimate and where the tricky parts are

  • This will help to understand the full scope of the task
  • and if the engineer is making assumptions because you hadn’t accounted for something, perhaps you can decide to limit the scope of the task and make the engineer’s life easier.

Communication

  • some engineers like work with to do list and don’t care why yo make decisions
  • Others will be frustrated if you don’t explain them why you made certain choices

Interruptions

  • give the engineering team time to focus on getting its work done, even if it means you have to wait for an answer to a question.

Bringing your product to market

Understanding customers

The buciness model canvas.

These are the key areas to focus on from a marketing point of view:

  • Customer segments: Who are the key personas?
  • Value propositions: What’s the benefit/value each persona will gain from your product?
  • Channels: How does the company reach each persona?
  • Customer relationships: What communication level and type does each persona expect?
  • Revenue streams: How much and how often will the customer pay?

Specific things we need to know about Persona:

  • How the persona would consider your product a success?
  • How the persona perceives your product/company (if you have an existing product)?
  • What buying criteria the persona has
  • How the persona evaluates products (e.g., does he expect a free trial?)
  • How the persona perceives your competition?
  • What influence this persona has on the buying process?

The main output from business/value proposition is the right messaging for every persona.

Product messaging

Key elements of the product messaging

  • One fundamental theme with answers to 3 questions:
    • Why is this product/company important?
    • Why are you doing this?
    • What’s special about your company’s mission that will make a customer want your product over a competitor’s?

    Example: Moover’s founders created the company because they found planning a move to be overwhelmingly stressful, especially while working full-time. Their core theme is making moving as stress-free as possible so that it’s easy for you to get to where you want to live.

  • What’s fresh and new about the product:
    • What are we building a message for?
      Example: In Moover’s case, it’s the chat feature.
      Hint: “fresh and new” part might differ for new versus existing customers.
    • For existing customers — about new feature;
    • for new customers — education how to use product first and new feature is only one of the bullets.
  • Next to each new feature you listed, write why the customer should care and how this feature relates to the theme.

    Example: Moover’s chat feature lets customers communicate with moving companies at the customers’ convenience, not only from 9am to 5pm. We could rephrase this to explain why a customer should care by writing,
    “Never stress about missing a phone call from the movers: talk with them on your schedule.”

  • How is your product different and better than what the customer’s doing now?
    • create “Now” and “Future” columns and write out what the customer’s doing now and why your product, especially with this new feature, is better.

    Example: Right now, Moover’s customers, both existing and potential, have to stress about answering phone calls and not missing emails from moving companies, even when they’re really busy dealing with life. We could further refine our message by saying, “We’re taking the hassle out of talking to movers.”

  • Right what the persona’s first impression of your product might be, and whether you need to influence that impression.

    Example: CleverPet is a game console for dogs, and at first glance it looks like it’s just the memory game Simon even though it costs $299. CleverPet’s website explicitly calls out that it’s “One hub. Unlimited games.” This wording influences your first impression to know that it’s more than just Simon, and it helps justify the $299 price.

Finding Your Company’s Voice

  • Enterprise products traditionally have taken a formal tone to create a “business” feeling
  • consumer products have adopted a casual tone to create a friendly and accessible feeling
  • The overriding trend now for both enterprise and consumer products is to have a more casual and authentic tone.

Using similar diction

  • For consumer products — this means not using industry jargon.
    Example: Messaging for Microsoft Surface: the most productive devices on the planet” instead listing each device’s CPU specs
  • With enterprise software or specific, targeted products, you often want to use certain buzzwords that a customer is looking for
    Example: Messaging for IT who cares about compliance with government regulatory: Calling out a specific compliance level as part of the message helps him quickly know this product exactly meets his needs.

Going to market

Go to market plan (GTM)

Prelauch

Prelauch planning

The main things to decide during prelaunch are

  • the key launch goals
  • how you’ll make sure the product is ready for that launch
  • when and how you’ll launch the product,
  • and what assets you need to launch.

Launch

Launch have different purposes:

  • (Google pixel) To get as many customers upgrading to new phone or buy new phone
  • (Enterprise SalesForce) the goal might be getting a subset of customers engaged with a new feature.
  • Sometimes the goal is simply awareness of a new product/feature

Launch timing
When they plan to launch (specific date/usually a date range: for example companies buying period)

Testing

Testing the idea the product will deliver on its success metrics.

  1. Internal release of product. The goal is to make sure everything is OK
  2. Broader beta for small group of external customers. External invitation to the top contributors on the support forum or automatic opt-in

Key things to run a successful beta test:

  • Make sure your beta group matches your target persona(s)
  • Test your product messaging
  • Ensure you have appropriate onboarding (specific testing instructions…)
  • Have feedback mechanisms in place (quantitative analytical tools, qualitative feedback mechanism https://qualaroo.com/, https://www.uservoice.com/)
  • Assess your feedback and use it to inform launch decisions

Actions depend on launch type:

  • Conduct a large event with a focus on new and existing customers — if it’s the new product or a new version of existing product
  • Conduct a small event or series of press briefings with a focus on existing customers — if it’s the new big feature
  • Reaching existing customers is more important than securing press coverage — if it’s a small new feature

One simple approach is to build up an email list of interested customers prelaunch.
A “tell me more” landing page for your product is a simple way to capture email addresses.

Launch Asset Planning

  • Website updates. How will the product’s page be updated on your website?
  • Support documentation. What needs to be updated on your product’s support page for the new version?
  • Sample video/images. Do you need to create new screenshots wherever you distribute the product?
  • Blog posts and other social media material. What material do you want to create for the product’s launch on your company’s blog/social media channels?
  • Ads. Do you intend to have any advertising material with your product launch?
  • Demo plan. When company representatives are showing off the product, how will they demo the new product?
  • Distribution review needs. Application stores often require special reviewer logins or video demos so they can make sure your app works as designed.
  • Internal product FAQ. Clear, on-message answers to common questions, including any hard questions you might get from press
  • Support-team training materials. Create materials for them with the most common problems cus- tomers will face, and the solutions
  • Sales-team training materials. As with support, it’s important to create materials for the sales team so that the reps clearly understand the value in the product

4Ps Framework

Product:

  • what is it
  • who’s it for
  • what’s the benefit?
  • the packaging
  • accessories
  • support
  • warranty
  • and return policy

Price

  • both normal, everyday transactions
  • possible volume and sale discounts.

Promotions

  • What will your press release be like?
  • What ads will you create?
  • How will the sales team reach customers?

Place

  • Where do your customers find your product for sale?
  • Is it only on your website?
  • Is it in specific stores, either virtual or physical?
  • Sell where your customers are

The Customer Life Cycle

  • Awareness, interest, and engagement phases
    • social, display ads
  • Getting people to trust your product
    • money-back guarantees
    • Reviews
    • Affiliate marketing
  • customer satisfaction and advocacy (word of mouth)

As a customer moves through each phase, you’ll need to make sure she sees the appropriate messaging and material.

Marketing Cost Measurement Terms

  • Pay per impression (PPI): You pay for the ad whenever it’s shown. Impression means “someone saw the ad.”
  • Pay per click (PPC): You pay for the ad only when someone clicks on it.
  • Pay per action (PPA): You pay only when the user achieves some final action, such as downloading your app
  • Click-through rate (CTR): The percentage of people who click on your ad.
  • Cost per impression (CPI)/cost per thousand impressions (CPM): This is how much you pay to have your ad shown once (CPI) —more commonly listed as the cost to have it shown 1,000 times (CPM). This can be used to assess how effective a campaign is. It’s simply the advertising cost divided by the number of impressions.
  • Cost per click (CPC): This is the actual price you pay for each click in your PPC advertising.
  • Customer lifetime value (CLV/LTV): How much money do you expect to make from this customer over the product’s lifetime?

MOOVER’S GTM PLAN (EXAMPLE)

Key message: Moover takes the hassle out of planning a move.

New-feature message: Moover’s new chat feature takes the hassle out of talking with movers.

Prelaunch

  • How we will test this internally?
    We’ll ask for volunteers on vari- ous teams to help test the mobile app and web dashboard for 10 minutes each day over the course of two weeks. By using both aspects, they can make sure everything goes through as they ex- pected. Using the product for a few minutes each day is likely the most common use case. We’ll also designate one person on the QA team to handle a different fake company in the database so that she can test the “many clients/one response source” system.
  • How will we test this externally?
    We will ship it and turn it on for a small group of customers with no special announcement and see how usage changes, if customers have problems, and more. It’s tough to create a beta pool for moving customers because people move and then don’t do it again for a while. Letting customers try this feature also means we’ll have to roll out the web portal to our moving companies earlier, as they’ll need to be able to answer messages. We’ll need to create training material for these companies and provide support.
  • How will we launch this?
    This is not a huge feature, so it doesn’t need much fanfare. However, because many people haven’t heard of Moover, we want to use this to help generate fresh articles about our product. We’ll work with our PR firm to do a small press tour, and we’ll make sure the focus is on the core product message more than this specific new feature. We’ll need to come up with a sample demo flow for these briefings. Perhaps we can have a fake moving company that automatically sends a series of replies on the back end so that it appears like you’re having a real conversation with the company during the press briefing.
  • What assets do we need to create?
    We need training and support ma- terials for our moving-company customers, updated screenshots and documentation for the website and app stores, and a blog post describing what’s in this update.
  • How will we reach customers?
    We don’t have frequently recurring customers, so reaching existing customers isn’t a big concern. We can continue to promote Moover in general on job boards like LinkedIn (given that after people get a new job, they often move).
  • Launch
    There should be very little to do during launch, aside from updating the website with new product information and releasing the updated app. We’ll want to make sure our website can handle an increased visitor load, but given how infrequently people move, we don’t expect a huge uptick in simultaneous active users in the app. Given we see an average of 1,000 users per day, we could start by assuming that each user sends two chats per day to every moving company he has a bid from. There’s an average of five bids per user. This means we should be prepared to handle 1000 * 2 * 5, or 10,000 chats per day, which isn’t a huge number. We can adjust capacity as needed after things level off.
  • Postlaunch
    We will continue to promote Moover as normal, especially focusing on targeted display and search ads. The general message is still the key message to promote, as our app awareness isn’t at the point where it’s worth advertising specific features initially.
    We’ll want to watch how often people use the chat feature to make sure it’s sufficiently discoverable and intuitive.

Finishing the product-development life cycle

Celebrate

  • Cupcakes for small features
  • Dinner with the team for huge release
  • Take a quick speech to recognize the core team
  • Share positive feedback (CEO, external partners, press releases…)
  • If a launch wasn’t well received, you should still recognize the effort that went into it, as you want the team to have a positive attitude when working on the next iteration of the product.
  • Organize small activities and celebrations when the team hits a key milestone

Assess how things went

Your lead:
Schedule a 1:1 with your lead. Question to start: “Could you give me feedback on how you feel this cycle went? I want to make sure I’m doing the best job possible.”

The team:

  • Schedule a meeting with core team and stakeholders (1-2 hours)
  • Make comfortable atmosphere (alcohol nonalcoholic drinks)
  • Ensure there is a whiteboard
  • Divide the whiteboard into two columns: things you did well, and things you wish went more smoothly. Start by asking everyone to say what they think went well. After a bit, switch to the other list and ask for things people wish had gone better. Bounce back and forth between the lists until you feel everyone’s been hear
  • Last, take some time to discuss what you want to do differently and what you want to keep the same during the next cycle. Make notes

Create recommendations for next iteration

P.S.
One of the most common mistakes in landing your first PM job is setting your expectations too high, either in terms of your title or your company. Just because you are a senior software engineer now does not mean your first PM job will be as a senior product manager. Similarly, your current company might not be your dream company, but if there’s an opening for a PM, you likely have a better chance landing that as your first PM job than getting a job elsewhere.

Be realistic! Asses your current expertise and map out realistic career paths inside or outside your current company. Your ideal PM job will likely not be your first PM job, but that’s OK. As long as your first PM job is relevant to your career goals and you’re surrounded by more senior people that you learn from, it will still be a great job.

Была ли эта страница полезной?

(3)
(0)
Уведомить о
guest
0 отзывов о книге "THE PRODUCT BOOK"
Оставить отзыв
0/ 5
(0)
Межтекстовые Отзывы
Посмотреть все комментарии
Мы используем cookie-файлы для вашего лучшего взаимодействия с сайтом.
Принять
Политика конфиденциальности