LAUNCH - growth practices Amir Shokri - chaoter 12 - cracking the PM career amirsh.nll@gmail.com

1. LAUNCH - growth practices
Amir Shokri - chaoter 12 - cracking the PM career
amirsh.nll@gmail.com

2. PARTNER WITH LAUNCH STAKEHOLDERS EARLY
I didn't loop in stakeholders early enough, and now they've identified an issue that will block
my launch!
To resolve the issue:
1. Bring the stakeholders up-to-date with the goals,context,and priority of the launch.
2. Work together to write down options from low risk to high risk, along with the pros and
cons of each. Look for ways to mitigate the risk.
3. If you don't agree on an option, escalate the decision. Don't get emotional or defensive.
Stay focused on uncovering what's best for users and the business.
4. Once you have a plan, send an update to stakeholders. Let them know what new
information has come to light, what the new plan is, and that you'll come up with a plan
to identify issues like these earlier next time.

3. َUSE LAUNCH REVIEWS AS A WAY TO EARN CREDIBILITY
REFINE THE WAY YOU THINK ABOUT LAUNCH DATES
I've seen all the following issues occur:
● Projects delayed months because the legacy code they touched was more complicated
than the engineers had expected.
● One product looked great in design reviews, but when we tried it out with real user data
we realized the design was confusing and spent an extra month improving it.
● One time, we built our new features on a new piece of infrastructure that never
launched and we had to rewrite half the code.
● Another time, we paused work to move several engineers onto an urgent spam issue.
● One feature was a week away from launch when we noticed a data corruption issue
that took a few weeks to repair.

4. Instead of thinking about the launch date as a single day, think about it as
a range of dates, from the earliest you might launch to the latest.

5. The lower end of the range should be the best case scenario, if nothing goes wrong. To
come up with the date consider:
● Add in time before the engineering can start—for example, design time, and time
learning new technology.
● Put a multiplier on the engineering estimates (e.g., one ideal day = two real days).
Check with your engineers and other PMs to see what multiplier they recommend.
● Check for any planned vacations, offsites, or other non-working days.
● Add in time for running A/B tests or a beta program. You may also want to share the
estimated A/B test start date when sharing your dates.
● Add on time for how long the deployment and any other post-code work takes (e.g.,
translations).
● Consider adding an extra 10 to 20% buffer on top of everything else. Yes, even in the
lower end of the range. Good project managers should always assume that something
will go wrong.

6. The middle of the range should be based on your estimate of an average number of things
going wrong. Consider:
● What might you learn from user tests, A/B tests, or the beta program? How long would
those things take to address?
● What types of problems could the engineering team have, and how much time would
they add? What are the other risks, and how much time would they add to the project?
For the upper end of the range:
● Try to figure out the date by which you're 90 or 95% sure you'll have launched.
● For a multi-month project, this is usually at least two months after the lower end of the
range. Everyone on the team should agree that if it goes past that date, something went
really wrong.

7. Simple things to check for are gaps or mistakes, such as:
● Does the marketing strategy assume features that won't be included at launch?
● Does the pricing and packaging cover all types of users?
● Are there corner cases that should be explained in the help documentation?
● Do the sales talking points include the key things customers have said they care about?
Do any pages on the website need to be updated because of the product changes?
Is the experience consistent, with the same terminology and imagery, across all of the
customer touch points? Beyond the basics, you can look for opportunities to improve the
end-to-end customer experience. For example:
● Do you have marketing insights based on the user sessions you did?
● Do you have ideas for using launch partners or distribution channels to reach a wider
audience? Are there ways to make the product easier to demo to customers?