21a. Post-Launch Introduction

Welp, you’ve launched the product. Time to party!!

Not so fast. While the “new product development” actions might technically be complete, it’s worth spending a chapter to distill what typically happens after a product launch. There’s actually a lot more than one Chapter’s worth of content, so who knows, maybe this will become many Chapters one day.

What We’ll Cover in this Chapter

• The fundamentals of managing a product after launch
• Managing a feature backlog
• Crossing the chasm. Maybe you’ve heard of it, now try to actually learn it.
• ABL; Always Be Learning. Conducting a Post-mortem

Post-Launch: it’s not just for Product Managers

Most product development books won’t cover topics related to managing products after launch — reason being that post-launch management typically falls on “Product Managers” and people in Marketing.

Product Development = typically covers everything up until launch

Product Management = typically focuses on before and after development

But, in my opinion, this “siloing” is bad, and understanding how a product is managed after launch is useful for everyone involved in new product development.

Stay Close to the Product

Rocket scientists do not completely check-out and start chugging champagne once a rocket leaves the atmosphere. You would sort of look like an asshole if you were holding a flute of bubbly when someone says, “Houston, we have a problem.”

Don’t light that cigar until everyone comes home safe.

Yes, you can celebrate when your rocket breaks out of the atmosphere into outer space, but there is still work to be done. Similarly, keeping close to your product after launch makes sense for any good product developer.

Now, staying close to the product after launch may seem very obvious for digital products that evolve over time. Gmail, Facebook, Twitter —they look a little different now compared to their original form.

This lesson is less obvious with physical products.

With physical products, the engineering or technical team might be able to step away once the factory is in cruise control.

With physical products, the technical team might not “have” to deal with issues in manufacturing or complaints from the field.

This disconnect is a big mistake.

The factory floor offers a huge opportunity for learning. Improvements gleaned from one product can significantly improve next-generation products or adjacent products.

Keeping the development team around also makes them team feel more accountable for solving problems throughout the life of the product. They will design more carefully knowing they will share the responsibility of managing the product after launch.

The book Mastering Lean Product Development by Ronald Mascitelli summarizes this point extremely well.

“From a standpoint of risk reduction and team learning, it is vital that the development team stay committed to a new product well beyond the shipment of the first production unit…

If engineers and designers lose interest in a product once the fun part is over, then they miss the opportunity to learn how their new product fares in the demanding world of production . . . .

Without this knowledge, they are destined to repeat mistakes that can be costly and time-consuming once the product is transitioned to the factory . . . . 

If these individuals are required to live with the ramifications of their design efforts, they will be far more likely to pay attention to details, listen to inputs from operators, and deliver a truly production-ready product.”

Yes, that is a big quote, but I say it’s worth it. Good product developers are always seeking insights from the product development process about designing better products. Some of the best insights can be gained after launch, so the technical team should do their best to stay close to the product after launch.

21b. Managing the Product In-Market

There is a quote that goes something like this: “Ships don’t sink because they don’t know where they are going; they sink because they don’t know where they actually are.”

Iceberg, Right Ahead! You don’t want to be making this face when looking at your product launch metrics.

The Titanic’s problem wasn’t ignorance of its destination; it was ignorance of being on a collision course with an iceberg.

If the Titanic’s ‘product manager’ were paying more attention to his metrics and keeping better track of the ship’s heading, maybe we wouldn’t now have to live with the various Titanic memes proliferating the internet (yes, there was enough room on the door for Jack).

Smithsonian Magazine has spoken. “It’s Definitive: Rose and Jack Could Both Have Survived in Titanic.”

I digress. Back to tracking products after launch.

Chances are, you know how you want your product to do in the market, but in order to effectively manage your product post-launch, you need to clearly understand how the product is currently doing.

What’s Happening Now?

“What’s happening now?” is a question the product manager should always be prepared to answer…” Steven Haines, The Product Manager’s Desk Reference

How do you answer this question? Well, first, you answer by talking about money.

Jerry Maguire, Product Manager Extraordinaire

“If the CEO of your company asks you how your product is doing, the answer is “money.” — Steven Haines

“Without finance, there is no way to assess how well the product is performing against established plans.” — Steven Haines

“Look, I Don’t Dance Now, I Make Money Moves” — Cardi B

