 Hi everyone, my name is John Kennedy and I'm going to talk to you about working backwards from the customer. If you want to know more about the Amazon working backwards process, there's a great book by Colin Breyer and Bill Carr called Working Backwards. I put a link here on the slide, you can go and check it out if you like. Really good for understanding a little bit more context and history around the working backwards process. Today I'm going to talk about how you can do customer research in a structured way that will flow directly into a working backwards writing process. We're also going to talk about how to do that writing, how to create a pitch in the Amazon writing style. And then additionally, we're going to talk a little bit about how that doc that you write can help you pivot a product. When docs are written for a product launch or a feature launch, but they can also be written for a product pivot. So to kick it off, let's talk about customer research. Every product that Amazon launches starts with extensive customer research and in fact the minimum bar for a product at Amazon is 25 to 50 customer conversations even before a document has its first review. That's a high bar, that's a lot of conversations. So there's a structured process you can use to set up those conversations and get the data out that you need to start writing. Products that do follow this process also have an added advantage in that by building a relationship to those customers, you can have customers who are going to beta your product or even launch with your product and generate early revenue in your product life cycle. So a great way to get started contacting customers is to work with the team who contacts customers all the time, the sales team. It might be that your company has an enterprise sales team or a lean SaaS style sales team or it might be that you're a CEO or a product manager who also wears the sales hat. Regardless, when you want to set up customer meetings, it's great to get in the sales mindset. And what I do to help set up a pipeline is actually create a spreadsheet. Now you can use a CRM as well to create a pipeline of customer conversations, but a simple spreadsheet shared among people who would be doing those conversations is also a great way to start. It can be very simple, just a list of companies who you want to contact. If you're going to try and have 25 to 50 customer conversations, you might need 100 to 200 names on that list. You can build that over time and update them as you have meetings or set up meetings. Just a very simple pipeline is something that a lot of product managers miss. And the reason is that if you want to have that volume of conversations, you've got to get programmatic. So once you've got that list of customers to contact, the next thing you'll need is a good hook. So a hook is something that's going to get the customer interested in talking to you. And I have a structured way that I put together a hook for product conversations with customers and it looks like this. So you can start off by just expressing your respect for their time and expertise. You probably chosen the customer who you're contacting because they have the problem you're talking about or they are adjacent to the problem space that you're talking about. So a great way to start is to say something like we're investigating problem space and recognize that you're an expert in this area or you deal with this issue regularly. And then to go on, you can give them some context best to be direct. We are considering building a service to solve this problem or this type of problem. We would love your input. Then you can offer some value with your participation. We can ensure that the service we build will solve your problem specifically. You can also offer a different type of value you can offer them the opportunity to eventually be involved in the beta or even go as far as to offer a gift card or something like this. The direct approach works for plenty of people. So this kind of pitch can be used in an email or a LinkedIn message or even if you're reaching out through the sales team, if you give a salesperson a really punchy hook, they can actually put that into their own communication and that can help you get conversations. So for the first customer to contact, you want to be asking open questions that's going to enable the customer to tell their story. So a good example of an open question for a storage product that targets on-premise storage might be something like, how do you store your data on-premises today? And with that question, a customer is going to be able to tell their story and it may only be that you need only five questions to fill a half an hour to an hour phone call because what you want to do for each of these questions is really dive into that story and understand the pain points and get some technical detail as you're going through these questions. And what that should yield to you over a number of customer conversations is a set of problems. So the notes that you take for these conversations are really important. These conversations become a record that you can use later for various purposes and some of the things that I've found interesting to keep as a part of the notes are surprisingly simple. The email addresses, you might have one contact customer, if you get everyone's email address from the call, you can do a follow up and potentially make more contact to that customer and build relationships with those people. Problem statements, it's great to have free form notes or stream of consciousness notes but if you can also write out problem statements of the problems those customers had that's going to help you organize your custom notes later. And then quotes, if the customer has a really clear pain point they might give you a great quote around that pain point and that's going to help you later on. Once you've identified those big customer problems, you want to, the common problems across many customers, you then want to start asking quantitative questions to understand the value you might deliver by solving those problems. So great quantitative question along the same theme for data storage on-prem might be how much data do you store on-premises and in the cloud? And this is going to give you probably an answer in terabytes or something like this but it's allowing you to estimate the value of the problem. You can ask directly, you can ask a customer how much they pay for a particular solution, sometimes that's a little harder to get from them or you can ask indirectly if they can tell you the size of the team that manages a certain issue for them, that's a good proxy for how much they're spending on a problem right now. What you should end up with after asking a number of customers these quantitative questions and you shouldn't just ask three, you want to have at least 20 answers for these types of questions to get a good sample of customers but it should give you an understanding of the size of the problems that you could possibly address for customers. So once you've got all that research together, it's time to start writing. And I have a process that I use rather than going directly to a peer FAQ which is the standard Amazon format for product launches. I start out with a messaging framework so we're going to talk about that in a second but just start with to understand why Amazon writes. The reason is to lower the cognitive load for a decision maker who might be giving you headcount for the product you want to build and launch or the feature you want to build and launch. And so putting the writing in a standard format helps with that. Also being clear, concise and direct, explaining without technical jargon, using correct punctuation and grammar, very important and using consistent terms also very important when you're writing. So let's talk about that intermediate format that I use called a messaging framework. This is before we write the peer FAQ. We can start out by asking some simple questions. So you've just spoken to a lot of customers and you've found out their common problems. The problems won't be evenly distributed across all the customers. You'll have certain problems that certain types of customers have. For your biggest problems, you want to identify the types of organizations that have those biggest hardest problems that are worth solving and then you can identify the type of organization who you think is going to be your customer and that could be a couple of different types but you can write it out here in the messaging framework. And then you can write down the end user. So the customer probably has a role type who's going to actually use a potential solution to this problem. And then the problem statement. The example here, customers need access to petabytes of data storage on-premises is a very simple statement. It's the high-level big picture issue that customers are experiencing. And from there, we can break it down into the top customer issues. So as you've had those conversations with customers, you should have started to see the pattern that there are very specific issues within that larger issue, the example being data storage that they have. And I've got some examples here. So we can talk about the fact that on-premises storage is limited. Some data sets need to be accessible in both the cloud and on-premise. And the management of the infrastructure is time consuming, it's a management burden. So this is the breakdown of the three biggest issues. Once you really understand those high-value issues that you're going to be addressing with a product or a feature or a pivot, you can then talk to the engineering team about how you might address those issues. So you've worked backwards from the customer problem and now you're talking solutions. So there might be various technical approaches that you could use to address these problems. But in talking with the engineering team, you should be able to find a good theory about the set that you're going to use. And of course, you can review these with lots of people later, but you can take a stance on what the technology should be to address those issues to begin with. Once you've got those technical approaches or the what, you can think about how that actually addresses the customer issue, how you would state the technical value you're providing. In the case of feature one, which is the cache on-premises for cloud storage, it's cached access to cloud data that addresses the issue of limited storage on-premises. And it could be access to SMB and NFS endpoints on-premises and in the cloud that gives that symmetric access to data. So these are examples now of features rather than just the technology. So this is the how we address the issue. And from there, you can drive the customer benefit so that cached access is going to give you unlimited on-premises data storage. So you can see how we've worked from the customer problem to the solution and then backwards into the customer benefit. So you really understand the why now. The final thing for messaging framework is the getting started steps. And this is just a way to break down how a customer would use the product. And it's really useful to have this. Anyone technical reading a document is going to get a lot out of the getting started steps will help them understand the product. So then you've got overall the messaging hierarchy. And we haven't talked about the one sentence value proposition yet. But this is really the last thing you write. It could become your head or subhead or a first sentence. This is really once you understand the benefits, all of those three customer benefits that you're providing. You should be able to write a one sentence value proposition that really encapsulates the value you're providing with the product feature or pivot that you are proposing. So from that messaging hierarchy, we can then get started working on the actual document that we would use for review. We can keep the messaging hierarchy and appendices can be useful to have a structured template or a spreadsheet down there to explain certain parts. But the document that Amazon would use predominantly for product launches, etc., is a peer FAQ. And a peer FAQ is a narrative. It's a document that is very structured. And this is the structure that you can see here is the standard structure used by Amazon as you start with your heading and subheads. You've got the first paragraph is a summary paragraph. If a person was only going to read one paragraph, this should be able to give them all the information they need and then into the problems and solutions, lead a quote, getting started, etc. You can start to see how this maps back to the messaging framework that we just discussed. So digging in on the heading and subheads can be very simple. The heading can just be company announces product code name. Product code names are important during the research and pitching process because you don't want to bias the people who are reviewing your product with an actual name with a descriptive or a suggestive name. Having a product code name that could just be the name of a fictional spaceship or a plant is going to help people keep an open mind about what the product could be. The subhead, you can use the once in value prop or just to template like this, product description enables key customer benefit right at the top. And then if you're a subhead too, you can actually take the org type that you had in the messaging framework and think about some of the key customers of that org type you might want as customers. And this can help a reader understand the type of customers that you think are suitable for the product. So coming down to paragraph one for PRFAQ, you can see this structure here. This is a good example. You don't necessarily have to use this structure. But the first sentence should really encapsulate the value. Here's a template that I use. Today, company announced product code name and then the description of the product. That's really the watch that makes it simple for primary user role. And you can take that from your messaging framework to do the thing to get the value. You can then explain the product further. Customers can use the product to gain specific big claim value. You can make a big claim that you have to be able to support it. And then maybe with product code names, easy for customers too. And you can go into specific functionality. So you might take the three capabilities or features you've written and explained them in very briefly in the first sentence. Then great to finish off the sentence that just describes how you're going to get started with the product. So paragraph two is where you describe the problem you've identified. First, you describe the top level problem. You could do that by saying something like customers in these industries, listing out the industries, are experiencing this top level problem. You don't want to talk much about competitors. You don't want to get too negative. This is meant to be explaining the world as it is. So that you can then extrapolate on that by explaining each of the issues that you've discovered during customer research, taking them straight from the messaging framework. You can then, you need to then link those issues together in a narrative so they flow so it's easy to read. But you can take them directly from the messaging framework. Once you've explained the problems that customers are experiencing, you can then write the solution paragraph. And I've come up with a really formulaic way to write the solution paragraph. There are lots of ways to write this. And I think that it's more interesting if you go beyond the template and write in a way that's compelling and punchy. But this can be a great starting point. So you want to start out your first sentence describing what the product is. So product code name is the description and it provides this specific value. And then from your messaging framework, you can take the differentiated features and match them up with the customer benefits. And so your next three sentences, you can really just follow those columns and differentiated feature one provides customer benefit one and so forth. So after you've written up the solution paragraph, a great next step is to write a quote from one of your leaders. This really does two things. One, it gives you the opportunity to make a big claim in a conversational voice. And two, it also gives you a leader the opportunity to insert their own voice into this pitch. So as this pitch either goes further up the chain of command in your company or if you're going to use this publicly, they can have their voice in the press release. This should capture the why for the customer. So the last paragraph of the press release is the getting started paragraph. And this is really where someone technical will look to really understand what the product is. If you can describe how a user gets started with the product, that's often a really good way to understand the product technically. So you can take this once again straight from the messaging framework. You want to join each of these steps together. So they're easy to understand, easy to read, but really simple paragraph to help people understand the product. From there, having two to three compelling customer quotes can be really powerful way to finish off the PR. So these customer quotes should encapsulate one, for each customer quote should encapsulate one of those columns. So it describes the customer benefit in the voice of the customer and focusing on the impact to their business. So to follow the standard format, then you've got the frequently asked questions. And there are a set of standard questions you can ask that'll help expand the description of the product. So you can really dive to the next layer of detail with these questions, what are you launching, who should use it, et cetera. But you're still staying in the voice of speaking to the customer. So you're answering these as if you were answering them across the table to a customer. And internal FAQs we'll talk about in a second. These are the ones that you really couldn't answer to a customer, but as much as you can, you want to answer questions to a customer because that means that there's as low context as possible and that's going to make it easier to read for everyone in your company. So anyone reading this, if they can read the answer like a customer would read the answer, then they don't need any of the technical context necessary or any other context around the product. So beyond the standard questions, you should be taking questions that you've actually discovered during your customer research and then answer them in the PR. And this could be the research that you've done with customers. It could be the discussions you've had with technical staff internally or marketing or finance or sales. All of those groups can provide really good questions that you can answer in the FAQ and that helps everyone understand the product more thoroughly. And then finally, internal FAQs. So these are things you really couldn't answer to a customer, things like market size or competitive offerings, the P&L if you've got a theory around the P&L to start with. You could work with finance and come up with something really sophisticated, but often early in the process when you're finding approvals, a lot of it is going to be speculation and so best just to have a summary. Right. So that's the standard structure of a PR FAQ. End of the messaging framework can help you get there. And that structure is often used to get approvals for a product launch or a feature launch, but now we're going to talk a little bit about how you can use that process of customer research and the standard format of a PR FAQ to help or to pivot any given product. So you've gone through that process of research. You've built the artifact, which is the PR FAQ. And by the way, another way you can do this is you've done the customer research as I've said before and you can create some other type of artifact. It doesn't have to be a PR FAQ. It could be a document, it could be a presentation. In this case, we're going to talk about using a PR FAQ. And then when you go to pivot, you can use that artifact to communicate clearly and broadly to the organization. So once you've had approval for the pivot, you can take that artifact, the wider organization so they can understand the why and the how and the what. Pivoting a product is a huge undertaking, often harder than launching a product. And so really establishing the why with everyone is very important. And as much as you can tell people in meetings or you can announce through public announcements or emails having a living document that people internally in the organization can go back to to understand the why and the what is really powerful. So first step is building that artifact. Second step, reviewing widely and broadly so everyone understands this and making the link to this artifact available so people can go back to it if they need to. And then creating a closed loop process for the reprioritization of work. So in building your product, you've built a roadmap, people downstream of that have made plans, those could be engineering plans or marketing plans or sales plans. There's a whole range of activity that revolves around the product strategy and changing that product strategy, changing your product really requires everyone to think about that. A difficult problem. So it really is a program management problem of working out every plan that's affected by the pivot and then tracking those plans and helping people adjust their plans. And then finally, once you've executed the pivot gathering ongoing sprint data to understand if you've actually made the pivot if there are any leftover processes that need to be adjusted time and time again I've seen companies go through a pivot and then still have old processes running that were in service of the previous goal. It's hard to have people let go of specific goals they have they might have career goals attached to some of the tasks there. And it's important to take people through through the why, how and what so they understand why they're moving but also then ongoing and just have a set of checks and balances to make sure that everyone is on board with the new vision. So that's about it for the presentation today. Thank you for listening. I hope you got something out of it. If you'd like to know more feel free to reach out on email or LinkedIn really happy to answer questions about the presentation today. Thanks for coming along.