pm@olin: Launching (Class 6)

One of the most influential moments of my college career was visiting final presentations for 2.00b, Toy Design, at MIT. At the end of the semester, all of the projects looked professionally polished (take a look!) This was a long shot from where most of my projects ended up — for example the hardware and circuits in my Principles of Engineering Class.

I wanted to take part of the workplace “launch” skills back into the classroom, to give students an idea before that actually started launching.

Goals
1. Understand the different types of “launches”
2. Understand how the technical side of launching varies for a company that makes software, hardware, or a service.
3. Understand all the other pieces of “launching” outside of the technical.

Optional Reading
1. Shipping is a feature (Steven Sinofsky)
2. Product Hunt Manual (Kiki Shirr)
3. Why most Product Launches Fail (Joan Schneider and Julie Hall)

Materials
Whiteboard and markers
Laptops or pen/paper for students

Guest — 30–45 minutes
This is the first week we had a guest in my class! Tom Rudick joined us to talk about the some of the differences between Product Management and Engineering. In particular he included calendar examples for both to tie to the week before. His talk didn’t specifically tie to the class material. We also walked through a few sample technical interview questions.

Exercises

We approached this class in a similar manner to the way we approached the Specs class. After we had a short conversation on each topic, the student worked on their own idea for a bit.

Types of Companies — 20 minutes

I started by breaking the idea down into three major areas — Hardware, Software, and Services. There’s probably a better way to do this, but I wanted to separate some of the differences I see in technical launch risks.

Software: Considering everything you need to ship the product. This could include: Functional End to End Testing, Nonfuctional Testing, Device support, Browser support, internationalization (i18n), accessibility (a11y) and security concerns. We also talked about scalability and releasing a feature incrementally to your user base. I showed a sample “shipping checklist” of what you should look at as a PM before you’re shipping. Unfortunately we spent the most time in this area because this is the area that I know best.

Hardware: In this area I wanted students to consider manufacturing concerns. Are you hand making the first few units yourself? How do you pick a factory? US/International? Do you visit the factory? How do you weigh shipping costs? How do you handle distribution?

Services: I mostly threw this in because I wanted to showcase a couple different MVP techniques. It’s easier to example the Wizard of Oz and the Concierge model using a Service.

You could definitely break this up differently. I just wanted to point out that the “technical” side of your launch plan will likely depending on the type of business you build. Many of the students pointed out that they wanted to build a hybrid of these — that’s fine. We had a mix across the class of each type and combinations of the types.

Types of Launches — 20 minutes

After settling on projects and thinking about the key types of technical concerns for each launch, we discussed “What is a launch, anyway?”

As expected, this varied across the class. We built a full list of different types of “launches” based on some expectations. There are probably more, but this is a good starting point:

Alpha — The first time anyone is using your Product. Possibly looks like an “experiment” or “test” mores than a big launch.
Friends & Family — A short list of people you want to try your Product that you know, and who will report back.
Beta — Probably a larger list of people using the product. Might involve asking for an invite, a waiting list, or something else.
Public Soft Launch — Available to everyone, but not publicized.
Traditional Launch — Available to everyone, trying to drive as much usage as possible, press coverage, etc.

This also impacts how much planning you need to do for the first piece. If you’re having a small set of friends and family use your app to test, you can have a different quality bar than a large public ship.

Building a Technical Launch Plan — 20 minutes

Based on these first two groups, I had each student come up with what they thought was the biggest concern for their launch, and how they planned to address it. If we’d had more time, I would have asked them to pick more issues and go into more detail.

While I don’t write a full launch plan every time I ship something, I think it’s wise to consider all the angles once academically so you get a feel for what could be going wrong.

For example, one student was considering a “breakfast delivery” startup. An appropriate beta launch might be in a specific apartment building or office building — rather than a launch in an entire city — or everywhere!

Communications Around Launch — 45 minutes

The other part of launches that often gets overlooked is the communications side. I wrote down a bunch of different launch communications that happen:

Purely Internal:
Team — Thank you Notes, party, etc.
Internal email (team vs all)

Internal/External:
Customer support plan — best case? worst case?
Company blog post — how do you present this?
Changing the homepage, new badges, etc. — how big of a splash?

External:
Product Hunt Post
Press Release / PR — who do you pitch to? why do you pick them? how do you write to them?
Help Documentation, FAQs

For each project, a student picked something they’d like to do. Some tried to write the launch blog post they’d want the company to share. Some tried to envision a worst possible scenario (food poisoning on day one of the breakfast startup!) and write how they’d communicate with customers. This is harder than it sounds! It’s about getting the brand voice right, but also about appealing to your customer demographic and sounding genuine.

While we didn’t have enough time to write out all the pieces, this was again meant to expose students to the various aspects of launch.

Selected Changes / Notes

1. Having guests is hard! I didn’t adequately prepare for the guest situation. Each classroom has it’s own dynamic, and as the instructor, you pick up on it. Tom opted for more traditional lecture, which contrasted by socratic style. I should’ve been more up front about how to directly engage with the students.
2. Students anchor on what you say. As mentioned, my hardware/software/services was just meant to be a starting point. Once again, students thought of it as a hard and fast rule. It’s hard to keep things general.
3. I wish we’d had more time for the communications / launch time. I think that was more valuable than the more technical sides of launching.