[Rebroadcast] Answering Your #1 Question: What's a One-Pager? (With Daphne Funston)

Maggie: Welcome to Build. This is Maggie. Today, I'm re- releasing one of the top listened to episodes of the podcast. The one pager episode, this is our version of the spec or the PRD and is perfect for smaller teams and products that are in the first part of their scaling journey. I wanted to share this one again, to refresh everyone on what it was because in the past couple of quarters at Drift, we've scaled enough that we've had to actually evolve this original template. I'm going to be releasing part two of the one pager story in the next couple of weeks so for now, enjoy this look back into the archives where Daphne schools me on how to use one pagers effectively. All right, welcome to Build. This is Maggie. Today is a different type of episode because rather than having a guest from another company, we're answering your number one question that you've sent in, which is what is the one pager? And I have special guest, Daphne also on our product team here to help me describe exactly how we use this tool to build better products at Drift.

Daphne: Hey, Maggie.

Maggie: Hey. Okay. We, unlike DGI have so many notes because I wanted to give this the justice that it deserves as a thing that we do here on the team. But I think people have asked about the one pager continuously through email and Twitter because it's the first step that we take when we're going to go and start a project. And it's really an artifact that we use as a team to scope and define a problem. We've talked about, we talk to customers all the time and the first step that we take is defining the problem that we want to solve. And so unlike maybe a spec, which is something I've used in the past or product requirements doc or you had a one pager also at Buzzfeed, this is really specific to the problem and all the context that you have around it. It's a way to share context and research with your team. It's a well researched story that you can tell about what you want to do. And what it's not and this is really important, is a description of what you're building. It's not a list of requirements. It's not a list of features and it's not something that you can just drop off with your engineering team and expect them to build. I think for me, the reason why these things are really important is because they help us as PMs frame scope and communicate the customer problem to the team because we're spending so much time talking to customers that for us, we might be really familiar with something but we need to sort of bubble up all that information and share it back with the team.

Daphne: Yeah. I think that's the really critical piece, is you've been doing all this research on your own and talking to customers and looking at the data and now you kind of have a chance to distill all of those learnings into something that really arms your team for helping come up with a solution.

Maggie: Right. Exactly. And I think there, also another important point is that we use them to get the teams excited and sort of help them build empathy I think with the customer. And then also as living documents that sort of move through the project with us. They're there the beginning when we define their problem and then we add to them as we go. And so there's sort of a record of the decisions that we've made along the way.

Daphne: Yeah. That's the dream.

Maggie: Yeah. Okay. There are six sections in a one pager, it's deceptively simple and they are the story, background and context, the goals that you have, any requirements and constraints, a time box for the project, as well as concepts and references. We're going to go into each of those quickly in detail. And one thing I want to call out is that the audience for these is really important. The audience and the reader isn't necessarily you, it's your team, which is the engineers obviously, designers you're working with but it's also often at least here at Drift our executive team and the other people at the company who want to know what we're working on.

Daphne: Right. Definitely stakeholders.

Maggie: Yep. The story, this, I know we've talked about copywriting and storytelling a million times on the show. And this, I think to me at least is probably the most important part of the one pager because this is where you hook your listeners. You describe what's going on, you describe what you're building, why it matters and who your customer is and what it means to them.

Daphne: Yeah. And I really try and frame this part of my one pagers as the job to be done, which is a framework we use at Drift, I've used in past companies. Kind of set forth by Clayton Christensen. But the thing that I find helpful about jobs to be done is that it forces you to zoom out from your product. Don't just think about how would it be easier for somebody to chat in Drift but think about it in terms of what is their ultimate goal? They want to engage in conversation with buyers and if you're agnostic from the product that's solving it, it can really make sure that you create your product in a way that would cause a customer to hire you to solve that problem for them.

Maggie: Yeah, absolutely. And I think that the better that you can paint that picture and the more crisp you can be, the easier it is to A, build the thing that you're trying to build and B, write the rest of your one pager.

