This document provides guidance on growth practices for product managers. It discusses several approaches to test hypotheses quickly such as using prototypes and A/B tests. It also discusses designing for sticky usage through notifications, updates, and gamification. The document advises building a product mindset by focusing on the problem to be solved. It recommends prioritizing goals and developing a quality bar by choosing issues to fix while keeping costs in mind. Finally, it suggests considering more radical solutions by expanding perspectives on team size, deadlines, partnerships, and business models.

1. GROWTH PRACTICES - chapter 7
Page 85 - 89 (Cracking the PM Career Book)
Amir Shokri - amirsh.nll@gmail.com

2. pick the fastest and best ways to test hypotheses
● Test on people around you
● Use a site like usertesting.com to recruit participants for you
● Set up a recruiting intercept on your product's website
● Use low-fidelity prototypes
● Use high-fidelity prototypes.
● Have an open-ended conversation with real users
● Invite stakeholders to the user sessions
● Run a quick A/B test.
● Run a "fake door" test.
● Create a concierge MVP for a few customers
● Analyze existing data

3. design for sticky usage
Here are a few approaches to help bring people back to your product at the appropriate
time:
● Notifications
● product Updates
● Visibility
● Gamification

4. build product mindset
● What problem are we trying to solve?
● What problem should we solve?

5. build product mindset
If product mindset isn't natural to you yet, you'll need to work to build this habit.
● Check for assumptions that might get in the way of having a product mindset.
○ Do you assume that you can't push back on the goals set by your boss?
○ Do you think true innovation comes from a spark of creativity rather than a
deliberate process?
○ Are those assumptions holding you back?
● Set reminders for yourself.
○ Is this problem worth solving?
○ What problem are we trying to solve?

6. Practice identifying and prioritizing goals
● write down all of the business and customer goals you can think of
● prioritize the goals
● stay current with well-designed products
● develop your quality bar

7. develop your quality bar
Developing your quality bar includes two parts:
● design for sticky usage
● Choose which issues to fix, but keep cost in mind

8. sample conversation
Okay, we've just done a thorough team review and noticed these ten issues that I wrote
down. Let's go through them and figure out which ones we want to fix before launch.
We should fix all the typos because I'm assuming those will only take a few minutes; does
that sound right?
The drop target being small is pretty frustrating; is there any way we could fix it in less than
a day? How about we spend an hour looking into it, and if it'll take longer than that, we
don't fix it? Designer, does that seem reasonable?
The error message when files are too big is not very helpful, but I know we don't have much
control over that dialog, and I don't think many users will hit it. I'll look at the logs and
customer tickets a few weeks after launch and we can see if it ends up being a problem.

9. expand your perspective: consider more radical solutions
Here are some questions to consider:
● What types of solutions would be possible if you expanded your team size?
● What if you could move the deadline?
● What if you could form a partnership with another company or buy a ready-made
solution?
● Could the problem be solved outside the product, such as via customer support or the
sales team?
● What if you could change how the business model works?
● If you could wave a magic wand and build anything you want, what would it be?