Even Cardi B knows that financial metrics are critical for understanding how your product is doing in the market.

Financial terms may seem scary, but with regard to product metrics, they are quite simple. Here are a few of them:

• Revenue — the total money being made from your product
• Profit margin — the revenue minus costs
• Gross margin — the profit margin divided by the sales price
• Fixed Cost — costs that don’t change based on how much product you produce. Rent paid for a factory or the cost of tooling is fixed
• Variable Cost — costs that change based on producing your product. Labor and material costs are variable if they scale with production
• Contribution margin — The contribution margin is computed as the difference between the sale price of a product and the variable costs associated with its production and sales process
• CAC — Customer Acquisition Cost — the average cost of acquiring customers

OK, enough of that. Financials can be a bit boring and dry. But being familiar enough with financial terms to make sense of the product’s performance will give you an advantage as a technical product worker, and it’s a requirement if you want to get into management (product management or general management).

Is it Only About Money?

There is more to life than money, and there is more to tracking your product after launch than financial metrics.

Haines provides what I think is the best comprehensive list out there for tracking your product after launch. He calls it the “Product Performance Report Card” and it goes like this:

• Financial results
• Major sales activities (wins and loses)
• External KPIs (industry and competitor activity)
• Operational KPIs
• Marketing mix performance (pricing movements/discounts, promotional campaign performance, and channel performance)

This may seem like a big scary list, but the good news is that many of these items should have already been planned for in your Launch Management System. (If you missed the Chapter on that, click here for Chapter 20 — Launch.)

Tracking these things after launch requires work, but often it is just a matter of simply collecting information and paying attention.

Actually Managing the Product Post-Launch

I explained earlier that most actions taken with regard to product management post-launch relate to money. Do we invest more money or less money, and if so, how/where in order to make more money from the product?

The actual levers you can pull mostly relate to the Marketing Mix. Based on what is happening with the product in the market, some adjustments may be needed to price, promotion, placement, or the product itself.

Here are some examples of post-launch actions related to the Marketing Mix

• Price — Lower the price
• Promotion — buy now and we’ll throw in this, this, and that!
• Placement — Change where people can access or learn about your product
• Product — Augment the product with a warranty or guarantee

It depends on the company, but the above actions may be managed by a Sales team, and Marketing team, or possibly even a Product Management team.

21c. Managing a Product Backlog

As we’ve seen throughout the product development process, there have been many instances where not all product developers face the same challenges. “Different strokes for different folks,” is how we described it.

Well, guess what? This is again the case after launch.

In some cases, once the product leaves the factory, the product developer’s work is done. With many physical products, the specs don’t change once the factory starts production.

In many other cases — digital products, software, cell phones — you aren’t really “done” just because you’ve launched the product. These products must be supported and often evolved in order to remain useful and relevant. (Look into terms like continuous delivery and continuous deployment to learn more.)

For these products, there are typically two main things that are going to be needed post-launch:

• Bug fixes
• Feature improvements

Bug fixes are simple. When something doesn’t work, you just have to fix it.

Feature improvements are more complex. To understand how feature improvements are made, we are going to have to distill roadmaps and backlogs.

What is a product roadmap?

“A product roadmap is a plan for how your product is going to meet a set of business objectives. The roadmap details the direction of your product and the work that is required to get there. It is used to communicate the product direction and progress to internal teams and external stakeholders” Source

Basically, the roadmap maps out the vision, direction, and priorities for your product over time. You might think that where you’re going, you don’t need roadmaps, but actually, yes, you do, they are quite necessary for clarifying purpose and direction.

What is a product backlog?

“A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first.” — Atlassian blog

“The product roadmap communicates high-level strategic objectives and priorities, whereas the product backlog is a list of tasks that will serve the roadmap’s strategic plan.” Product Plan

As you can see, the roadmap and backlog are two of the most critical resources for a product development team. The two complement one another to provide a long-term and near-term direction for products that evolve somewhat continuously (like software).

There are literally thousands of books and blogs dedicated to this discipline of product development using a roadmap and backlog. I’ll list some resources below, but here are the common “best practices” you’ll read about if you dig deeper.

• Maintain one single, manageable (not 1,000,000 items) list
• Groom it frequently for prioritization
• Focus on “what” and “why.” This is like the section on the Marketing Requirements Doc; don’t tell the engineering or product builders “how” to solve the problem — just tell them what the problem is and why it’s important
• On a similar topic, you don’t have to turn everything into a user story. Sometimes less is more