Daphne: Yeah. This is the part that has the most revisions for me generally. And that's okay I think as you go into writing one pagers, to know that you'll start and it'll evolve as you are able to better articulate exactly what is that problem you're solving? What is the job to be done? And trying to make that really succinct because I think one thing is if it's taking you a lot, a lot of time to describe that and many sentences and paragraphs, you haven't really quite nailed exactly what is.

Maggie: Yeah. I a 100% agree. And I often find myself filling out the rest of the one pager and then coming back and finalizing that first part, as I remember all the context that I've gained over the course of whatever it is I'm working on.

Daphne: Definitely.

Maggie: Okay. Second part, background and context. This is really where you describe the insight about your customers, your market or your business that led to the job to be done. This is where you expand on the story you told in the first section, it's why this problem matters. It's why anyone on your executive team or your other teams or your engineers or whoever should care about it. And it's really just all about the lessons you've learned and the market that you're in and why this problem is relevant to your business.

Daphne: Yeah. And this is a great time to, I always include direct quotes from customers, visuals where I can. Here's what the experience is right now. Here's why it's hard. Just so that you can really demonstrate to the reader, the context around the story that you're telling.

Maggie: Yeah, definitely. I think this is if the first step in the story is, as a marketer I want to do X so that it can Y and then second part would be okay, it's the background. This problem is important because this big theme is happening in the market and we're trying to build this new product and this is one of the core problems that we have to solve to get to the business outcome that we have.

Daphne: Yep. Definitely.

Maggie: Okay. Step three, goals. Again, this is mission critical for everyone to understand for every single project. It's something that two jobs ago at TripAdvisor, this is something that we focused on a ton, which was, you need to understand the impact that this project can have and have a concrete numbers based goal. It's not enough to say," Oh, it's going to make this project better." Or," It's going to make this user happier." You have to be able to understand the impact that you're hoping to get out of the future.

Daphne: Right. And this goes in a little bit to the next part but the timeline on which, you could have a whole podcast devoted to goals.

Maggie: Yes, definitely.

Daphne: Serious.

Maggie: Maybe we'll do one. Yeah. You have the goals. Step four, requirements and constraints. I think this is an interesting title for this section because we actually don't include requirements in the sense of what you should build. Instead it's, what's the box in which you're working? What are the things that you know need to have happened? Or what are the, I think you mentioned, risks and dependencies that you need?

Daphne: Yeah. And it's a good way to scope the problem. This can't impact X other product or can you do this within the scope of kind of these parameters depending on which product is? But I think it's a good opportunity to narrow the focus of the solutions that you're generating so that you don't get distracted.

Maggie: Right. And this is also where I at least start to capture all of the unanswered questions or as we call them, open questions that I have about whatever it is that we're working on. Okay, I'm writing this one pager, I get to this part and I already know that I'm going to have a dependency on another team or that this part of the product is really old and legacy, might take us twice as long to work with. Or whatever the thing is that you already know might be a roadblock I would call it out here so you can remember to look into it and make sure you're not going to miss it when you build.

Daphne: Right. Definitely any risks that you can identify up front.

Maggie: Yep. Okay. Step five, time box. So this is how long you have to solve the problem. And as we were chatting before this Daphne, Daphne and I both admitted that we leave it blank but in theory, I think what Craig would be telling us, our VP of products, is that this is where we understand how long this should take to build, how much it's worth. How much time it's worth, I guess.

Daphne: Yeah. And I think, again, it can be a good kind of forcing function to set a deadline that helps prioritize and make sure that you're devoting a reasonable amount of time to solve this problem, depending on how important you think it is. I think you can use your judgment on whether or not it's required.

Maggie: Yeah. I try to give a sense at least, if it's something that we need to do in the quarter, if it's only worth a week or whatever, just to give a relative sense. But again, this is also where I do occasionally come back and put in, let's say we've gone through the process of writing the one pager, we've done a story time and now we're actually building the thing then I might come back and put details on milestones later on.

Daphne: Yeah, absolutely. I think that's when it's really helpful is to be able to show when we expect to accomplish different pieces of this project.

