Defining your product: A strategic approach for senior product leaders

Paul Meighan, Director of Product Management, Amazon S3 and Glacier, gave this presentation at the Product-Led Summit in San Francisco in 2023.

I work on Amazon S3, which is one of the world's first and largest cloud services. If you’ve been on the internet today, you probably interacted with our service either directly or indirectly. We have millions of customers, many trillions of files or objects in the service, and lots and lots of usage.

I want to talk a little bit about my experience with this service today because I think it gives us an interesting perspective on product management for a few reasons.

Product management in the cloud

Because of our scale, we have really fast cycle times. We get a lot of reps and we do a lot of launches every year. But we also see a lot of stuff because we have so many customers who come to us with random problems and queries.

Additionally, the little things add up. As a product manager, you may see a bug or problem that affects one out of a million requests, and you can decide to just release notes that. But for us, one in a million is a lot every day. It has a meaningful impact on the customer experience, and these ‘little’ problems can have big downstream effects.

As a result, we're obsessed with the details. We have fast cycle times and we're getting a lot of repetition. We're seeing a lot of customer situations, doing a lot of launches, and we learn a lot.

On top of that, we have so many customers who are coming to us about how to build in the cloud.

I deal with a lot of product teams, product managers, and product leaders who are building on AWS on top of S3, so I also get to see their mistakes and what they're doing. So it's just an experience of seeing a lot from my unique vantage point in the cloud.

The theme of this conversation is related to making mistakes and getting stuff wrong. Over my last five years in the cloud, I’ve messed up a ton of stuff and got a lot wrong. And what I've found is that the key to being a great product manager is to figure out how to get really good at being wrong.

My goal is to provide you with practical tips that you can apply to help you be better product managers.

Building the wrong product

You’ll definitely end up building the wrong product. It's a heartbreaker, but it’s totally going to happen. It's just a question of how wrong your product will be when you launch it.

There are three things that I try and coach our product managers to think about:

Embrace the churn and iterate on your product definition.
Write down decisions as they come and keep them documented.
Avoid one-way doors.

Let's talk about each of those.

Embrace the churn

A lot of product managers come to me frustrated with the churn. I’m writing a requirements document and they’ve got to review it and review it and review it.

I'm here to tell you that churn is good and that you should embrace it. You’re probably not going to come up with the best idea, and it's really not your job to come up with the best idea. Your job is to find the best idea.

So, if you can iterate and bring your stakeholders in and just iterate and iterate and iterate, that's how you're going to build a great product.

Write down decisions and keep them documented

You're going to make decisions along the way. With my team, I always ask them to write down their decisions. We use a simple decision doc format. There's no magic to it, it's just:

Summary
Option one
Option two
Option three.
Which one do we recommend?

And then we bank it.

The reason we do that is because it allows us to record our decisions so we can go back and check things like, “Why did we do that last year?”

That helps you from being wrong twice. It also allows you to validate your logic with actual writing and review. Clarity comes from writing, and it's a great practice to help focus the mind.

And whenever all your stakeholders are looking at, it, they can look at the words, we can talk about what's on the page, and it helps when you're debating and going back and forth on a decision. It really helps to get buy-in and alignment from your stakeholders and leaders if you're talking about a document and not some idea that's in your head or a slide somewhere.

Avoid one-way doors

One-way doors are decisions that you can’t come back from. They threaten to break the business, so they can't be wrong. So you’ve really got to pay attention to the one-way door decisions, think about them, and take them very, very seriously.

Two-way door decisions can be reversed later, so it's not worth the time and effort to spend a year thinking about a two-way door decision. It's better to just go and do your thing, and if it breaks, then roll it back and revert the decision.

Good examples of when we make our decisions are API contracts. If a customer builds against your API, that's your API. You can't go change it and introduce breaking changes later.

I’ve also been really wrong about some product names in my career, and they can box you in. They can prevent you from doing cool features that you want to do in the future because you named the product incorrectly in the first place.

So be very careful with product names.

Also, anything that a customer builds a business process on top of. It's really sad to go to a customer and say, “You're going to have to change the way you do business.”

Getting P&L wrong

Now I'm going to talk about pricing.

This is a question that we get from leadership all the time: “How much money will we make?”

On one hand, it's reasonable for leadership to want to know how much money you're going to make. On the other hand, it's ridiculous. We can't predict the future. We're going to be totally wrong about our answer to this question.