It’s typically a product manager’s or “product owner’s” job to maintain both the roadmap and the backlog. The backlog is certainly changed more often, as it provides more of the day-to-day priorities for how the product is to evolve and improve over time.

The product development team works closely with the product management team to execute items on the backlog and deploy them (i.e., launch them).

Like I said before, you could fill a room with all the books dedicated to managing products effectively with a roadmap, a backlog, and other related tools. If that is how your organization functions, see the resources at the end of this Chapter to dig deeper into these topics.

21d. Crossing the Chasm

This section might not perfectly dovetail with everything else around it, but every product developer should have an awareness of how products are adopted by the market.

This whole section is distilled from the work of Geoffrey Moore in Crossing The Chasm. Despite spelling his name totally incorrectly, Moore came to be one of the most important people in Tech, leading Sun Microsystems, authoring books, and even having a law named after him (Moore’s law describes how rapidly microchips improve performance).

Let’s cross the chasm, people.

Who Adopts Products First?

This is somewhat intuitive; the people who like to adopt products first are called the innovators. They want to be first. They fucking love being first. They will buy a product just to be first, regardless of their needs, jobs to be done, or whatever their husbands keep telling them about how much money they’re spending on shit they don’t need (sorry, that got personal there).

After the Innovators come the Early-Adopters.

Early-Adopters are also willing to be leaders, to take risks, and to try new products…typically because their need is so great that anything beats what they’re currently doing.

After the Early-Adopters, there is a chasm.

A chasm: a big opening; a divide.

On the other side of the chasm is the Mainstream Market.

Image credit Words By Sorensen

The Mainstream Market

The Mainstream Market consists of the Early and Late Majority, and finally the Laggards. The Laggards are the people who won’t buy a new product until they pretty much absolutely have to. (Fuck those people, amiright?!).

The Mainstream Market is the majority of the consumers out there, and the truth is, most people don’t really care about your product. This is an inconvenient truth.

“Here’s an inconvenient truth: the mainstream market doesn’t care about your product.”

Most people out there are making do with whatever they are currently doing. Most people don’t like change. Most people don’t have the time or interest to carefully consider why your product might be better for them. Most people don’t like taking on risk — especially people who are buying on behalf of their company and would be consequently “sticking their neck out.”

Getting this group of people to buy your product is difficult. This is unfortunate, because the mainstream market is obviously where huge profits and market share success lie.

The question is, “how to cross the chasm?”

How to Cross the Chasm to the Mainstream Market

Here are Moore’s lessons, distilled:

Deliver a “whole product”

While the Lean Startup method preaches making “minimum viable products” that allow startups to rapidly learn, the majority of buyers out there are not looking for a minimal product — they are looking for a whole product. To be considered by the mainstream, you’ll need to augment your product with training, with support, with third-party plugins, with warranties, etc.

Choose the right channel

Breaking into the mainstream may require a sales force to beat down people’s doors. It may require you to open a retail space. There is no single universal solution. The point is that many different sales channels exist and you must choose carefully. Select the wrong one and you’re not going to cross the chasm.

Pick a Beachhead

A beachhead is the segment of the early majority market that you are going to focus on. If you find a group of customers who are most in need of your product and who already have the budget to buy it, focus on that segment in order to establish early wins, momentum, referrals, and market share.

Compare and contrast with existing options

Remember, the majority of customers are generally risk-averse and they haven’t heard of you or your product. If you want them to spend their hard-earned cash (or risk their reputations to their bosses), you need to make your product “safe” and clearly explain how it compares to known product alternatives.

In Summary

If nothing else, you are now aware of the general market adoption process, as defined by Moore. This description is pretty widely accepted to be accurate for most industries and markets.

21e. Looking Backward with the Post-Mortem

A post-mortem is a real thing in the medical world where a medical professional explains why someone died.

In the product world, a post-mortem doesn’t have such a negative connotation. It’s just a clever way of saying, “Why did that happen?”

Post-Mortems Distilled

Typically a post-mortem is conducted by bringing together a number of people involved with a project and having an open discussion about the process and outcomes.

There’s also plenty of defensiveness, denial, accusations, blame, name-calling, and chair-throwing.