Maggie: Right. Okay. Sixth and final section and this is probably outside of the story part where I spend the most of my time and that's what we call concepts and references. And this is where we put every single piece of relevant information that you have sort of, I often just have a grab bag of things at the end of the one pager and that's stuff like role models. Who has built a feature like this out in the market that you want to learn from or you want to copy or innovate off of? This is where you'd put tear downs. Have you done an analysis of someone else's tool or feature or way they've solved it and you've learned something? Put it there. This is where I put all the customer context that I have. All the quotes, definitely just pictures of Slack messages and pictures of emails and whatever and just any details that we have of things.

Daphne: Yeah. I think I use it a lot for all the research that I've done that led to this so that if people want to dig further they can. But also because it's great for posterity just to go back and be able to reference it later so I'm not trying to dig through notes somewhere else.

Maggie: Yeah, totally. I think also sometimes you might have concept designs or concepts that you put together and this is where I would put them just so everyone can see them, learn from them and have them in one place for sure.

Daphne: Yeah. And as the design process goes on, as you were saying, we definitely always add them to the one pager so that you can see how things evolve.

Maggie: Yeah. Okay. Those are the six sections. Again, it's the story, background and context, goals, requirements and constraints, time box and concepts and references. Super simple. These shouldn't take a ton of time to write because in theory, you've already done the work by the time you get to the point of writing them. One other thing I want to call out is that we use one pagers at different points in our process. We have at least two types that I could think of when I sat down to work on this, which is the vision one pager and then the actual one pager. Vision one pagers would be okay, we have this bigger problem that we want to solve, maybe over the course of the quarter and this is the full scope of that. Whereas the individual one pager would be the first step in solving that problem.

Daphne: Yeah. When you were mentioning that in your time box you might have the different milestones, generally for me, each of those milestones is its own one pager.

Maggie: Oh, okay. That's great. I should do that. I think we also wanted to add a couple of other tips and tricks that we've learned along the way that make one pagers helpful and something that another person told us here is that write for your readers and not for yourself. Think about G2 reading your one pagers on the Wiki and maybe he has no idea what you're working on but you could add enough context that he could pick it up and understand why it's important.

Daphne: Yeah. And I think alongside that, anticipating the questions that you're going to get from your engineering team or others when you present this is really important because always people are going to have questions that you don't think of. And that's great. That's actually one of the goals of the one pager is to start generating these questions from other people. But the ones that you can think of on your own, you should already be able to address in the one pager. That's a good kind of exercise is what questions do I think are going to come up? And are they covered? Have I addressed them here?

Maggie: Yeah. And I think another thing that our team member called out was think read you one pager from the perspective of someone who has no context or is not technical and then from the perspective of someone who is technical. Especially if you're working on something that is deeply technically technical and technically challenging then you probably want to understand where those big issues are going to be and like you said, call them out.

Daphne: Yeah. And I love that idea. I'm definitely going to try that. That's not something I've done yet.

Maggie: I know. In the process of researching this episode, I've learned a lot of things I should have been doing, which brings me to my second point, which is don't rush the job to be done or the story. And I think we were talking about this earlier. I think it's really easy to write one that's sort of simple and not useful, especially if you're sticking to that strict job to be done framework. I think it's pretty easy to say something like, a project that we just shipped a couple weeks ago on one of the teams that I work on as a marketer who's using Drift, I want it to be, to build bots so that I can launch more bots. That's easy to write and that definitely is a job that we're solving but you can't use that. There's nothing I can do with that. And so I think spending the time to write that story in a way that's compelling is worth every second.

Daphne: Yeah. And to your point, nuanced. You don't just want to build better bots, what is the goal that you're trying to achieve? And so again, how can you zoom out from the solution and really think about the job itself?

Maggie: Yeah. That's true. Better bots is uniquely unhelpful for a team member. Third point that we wanted to bring up was we've mentioned this before in the podcast but I think here it's really relevant is show, don't tell. Of course we're writing one pagers and there's words on the page but the more pictures and the more examples that you can give from real life where you're not just talking, I think the better. Because nothing gives customer context better than a recording of a customer.

Daphne: Right. And so direct quotes for sure. Often like we were saying, it's just screen grabs of conversations with customers. Also, I include a lot of graphs of data that apply to the problem that we're talking about. I do think those visuals, in a basic way, also break up a chunk of text which can be helpful for your reader.