That said, I ask my PMs for this all the time, and you're going to be asked this as well. But the correct answer to how much money you’ll make is P&L. That explains the volume of how much you’re going to sell, how much you’re going to price it, and how much it's going to cost.

Let's go through this dumb P&L example:

Table showing an example of P&L forecasts from year 1, year 2, and year 3

First of all, they’re getting the volume projections wrong. There's no way they're going to get a forecast right. You can't predict the future. Predicting the future is impossible.

Secondly, prices may be right because you can set them, but in B2B, we have sales discounting too. I'm going to be wrong about that, so prices are going to be wrong.

So, wrong volume plus wrong prices means my revenue top line is going to be wrong.

Now we go down to cost. You definitely can't predict costs. You're going to be wrong about that.

And when you’re predicting the cost of actual developers, you’ve got to be right about how much you're going to pay them and how many you need.

So you're going to be wrong about both of those things, which means that your costs are totally wrong.

And then leadership's going to come down and make you pay for the administrative functions of the company. They're going to allocate cost to you. If they don't change their mind, you can be right about that.

And if politicians don't change their minds about taxes, you can be right about that.

So you're basically going to be wrong about all this, and you're going to end up with a revenue number that’s anyone's guess.

Now, just to think about how we think about this in the cloud, you can spend many hours working on this and you will many times in your career, but it's not the most important thing when it comes to pricing in the cloud. Pricing in the cloud is actually a little bit different.

When you price physical products, if you mess up the price and you come in with a negative margin and you lose money on every unit, eventually there's a maximum amount of capacity on the production line. There's a maximum amount of input that you can bring into the product.

But in the cloud, it's infinitely scalable, highly elastic, and you get billed later. So with cloud pricing, you can be infinitely wrong, which really sucks. So this is what I'm protecting against when I'm thinking about pricing for SaaS or in the cloud. I'm thinking about protecting against that infinite downside.

So here's what we're going do to give you a nice tool for protecting against the infinite downside.

The first thing is that we're going to take away years two and three. We're not going to think about those.

The second thing we're going to do is not think about year one. We're going to think about unit economics, which means that we don't need to worry about volume anymore. We're just thinking about a single nth unit.

Table highlighting volume and total revenue for a single nth unit

It also means that total revenue doesn't mean anything anymore because we've taken away our unit forecast. So we're just looking at prices. We’ve still got to deal with discounting, but that's okay.

You can see below that I also pivoted the cost. Now, we're talking about a single unit. I'm talking about the cost per unit, marginal cost.

I've calculated how much I'm going to charge per unit, and how much it's going to cost per unit.

I still have to deal with developers because I need developers, but I'm just going cheat and bump them down to fixed costs. I'm going to take these fixed costs as this is what the company generally pays.

Table that demonstrates developers being bumped down to fixed costs

So what I've done here is put myself in a position to calculate a marginal net margin P&L. What it tells me is whether I have a business or not, whether, at scale, I'm going to realize margins. It also tells me what the impactful cogs are that I can go run at and drive down.

So this is the first step financially when you start to think about price and when you start to think about marginal net margin. How am I going to do at the margins? Once my forecast is fully realized, do I have a business? Once my engineering teams have done their work, do I have a business? Have I protected myself against unlimited downside?

These are the key questions to answer before you go and spend three months on that fully blown P&L with a thousand assumptions in a spreadsheet.

Place = ecosystem in the cloud

Placement is a bit of a stretch in the cloud, but from my perspective, placement has a lot to do with ecosystem in the cloud.

There are a lot of interconnected products in the cloud. Many depend on each other to go sell. And what you want to ask yourself is, Who else has an interest in my success? And what am I doing to enable them?

There's a movie from the 90s called Field of Dreams. The famous line from it is:

“If you build it, they will come.”

But they might not come if you build it.

When you're running a product, a business relies on ecosystem. For example, if you have a B2B product and you're going to build a feature that must be integrated by B2C companies, that must be sold to a consumer in order for usage to then trickle back to you, you have to be very cognizant of whether the adoption of your service in the cloud is based on someone else's roadmap.

You want to be realistic about what external dependencies you have. You want to think about that as you're modeling out the business, and when you identify those external dependencies, you want to be super clear with your boss and your boss's boss that you have that dependency.

You want to be very mindful about the roadmap changes that you're asking them to take. You know how often you're wrong about your own roadmap, so think about how often you're going to be wrong about someone else's roadmap.

