On this episode of Build, Maggie and special guest Daphne Funston from the Drift product team tackle the number one question from listeners: what’s a one pager and how can I use it to build better products? Maggie and Daphne talk about how one pagers are deceptively simple, yet when done well, they can be a powerful tool for PMs to frame, scope, and communicate a customer problem to engineering and leadership teams. Tune into learn about the six sections that make up a one pager and how Maggie and Daphne use the one pager in their roles at Drift.
You can get Build on Apple Podcasts, SoundCloud, Spotify, Stitcher or wherever you get your podcasts. Or listen to the full audio version below?
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends! You can connect with Maggie and Daphne on Twitter @maggiecrowley and @daphnegrayson.
Subscribe & Tune In
Full Transcript
Maggie Crowley: 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 send it, which is, “What is the one-pager?”
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 Funston: Hey, Maggie.
Maggie: Hey. Okay. So, we, unlike DGI, have so many notes. Because I wanted to give this the justice that it deserves as I think 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 our projects. It’s really an artifact that we use as a team to scope and define a problem.
Maggie: So, like 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. So, unlike many a spec, which something I’ve used in the past or a product requirements doc, or you had a one-pager also at Buzz Feed?
Daphne: Mm-hmm (affirmative).
Maggie: This is really specific to the problem and all the context that you have around it. So, 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. 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. It’s not something that you can just drop off with your engineering team and expect them to build.
Daphne: Right.
Maggie: So, 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. 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. I think that also another important point is that we use them to get the teams excited and get them sort of … Help them build empathy, I think, with the customer. Then also as living documents that sort of move through the project with us. They’re there at the beginning when we define the problem, then we add to them as we go. So they’re sort of a record of the decisions that we’ve made along the way.
Daphne: Yeah, that’s the dream.
Maggie: Yeah.
Okay. So, there are six sections in a one-pager. It’s deceptively simple. 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. So we’re going to go into each of those quickly in detail.
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. So, the story. This, I know we’ve talked about copywriting and storytelling a million times on this show. 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 customers is, and what it means to them.
Daphne: Yeah. 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. So, 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. 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. 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. 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 it is.
Maggie: I 100% agree. 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. So, second part background and context. So this is really where you describe the insight about your customers, your marketer, your business that lead to the job to be done. So 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. 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: 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: Definitely. I think this is like if the first step in the story is as a marketer I want to do X so that I can Y. 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. 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 in my last job at … Or, two jobs again 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. So 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 feature.
Daphne: Right. This goes in a little bit to the next part. But, the timeline on which that … I mean, you could have a whole podcast about it, to goals.
Maggie: Yeah, definitely.
Daphne: Serious.
Maggie: Yeah. Maybe we’ll do one.
So you have to have goals. Step four, requirements and constraints. So 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 happen? Or, I think you mentioned risks and dependencies that you need.
Daphne: Yeah, it’s a good way to scope the problems. So, this can’t impact X other product, or can you do this within the scope of kind of these parameters depending on what your 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. 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. So, 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. As we were chatting before this, 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: 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. So, I think you can use your judgment on whether or not it’s required.
Maggie: 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 would … I do occasionally come in and put in if we … 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 in and put details and milestones later on.
Daphne: 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. That’s what we call concepts and references. This is where we put every single piece of relevant information that you have. I often just have a grab back of things at the end of the one-pager and that’s stuff like role models. So, 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 would put tear downs.
So, have you done an analysis of someone else’s tool, or feature, or way they’ve solved it and you’ve learned something. So put it there. This is where I put all the customer context that I have. So all the quotes, definitely just pictures of Slack messages and pictures of emails and whatever. Just any details that we have of things.
Daphne: I think I use it a lot for all the research that I’ve done that lead 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’ve 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. 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: Yep. Okay, so 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.
Daphne: Yep.
Maggie: So, 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. So, vision one-pagers would be, okay we have this bigger problem that we want to solve maybe over the course of the quarter. This is the full scope of that. Whereas, the individual one-pager would be the first step in solving that problem.
Daphne: 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.
So, 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. Something that another person told us here is that write for your readers and not for yourself. So, 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: 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. So that’s a good exercise is what questions do I think are going to come up, and are they covered? Have I addressed them here?
Maggie: Mm-hmm (affirmative). I think another thing that our team member called out was read your one-pager from the perspective of someone who has no context, or is not technical. Then from the perspective of someone who is technical. So, especially if you’re working on something that is deeply 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. 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. 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 strict job to be done framework. I think it’s pretty easy to say something like, you know, 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 easier 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. So I think spending the time to write that story in a way that’s compelling is worth every second.
Daphne: To your point, nuanced. You don’t just want to build better bots, what is the goal that you’re trying to achieve? 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.
Okay. 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 the customer.
Daphne: Right. So, direct quotes for sure. Often for, 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, I mean 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: 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 it’s going on it’s all there.
Daphne: If you’re worried about these becoming really long and unwieldy use them to link out to those other documents. If you have … You know, we have a big other design document breaking down all the design needs we have for a particular project. It’s just linked to the one-pager, which is really helpful.
Maggie: I’ve definitely used, when I’ve worked on things I’ve gone back and searched the Wiki and found old one-pagers, kind of 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: Totally. Okay. So, I want to talk about the best and worst one-pagers. We were talking about signals that you can use to know whether you’re on the right track. 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. So that’s definitely a big signal for me.
Maggie: 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. That’s 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: 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. 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. So, I have one last thing that I want to talk about with one-pagers. 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. 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.
So, 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: 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. So I want to wait and see what other people’s questions are before I present my own. So 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. So, 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.
Maggie: 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. No, you need to be pubbing it more, Maggie.
Maggie: Yeah, definitely.
Daphne: Six stars.
Maggie: Six stars for me and Daphne. You can many call out G2, I don’t know if that gets them reviews. I’ll take that too.
Daphne: Yeah.
Maggie: Thanks guys.
Daphne: Thanks.