Maggie: Super true.

Daphne: But also just provide, I think visuals are often a way that people learn more easily and you can communicate what you're trying to say through it.

Maggie: Yeah. And then I think another thing that we mentioned a little bit, which is keep adding to them. I don't view a one pager as a moment in time, it's sort of the start of a piece of work and then it moves with me throughout the project. It's where I keep track of who's in a beta, the things we've learned, like you mentioned earlier, the decisions that we've made, the designs that are happening throughout the process. It's sort of really nice to have that all in one place so that no matter who wants to know what's going on, it's all there.

Daphne: Yeah. And if you're worried about these becoming really long and unwieldy, use them to link out to those other documents. We have a big other design document breaking down all the design needs we have for a particular project and it's just linked to the one pager, which is really helpful.

Maggie: Yeah. Yeah. I've definitely used when I've worked on things I've gone back and searched the Wiki and found old one pagers and have pulled context and research out of those ones for new ones.

Daphne: Yeah, absolutely. I think all that research is often reusable because maybe you weren't thinking about a particular piece of what a customer said but now you're focused on a different problem and that's relevant again, so you can come back to it.

Maggie: Yeah, totally. Okay. I want to talk about the best and worst one pagers. And we were talking about signals that you can use to know whether you're on the right track. And so Daphne, when you're writing a one pager, how do you know that you have a winner?

Daphne: I think there's a feeling of how easy it is to write, how much material am I drawing on? If I have a bunch of customers with similar feedback, it's probably going to be an easier one pager to write. Because it's directly related to how common is this problem? How sure am I that this needs solving? that's definitely a big signal for me.

Maggie: Yeah. I think for sure, how easy it is to write, how easy it is to define the job, how easy it is to get the research together definitely is a signal, for me at least. I think also if you find yourself trying to spin the story or spin the problem that you're solving in a way that fits into some bucket, that would be a warning sign, I guess, on that front, that I'm going down the wrong path. And that's like, I'm trying to fit this project that I want to do into a goal or into some priority that we have and I probably shouldn't be doing that.

Daphne: Yeah. I think that's the most common way that happens is trying to couch it in the context of what's important to the company. And I think if you're finding yourself doing that, don't try and do that. But instead, if you have a real customer problem that doesn't fit into your priorities, that's a good opportunity to market that up and socialize it and make sure people are aware because even if it's not a part of the priorities today, this might be a good opportunity for you to raise your hand and say," I've identified a gap we haven't been focused on."

Maggie: Definitely. I have one last thing that I want to talk about with one pagers and a lot of the context that you guys have been sharing with me, listeners, on why you wanted to hear about this tool is I think because it sounds like there's a piece missing in the process that makes it hard for you to do whatever it is that you're trying to do. And I think again, we've laid out what a one pager is for us but I think it's only a tool and it's only as useful as the communication is good between your teams. If that makes sense. If you're not already talking to your teams and collaborating, it's not going to solve the problem and it's not going to be useful. It's a tool to share context amongst people. And you need to be able to have that conversation with your engineers and designers for this to work.

Daphne: Yeah. And that's why it's not proposing a solution. I even sometimes hold my open questions that I have on a one pager for the story time. I won't put them in directly because I don't want to guide the solutions too much. I want to wait and see what other people's questions are before I present my own. I think really making sure that you're using it again as a tool to equip your team with the information that they need to be part of the solution.

Maggie: Yeah, absolutely. That's it. That's the one pager, that's the mystery uncovered again. There are six sections, the story, the background, the goals, the requirements, the time box and all of your concepts and references. I hope this is useful. I hope you guys try it out. Please let me know if you use it and if it helps. Daphne and I need a six star review, definitely. People have been coming on and saying that they found Seeking Wisdom through this podcast and then they leave them a review.

Daphne: Oh no. You need to be pubbing it more, Maggie. Six stars.

Maggie: Six stars for me and Daphne. You can maybe call out G2. I don't know if that gets them reviews. I'll take that too. Thanks guys.

Daphne: Thanks.