Post-mortems can end up looking like this.

The goal of the post-mortem is learning and improvement. This might mean changes to a development process, new protocols, or the creation of ongoing projects to further investigate something.

In many organizations, a “premortem” is conducted very early in the development process. What is a premortem, you ask? A premortem is just like a post-mortem, only it challenges the product team to anticipate what might go wrong before the product is fully developed and launched.

How to Do a Post-Mortem or Pre-Mortem

There really isn’t a big trick to it. Like any other meeting, it’s critical to facilitate the discussion to keep it on track. Keep people focused on outcomes and processes rather than on blame.

It helps to have a well-organized agenda with prompts to get people thinking, ideally shared with the team in advance of the meeting. This beats sitting everyone down and just starting with, “Jerry, what the hell went wrong with your project?”

A best practice is to solicit input from the team in advance. There are two reasons for this.

First, it allows you to set the agenda for the meeting based on the key issues people have already identified.

Second, it allows people to provide insights individually and in private. Most people will shy away from confrontation and honesty if it hurts a colleague’s feelings. It’s difficult, to be honest about a mistake someone made when the offending party isn’t sitting right across from them, scouring at them over a mug of coffee that reads, “Don’t even talk to me until I’ve had my coffee.” OK, Karen, calm down, you go get your coffee and then I’ll talk to you.

Beware of conducting a post-mortem with someone who actually has a mug like this.

Root Cause Analysis

Since this has not been covered elsewhere, now might be a good time to make sure you’re familiar with two terms.

Root Cause — the fundamental or “initiating” cause for something happening.

5 Why’s — a thought-exercise where you ask “why?” over and over until the root cause is identified. Basically behaving like a three-year-old until you know why something happened.

Using root cause analysis can be invaluable for actually solving problems and enacting change.

For example, your product may have shipped late, but was the root cause poor execution, lack of planning, or maybe good planning but unrealistic expectations? These are different root causes, each of which would warrant different corrective actions.

Don’t be fooled by how not exciting this looks — it’s a useful tool. Source

Auditing Your Launch

Finally, if you are doing a full post-mortem, you might also want to “audit” the product launch itself. Haines recommends auditing these things post-launch:

• Market window and how well you timed your launch
• Executive support and sponsorship
• “Synchronization between the business case and the launch plan”
• Prep of the sales team
• Prep of sales and marketing assets
• Operational readiness
• “Launch metrics”

In summary, there is a lot of opportunity for learning after a product launch. Dig deeper into post-mortems or launch audits to learn more.

Chapter 21 Summary

• Once launched, product feature additions are typically managed through a product backlog, which helps the product team execute against a grander product roadmap.
• Financial metrics are used to assess how your product is doing in the market. Other KPIs are used as well, but typically everything should be tied to a financial metric.
• The levers for managing the product post-launch are typically within the Marketing Mix: product, promotion, price, and placement.
• There is an entire field of study into the product life-cycle, and “crossing the chasm” is one of the more important concepts for how products to scale.
• Post-Mortems (and Pre-mortems) are a useful tool for learning.

Resources

As I explained, Post-Launch management is more of product management or even product marketing topic than it is a product development topic, so most NPD books don’t cover it thoroughly.

For a helpful visual, here’s a look at product management and product marketing. If you work on the product development team as an engineer or UX designer, you may not touch product marketing much at all.

Source Hugh McFall

The Product Manager’s Desk Reference — Steven Haines. This book covers a lot of post-launch content: auditing the results of the launch, running a business, planning future products, and discontinuing the product. Probably your best bet for post-launch content.

HBR’s How to do a Project Pre-Mortem

There are a lot of templates and guides to Post-Mortems online. Just google it. I don’t have a particular favorite resource.

Crossing the Chasm — Geoffrey Moore. A classic. Relatively quick read. Worth it.

5 Product Marketing Tips to Help Your Startup Cross the Chasm. Good 10 minute read to help you understand what actions can be taken post-launch.

https://www.productplan.com/glossary/product-backlog/. Product Plan offers a lot of useful resources like articles and ebooks.

Roadmunk is another good source for solid/quick reads on product backlogs and roadmaps.

Scrum.org has good resources, such as this article 10 tips for backlog management on Scrum.org. I can’t say that I’ve spent much time on their website, but it looks promising.