 Good morning, everyone. I'm John Kennedy head of product for 3d engines at AWS Today, I'm going to talk about the lessons and processes I've learned working at Amazon for three years and in Startup for eight years prior to that specifically. I'm talk going to talk about how to pitch products using Amazon's unique document writing process and customer research process If after this session you want to learn more about Amazon's working backwards process, I highly recommend the book working backwards by built by Colin Ryder and Bill Carr It contains many of the lessons. I will talk about today And it'll give you more context behind the Amazon writing process If you're even more interested in the process Maybe you want to consider joining our team if you have game industry experience and product experience I have a role open right now for a product manager and the link is there Or if not, we have plenty of product manager roles open at Amazon at the moment You can find them at Amazon jobs. I Realize there is some irony in explaining how not to use PowerPoint in PowerPoint Writing documents for pictures is not for all companies and not for all situations It works really well at Amazon It can work elsewhere, but it takes commitment and process change for most companies Docks are you docks usually take more upfront work than presentations? But they can significantly accelerate decision-making processes and give teams much more autonomy after an approval or a successful pitch I'm not going to talk about the doc review process today, which deserves a webinar unto itself But it is important to note that to make the doc writing process effective also takes a rigorous doc review process By the end of this session, I hope you'll understand some of the advantages of a doc-driven pitch process And you know what you should take away is our research process how to get the most out of customer conversations What you need to get started before you start writing and how to write a pitch in the Amazon style So if you're currently at a startup trying to pitch your product You might be wondering whether this is the right session for you The process I'm going to talk through is a product process that operates on a large scale at Amazon But it is also the process that I would use if I was running product at a startup today Actually came to Amazon from being director of product management at a startup I observed the Amazon doc writing process while working with Amazon on a partnership and knew that I wanted to explore it further Amazon PMs are constantly pitching Every major feature or new product at Amazon has to go through this process It's always been refined with a multitude of best practices the question questions answered in an Amazon PR FAQ Are the same that you're likely to be asked by anyone you're pitching to? Amazon execs operate in a similar way to the best type of edge capitalists rigorous review with significant authority after approval Amazon execs want documents that give them all the context they need to make a decision similar to anyone thinking about investing in your product At Amazon a doc is owned by one person and before I talk about customer research and writing It is important to know why Amazon prefers single-threaded owners for docs There is a culture of thinking big at Amazon that makes That means a single PM Can pitch for a series B level of investment Amazon trusts this process because the doc writing and review process is thorough The PM is in charge of doing the customer research taking all the imports from internal teams Writing the doc scheduling reviews and rewriting the doc based on feedback from each review This is a significant amount of work I give each of my PM's ownership only only one doc at a time and and it is their top priority One of the outcomes of the of writing the doc in this way is a clarity of vision Documents owned by one person are much more likely to be internally consistent based on strongly how believes and Making one person a single-threaded owner significantly improves quality through accountability Docs are a lot of work up front But if the doc can drive a solid decision that it can avoid months or years of adjustment of a product vision prior to launch I'm not against product pivots But the best information you get tends to be it tends to come ask you launch the product What can happen at companies that give approvals based on limited research is an initial period of uncertain development Resulting in trash or waste as the vision is adjusted So let's talk about the research we do The primary questions we're asking when doing the customer research are who is the customer? What is the customer problem or opportunity? What is the most important customer benefit? How do you know what the customers want and what does the customer experience look like? Every pitch every Amazon pitch starts with customer conversations And in fact the minimum bar before I would take a doc to review by By parties outside of my group would be 25 to 50 customer customer conversations That's great Those customer conversations lead to relationships and that's great for product launches because you can end up With a number of customers invested in your product prior to launch So let's talk about how a PM can work with other parts of the business to build The product pitch and do that customer research. The first thing a product manager has to do To talk to customers is actually set up A list of customers they want to talk to or set up a pipeline and the people who know how to do that best of course Are sales? Sales can be a great resource for product managers wanting to work out how to set up more customer conversations and getting in touch With customers it could be that you're working with an enterprise sales team and that will be one set of processes It could be that you're working with a lean sass sales team And that would be another type of engagement Or you could be a product manager who also wears the sales hat In which case you need to switch hats, but in all of these circumstances it really pays to understand the sales mindset A gap that I I see with a lot of our product management is rigor around Around this process of setting up customer calls and customer conversations and building customer relationships And so what I do From my pms and in fact you could just use a serum for this if if you want But what I do with my pms I get them to set up a pipeline of customer conversations a shared spreadsheet Now in a circumstance or even for us That where I can see all of the customers they intend to contact And talk to without this kind of mechanism It's hard to maintain the two to three customer conversations per week That you'd need to get through to get through the research The next thing you're going to need is a good way to encourage customers to talk to you and that's the hook You know, so the hook is something that you could use if you were If you're going to cold call an email a cold call customer or send a cold email Or have a chat to someone at a conference It could be something It could be something that you give to a salesperson to offer to their Accounts to encourage a conversation really the purpose of the hook is to enable you to To set up a time, you know 30 minutes to an hour where you can have have structured time with a customer where you can You know Actually go through a set of questions that can give you the answers you need so You know sales people are brilliant at coming up with a hook But I also give my product managers a little template that they can use When setting up a hook and so, you know, it's important to respect customers time and expertise And so often it's good to start with with With that respect and and also by giving them some context So we're investigating a topic area or a problem space and recognize your your expert in this area We're considering building a service to solve the problems in this area. We would like your input Then you can offer value. So with your participation, we can ensure that the service will be built to solve your problems specifically And this is actually really attractive to a lot of customers who have problems in the problem space You're thinking about and would love them solved with it with a product they can use And then there are also bonus benefits you can offer sometimes to get off a gift gift cards You can also offer early beta access to the product So when you're having your first conversations, what you're really needing to do is problem discovery If you want to know more about problem discovery, there's a great book called spin selling specifically for sales teams You know, I I think about adapting that process specifically for product to To discover problems in a space that we're we're researching Where the product has actually hasn't been built yet. So, you know, I've taken the example of of storage As the problem space for this example I was previously working as the principal product manager on awp storage gateway. So this is a fairly familiar A familiar territory for me But these are some of the open questions that you could ask someone when you're when you're doing problem discovery in a particular problem space For storage. So how do you store your data on premises today? This is meant to elicit a story from customers. It's meant to get them talking and talking about their process and their challenges You should be able to start to hear things as they as they as you kind of do research across multiple customers to see what's important to customers How does your data move from on premise to cloud similar kind of question? You know asking about a specific process and once you hear more about that you might dive in further Asking what types of data do you store for what purposes? This is once again just broadening the view of of why they're Storing data. This could be implied to any kind of problem space You're going to make sure that you go broad and open up conversations to elicit stories And what this should result in is a set of freeform customer notes, but as you're going through these initial conversations It's also important to gather email addresses And quotes from the customer email addresses are great. You want to build a relationship? I think, you know, it's pretty reasonable to contact customer every couple of months to build that relationship and potentially set up follow on You know meetings with them to do further investigation as you further down the track to solve the problem The quotes come in handy later when you're writing to to be able to model the voice of the customer The next next thing you want to do once you have a set of problems Is ask close questions to determine the value of each problem for each customer? And this you're really asking questions that that are quantitative here So, you know, a good example would be how much data do you store on premises in the cloud? Or how much do you pay if you're on premises data infrastructure each year? And then how much do you pay kind of question is often really hard to get out of the customer? But it's gold when you get the answer. So it's often worth asking How large is the team that manages your data infrastructure? This is a great question If you want to apply it generically what i'm asking is team size And that's so valuable because a lot of products are going to reduce the or they're going to automate and reduce the amount of You know manual work and the amount of people it requires to solve a particular problem And so by asking team size You're really able to to start to understand the value you could provide In terms of reduced headcount for a particular problem for that customer And that that translates pretty easily into dollars So after this you should end up With a table where you've kind of asked these questions You've got quantitative answers You know and you can start to see averages Across the answers so you can determine the value of particular problems To to customers So once you have we understand the value behind Behind those particular problems You can then go to engineering and start to talk about what is viable to solve You know, what can we build with a small team and meet a need that customers care about? So when you're working with engineering You may not actually have a table like this But this is an easy way to think about it So you've kind of determined the problem You may be determined the percentage of customers that care about that problem and the value per customer But with engineering you can start to understand how long it's going to take to build And the number of people it would take To to build that product to address that problem Once you've kind of come up with your theory about which One of these products is going to be the the best ROI You can then dive a little deeper with engineering to come up with a Tentative estimate for a product roadmap to give you a little bit more firm of a timeline And then a team size And to make sure that you're you're accurate With your estimates and you can put that all into the P&L later on So the next step once you've kind of once you've worked out viability Is to start working on the messaging and marketing Are great people to work with on the messaging marketing have a broad view of the market the market size And also the language that will resonate with buyers An effective mechanism to do this is is a structured What you know working backwards messaging framework So there are really a number of questions you put in another table that are very simple. It can be answered easily You know and in conjunction with marketing So, you know, some some examples would be type of organization and user problem statement And then there's a grid of nine I like to use to divide up the major problem Into into its parts into its most important parts within the messaging framework and I'm not going to Be exhaustive to kind of examine all of the parts of a messaging framework We use it amazon, but but you know, I'm going to focus on a couple of the really important parts It'll help you write the peer FAQ later on So the first part of that grid of nine is the top three customer issues And once again, I'm going to use the example of storage here So let's break down the issue of customers need to need to access data on-prem into a few different issues on-prem On-premises storage is limited Some data sets need to be accessed both in the cloud and on-prem And on-premises data infrastructure is a management burden. So, you know, what you're doing here is taking a very customer-centric view Understanding their top problems is probably five or six or seven or more problems the customer has but by finding by by narrowing it down to the three top problems You're really ensuring that you you hit on the top value when you're writing your document That customers will connect with across a broad spectrum of customers Once you've got your issues you can then connect them with features that will fix those problems So you can see that down each column We've got a connected set of issues and features and benefits which we'll get to in a second So feature one that could fix the problem of of limited storage on-prem is cached access to cloud cloud data as an example And once you've got these differentiated features The the final part of the three by three grid is the top customer benefits So, you know that that on-premise data cache is going to give you unlimited on-premise data storage Now each of these boxes you filled out I filled them out with one sentence And generally what happens is you'll fill them out with a whole paragraph each But it's good to eventually get to one sentence that really defines The the issue the benefit Sorry the issue the feature and the benefit this is going to help Help you with writing the document later on so absolutely fine to keep in your paragraph or more of data inside the the issues and features and benefits But by the end you should also have you know the kind of one sentence summary And then additionally in the messaging framework, it's good to have a get started section This is going to help you with your writing later on it doesn't need to be connected to those columns It could be three or four steps or or more but three or four steps is a good number And this this gives you a little bit more clarity about the product because once you start kind of Diving into how the product is used it gives you a better technical understanding of what the product is and will be useful to customers later on So, you know, once you've kind of brought all those elements together It's time to start it's a good time to work with finance to think about the overall viability Of of the product, you know, finance can help you put together a profit and loss to really determine your return on investment for a product and you can build in all of the Pieces that you've put together including headcount costs and infrastructure costs and sales and marketing costs all these kinds of things You know And and everything that we've created up till this point should actually go including this peer now should go into the document's appendix You know a peer FAQ should be about six pages in total But often we'll have 50 pages of appendices behind that with the supporting information or that information We've been gathering in this process of working with customers and you know the customer log and and then all of the Partners that we've been working working with up to this point So now we're ready and Ready to start writing and maybe we've come up with a draft peer FAQ You know press release and frequently asked questions document prior to this point But all of this information is going to make it a lot easier that we've gathered to to start writing and you know the point of a narrative document at amazon and it could be The structure that i'm going to talk about today, which is the press release and frequently asked questions structure Could be a different narrative structure But the the point of writing at amazon is really to lower the cognitive load for for a decision maker So that they can make a decision quickly and have all of the information available and some of the style points when writing include You know that we We don't use jargon because that that would increase the cognitive load You know, we want to be technical, but without but without necessarily using You know industry jargon, so it's easy for any on anyone to understand We you want to remove uh, it's important to remove unnecessary adverbs like extremely or very these don't actually add very much But uh, but but they do kind of cloud Cloud the message. It's important to avoid negativity. You don't really be talking about uh competitors You know and it's and it should be appropriate for c-level customers or uh technology trade journalists. That's kind of who you should be thinking about Pitching to in this document It should be completely comprehensible on its own It should have correct terminology usage grammar spelling punctuation And it should be reflective of what's planned for the initial launch Not aspirational because you want to be able to determine whether what you're going to originally initially launch is going to be attractive to customers So let's get into it. So the structure of a working backwards press release I've broken this down into all the paragraphs and the pr and then the faqs and actually Points one through seven here or fit into just about the one page So, you know the first page of the six pages the faqs should take up the other five pages And I'll explain why that's important a little later But let's dive into the structure of the uh of the press release to start with So it starts, uh, you know just very simply with header subhead one subhead two And uh, you know these could be uh, these should be very simple They should be the kind of the key customer benefit Uh, you know who are going to think About the example we've been using such a storage gateway. We might say, you know, um, aws announces Storage gateway, but in fact in your document you should use a code name And this is using a code name is really important because it takes away bias When people are thinking about your product and you're researching your product and you're kind of you're bringing it to them If you give it a descriptive code name, uh, you know that has the word storage in it even, uh You know in that problem space it really biases them to to what they think the product is and will do So coming up with the code name is really important. There's lots of schemas to come up with, you know, uh Of product code names, but it's important that the code name really has nothing to do with the product It's just something arb is arbitrary like, uh, you know, uh spice or a herb or, uh, you know, a sci-fi spaceship or something like that The subhead should be your kind of single, uh Single sentence complete value prop and then another subhead. It's great to talk about the ideal customers. You would want for the product So paragraph one, um, it has to be the complete summary. Uh, you know, when you're writing a pr It's often that it's excellently read paragraph one So you've got to include everything there and I've got a little template here But to give you an idea of what it might look like if I was actually to kind of play this out and replace The placeholders here it might be something like, uh, you know, uh, uh, Seattle December one 2023 each day aws announced aws storage gateway a hybrid storage appliance that makes it simple for it administrators to give us Uses access to unlimited data storage on premises And that's kind of the first sentence. It just lays it out. What it is. What it does next sentence. Um, You know, let's talk about the value so customers can use aws storage gateway to enable symmetric access to common data Datasets on premises and in the cloud through a range of protocols including s and b and nfs So I've given some detail. I've given the value prop, you know a key takeaway Um, and and then I might dive into some of the fact Functionality so I might say something like uh with storage gateway It's easy for customers to manage their storage appliance was all updates managed by aws and administration by their eight via the aws console Really condensing down the message that I'm going to talk about later on Into this first paragraph and then it's good to round it off just with how to get started if your product is not a Assass or you know a service like we would have at aws. You might you know have something to download or install But for aws, obviously you can activate everything from the console. So you can just say something like to learn more Visit, uh, you know amazon.com slash storage gateway or something like that So the next paragraph focuses on the problems You know, it starts with a top level problem And then we're going to take the issues that we built in the messaging framework And we're going to actually create a paragraph out of them So, you know, it's important to know that you can't quite take the issues verbatim I couldn't quite create a complete pf aq generator because You know, you have to actually tell a story It has to be a narrative for it to be easy to read the points have to flow together So it might sound something like this, um, you know So the top level problem We might say something like more and more customers need low latency access to increasing amounts of data on premises desktop applications and high performance computing Generating petabytes of data that the most part is Is stored on premise and large storage storage arrays something like that And then for each of the issues you could go on and say, you know For maybe issue one these storage arrays are limited in size by their hardware and available space on site Meaning that each time a customer runs out of storage space They must undertake significant planning to upgrade slowing down the user processes and ultimately limiting innovation So you see i'm capturing uh the point in in a narrative Sentence or two there and then i'm leading on to my next sentence, which should be the next issue So something like much of the data generated will also eventually need to be accessed in the cloud for backups Further analysis or used by cloud applications The process to move this data from storage arrays can be time time consuming An eventual access in the cloud may not be consistent with the access protocols on premises complicating application migrations to the cloud So try to join up the sentences but still maintaining the issues that i've laid out And then the final sentence might be in addition on premise storage arrays require ongoing maintenance and physical security at each location So the next paragraph is going to be the solution and we're going to connect You know with those issues we're going to make sure we address those issues With a combination of the different features coupled with the customer benefit So the the top the top sentence and the solution paragraph is just what the product is and the and the top level customer value so something like You know aws storage gateway is a managed hybrid storage appliance That gives customers symmetric multi multi protocol access to unlimited storage on premises in the cloud right, so what it is Customer value prop top level and then you can start to connect your features and your customer benefits into sentences So something like storage gateways managed on premises vmware appliance provides an on-premises cache ensuring low latency access to unlimited storage on premises for users something like that So you see i've connected up the feature and the benefit And and address the issue that we've mentioned the previous paragraph that should flow into the the next sentence So similarly I could say something like the appliance is connected to a cloud service that provides access by the same protocols To the data in the cloud including s and b and nfs You'll notice that i'm going the layer down in detail now in these i'm giving a little bit of extra information To interest the customer a little bit more in each of these features and customer benefits So final sense could be something like a storage gateway is managed by the cloud by the In the cloud ensuring that customers can set and forget the appliance And automatic maintenance windows can be set up to ensure that storage workloads are never interrupted critical critical times to the business So once again just expanding You know that that on that feature and customer benefit issue in addressing the issue in this paragraph So from there we're going to have a lead a quote and this quote is meant to capture the value provided to the customer Really the why it speaks directly to the main benefit the value proposition the differentiator But the tone should be humble and focused on the customer And the the big difference here is the the this kind of this paragraph this quote is conversational And you know one of the great advantages here is if you have a top level approver who's going to approve this They can be the person who you know is cited in this quote And so by putting it in their voice You can really connect with them and they can of course adjust this quote in the review And really put their claim, you know put their stamp on on the the pitch So final paragraphs are getting started paragraph as I mentioned when we're talking about the the messaging framework The getting started can really just dive a level down into the technical detail. So You know so a customer or user or an engineer understands a little bit more about how The product is meant to operate So I might say something and this this doesn't have to have an overall summary This can just be step by step So I might say something like to get started with aws storage gateway customers can install the VMware appliance on premises at each location where they need access And then the next step is something like then they can connect the storage gateway service their authentication system By the aws console Finally, they set up file stores by connecting storage gateway to storage buckets in the cloud These file stores will now be accessible on premises by the appliance in the cloud within the selected bpcs Really simple. It just gives the next level of detail down The customer quotes are really important and you can actually use the quotes You got during your research to speak in the customer voice What you want to put here is that the customer quotes that would apply after the service has been launched And actually the way I think about it is I bring customers into the beta period and they can give me these quotes And they'll be actually quotes that I get from customers by the time we launch the product So two to three minimum, but it should cover each of the major Issues sometimes, you know, so usually how three issues you could then create three quotes from three different customers And they should be believable written in a human voice, but they should also address the particular business issues of that particular customer So let's talk about the the FAQs you know the FAQs By the fact that they're written to the customer They they mean that there's no extra context there and as many of the FAQs as possible should be written to the customer We're going to talk about internal FAQs in a minute But most FAQs should be external and the first set are just a set of five standard questions What are you launching who should use it? Why should they use it? How do they use it? How much the cost and these are pretty standard across all products But then you then you get interesting questions and these are the questions You all have been asked later in the research as you kind of solidify your vision around the product and as you have ongoing You know conversations with customers And repeat conversations with customers. I'll actually start to ask you questions about the product And that's that's exactly what should go into this section They should also you should have a set of questions describing the major features in details So it really really gets those And to explain the major assumptions that you made when you work with sales marketing engineering, etc Then you should have then you probably should end You know with a set of internal FAQs to describe things you can't actually describe externally These might include market size and competitive offerings pricing research Details of proprietary technology and and maybe a summary of your P&L if you need to bring that in to the first six pages So at that point, you know by the end of the the FAQs, you should be at six pages or fewer It's very infrequent that will end up with less than six pages And the reason is that we usually blow out to eight or nine pages And then have to shorten our writing and you know, maybe cut out some of the less important questions So finally just briefly on timelines It's incredibly variable how long these will take to create But you know given a cadence of two to three interviews per week It's pretty reasonable to get all the research and writing done within a three week period And then it really depends on the size of your organization Talents and we're going to take to go through peer review and executive review and approvals So That's it. Thanks for attending You know, that's all we have time for today But if you're interested in this process and you're interested in product product management You know, please reach out if you want to join the team and you have game industry experience Or if you just have questions about the presentation, you can reach me on via email or LinkedIn or Twitter here And thanks for coming along