So if you ask some external dependency to make a very major change to their product to ultimately drive adoption to yours, you’ve got to understand that risk and you’ve got to understand how that timing is going to play out for you.

So, you really want to include as many of these partners as you can in the inner circle as we're building the product.

I've been wrong about dropping APIs off into market segments and waiting two years for the ecosystem to fully adopt them, put them through a full day of step cycles, and ship them. That's very bad as a product manager when you're twelve months in, and you're explaining to your boss and your boss's boss why you have no usage.

So, being wrong about the ecosystem and the timing of enabling your ecosystem is a very painful mistake to make. So get them involved early so you can go in parallel.

The 100-word messaging strategy

The cloud is very noisy. It has this promise of enabling customers to spin up and build apps quickly and innovate. All that is true, and that means it's more chaotic and it's more noisy than traditional IT where you have big gatekeeper vendors.

It's almost like the media in a way. The media used to be the big networks, and now it's lots and lots of entities that are out speaking to the public. It’s similar in tech right now and similar in the cloud.

Promote your products with the truth. It's what customers want to hear, and it's the most effective messaging that you can have.

Get jargon out of your messaging and your positioning. No customer has ever bought a product because a vendor told them that their product is best in class.

I'm going to give you a little technique that I use for messaging and positioning: 100-word messaging.

You want to be clear and concise. There are three steps.

The first is a fifteen-word message, where you just say what it is. Don't try, and don't try and be salesy. Just say what it is.

The second one is a fifty-word message. You say what it is, and say why it matters.

And then the third is the full-blown hundred-word message: say what it is, say why it matters, and provide adjacent information to flesh out your story.

I asked my product managers to write all three of these, and I'll show you a real example of a hundred-word message from a launch that we did a few weeks ago. This is for a product called S3 Glacier. It's our archive product.

The fifteen-word message is: “Amazon S3 Glacier Flexible Retrieval improves data restore time by up to 85%, at no additional cost.”

This is very direct and straightforward.

Now, I'm going to say why it matters:

”Amazon S3 Glacier Flexible Retrieval improves data restore time by up to 85%, at no additional cost. Faster data restores automatically apply to the standard retrieval tier when using Amazon S3 Batch Operations. These restores begin to return objects within minutes, so you can process restored data faster.”

And then we added the use cases as the adjacent information:

Now, whether you’re transcoding media, restoring operational backup, training machine learning models, or analyzing historical data, you can easily speed up your data restores from archive.”

Sometimes, if we have support from open-source projects at launch time, we'll use that as adjacent information. If it supports other AWS services or features within S3, these details matter to customers but don’t directly belong in the product definition itself.

So now I've asked you to write down all your decisions, and I've already asked you to write down your messaging, the question is, why am I giving PMs more homework?

Well, if you can't explain it in a hundred words in a very tight, structured, compact message, you don't have a message. And if you don't have a message, customers aren’t going to understand what you’ve built.

We live our products. We know them inside and out. It's very easy for us to write copy or messaging that seems good to us, but customers won’t understand. Forcing yourself into this very tight small package with some structure forces you to be clear and helps you to get across a message so that customers can understand what you’ve built.

More practically, if you have a message and it's cut into fifteen, fifty, and hundred-word form factors, you can then go out and enable marketing with whatever they want to do.

If you want to send a tweet, you can use your first fifteen words. If you want to put together a one slider on your launch for sales and you want to give them a little talk track, a hundred words fit really well with that one slider. On a website, fifty words fit nicely on a tile on a website describing a launch.

You can just give those words to marketing and it's easy for them to keep your messaging in sync and all the various ways that they need to put messaging out there.

Summary

It's not churn if you're making the product better. You want to iterate in your product definition. PMs complain to me about churn all the time, but this is how we make good stuff. We iterate. We use all the brain power in the room to come up with the best ideas.

One-way doors are terrible. Watch out for them. My product is very API-oriented, so I'm obsessed with one-way doors in the API. You may have other potential pitfalls or one-way doors in your product, so watch out for those decisions.

Before you launch and you're thinking about the pricing, leadership is going to make you write up that P&L, or they should. You should do it. It's a good thing to do, but focus on the margin. Start from there.

Be realistic about your external dependencies. We often have them. It sucks to be waiting on someone else's road map, and it's really hard to get people to change that road map.

Be very direct on your positioning. Don’t use jargon; customers don’t want to read it.