Getting Product, Engineering & Design In The Same Room: What Happens After You Write A One Pager

On this episode of Build, Maggie and special guest Alexa Nguyen from the Drift product team talk about what happens after you write a one pager. At Drift, ‘story time’ is the next step in the product development cycle. It’s where product managers, engineers, and designers get together in one room to outline the problem they’re solving and identify any open questions. So the goal of the meeting isn’t about coming up with a solution to the problem – it’s about empathizing with the user and then creating a list of questions you want to answer afterwards. Want to know Maggie and Alexa’s three steps to a successful story time? Listen to the full episode.

You can get Build on Apple PodcastsSoundCloudSpotifyStitcher 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 Alexa on Twitter @maggiecrowley @anguyenrex @HYPERGROWTH_Pod

Subscribe & Tune In

Apple Podcasts Spotify SoundCloud

Full Transcript

Maggie Crowley: Hello, welcome to Build. Today I’m really excited because back in the studio I have Alexa, another PM here at Drift. Today we’re going to talk about the story time.

So, a couple episodes we talked about the one-pager which is how to figure out and gather all the things you need for the problem that you want to solve. Today we’re talking about what happens after the one-pager, which is the story time. So we’re going to talk about what it is, why it matters and how you guys can do it with your teams as well.

So, the story time is what you do, like I said, after you write a one-pager. It’s how you go from outlining the job to be done to actually working on the solution. It’s sort of the first step that you do as a whole team. So you’ve written the one-pager as a PM, you’ve gathered all your requirements, and then you get in a room with your co-workers and it has to be designed, it has to be engineering and the actual people who are going to design and build the product with you. You get together and then you start to outline and clarify the problem that you’re solving and develop open questions.

Alexa: Yeah. So, I think the two key things to remember before you go into the room is the purpose of a story time is not for you guys to develop the solution. It’s for you guys to develop open questions about how you might solve something. So that’s an easy way for you guys to stay focused is remember that you’re not developing and making decisions, you’re just creating a list of questions you want to answer afterwards. It’s also a really important time for you to share the context that you’ve been creating with the rest of your team and help them empathize with the user.

Maggie: Right. So, I think one thing to call out is that story times should be simple. They should be fun, they should be engaging.

Alexa: They should be. But they’re not always.

Maggie: Yeah. We’ll get into the tips and tricks, and what we’ve learned over the course of time and how to make them a little bit more engaging. But, everyone should speak. Again, it’s the entire team that should be in there, and I think we can just get into what it looks like.

Alexa: Yeah. That sounds great.

Maggie: So, the first step before you can even have the meeting, it’s super important that every single person who’s going to be there reads the one-pager. So, A, you have to have a one-pager, and, B, people have to read it. Because what you don’t want is having people come into a meeting sort of unprepared. They don’t know what’s going on, they don’t know what problem you’re solving and then you end up wasting the first half of the meeting just talking about things that people should already know.

Alexa: Right. So make sure the whole team comes prepared. Usually we’ll write the one-pager and post it the day before we schedule a story time. Our team uses Slack really heavily. So, we use a Slack Bot reminder one hour before the meeting and say, “Hey, don’t forget everybody come prepared. Please make sure you read this.”

Then, the three steps once you’re in the room, the meeting room, for story time are one, it’s your job to orient the team. Two, together as a team paint a picture about the customer pain and the job to be done. Then step three is to develop ideas and open questions about how you might solve that pain.

So, I think it’s important to remember as somebody leading the story time you’re not really a dictator, or a leader, you’re there to facilitate the conversation. So, in these three steps I have a list of example questions that you can use to help facilitate the discussion.

So, step one when you’re orienting the team and helping them get focused on the problem we come together and I always start every story time by saying, “What is our goal of this meeting?” Remind everybody that we’re here not to create solutions but to create a list of questions.

Maggie: Yeah, I think it’s really important… Actually we were in a story time yesterday. A new PM member teamist, his first story time. Afterwards we were talking about how we could have done that better. I think the one thing that we didn’t do a great job of was zooming out and starting with why are we doing what we’re doing? Why does this matter? Not only for the specific problem that we’re solving, but in the context of our business.

Maggie: Because, one of the things I like to remember is from the one-pager to story time to all the steps that come after is that they’re all moments where you can decide not to forward. So, you have to remember why you’re doing it and you have to be able to answer the question of should we still do it?

Alexa: Yeah. That’s also a good opportunity for you to share your work with the rest of your team. I’ve worked with a lot of engineers, and designers, before who were highly skeptical. So it’s your job to say, “You know, this is the research that’s been completed. We’ve talked to these customers. Here’s what we’ve been hearing. Here are the milestones that we’ve completed so far, and here’s where we are in our journey together.” Kind of zoom everybody out of what you’re there to do today.

So, I think another important thing to start the story time with is, “Here’s what we’re going to do next after this story time.” So it helps provide constraints around don’t worry about this other idea that we’re going to tackle later. Let’s focus on right now.

Maggie: Yeah, I think the really important to call out. Is that, when you’re starting to bring people in the room who maybe haven’t done this type of thing before, if you’ve never done a story time, you’ll have people who start to think about the full scope of everything you could build, and all the problems you could solve. Then it’s really hard to focus on the one thing that you want to work on. So, yeah, I guess that’s probably a good way to sort of say, “We know that these other things exist but we’re not going to work on them today.”

Alexa: Yeah. Doing it upfront helps prevent any rabbit holing later on in the discussion.

Maggie: Got it.

Alexa: So, that’s step one, orienting the team. Step two, together we paint a picture about the customer pain and what the job to be done is. Some of the worst story times that I’ve led have been ones where I was the one who wrote down the job to be done, all the research about the customer, things we know about them. I think, one, it’s not only because I was the one talking at the team, and sharing that context. But it was also because I didn’t give the rest of the team an opportunity to get comfortable talking out loud and sharing their ideas.

So, step two, painting the job to be done, is really a softball way to get your team to start speaking up. So, I’ll get in front of the room and I’ll say like, “Okay, who’s the user that we’re solving for today? Which persona are we focused on?” Then we’ll go through the Clay Christenson’s what progress are they trying to make? What is their ideal outcome here? What’s preventing them from making that progress? What do they care about socially, emotionally, functionally? Really getting ourselves into the shoes of the user and helping us understand what they want.

Maggie: What happens if someone in the room, or no one speaks?

Alexa: Yeah. I think that’s why every step I have a list of questions is because it’s your job to come prepared with those juicy questions that will help people speak. To be honest, sometimes I’ll try and call people out and say, “Hey, how are you thinking about this?” What’s really helpful is story time doesn’t have to be about your personal opinion. It’s more of do you think this would help the user get to where they’re trying to go? If you try and orient the team around the user it makes it less of a this is my idea, it’s a good or bad idea. It’s more about things that they’ve heard.

Maggie: Yeah. You shouldn’t even be talking about ideas specifically. Because, if the goal of the meeting is to define the problem and develop open questions then you’re talking about the problem you want to solve and not any idea that you have of the solution.

Alexa: Hmm.

Maggie: Right? I think that’s something that we always talk about which is… Especially as PMs I think you’ve done all the work to build that… To write that one-pager, then you probably in the course of doing that have some sense of what you want to build. Or you think you should build. Or some assumptions about that. Especially if you’ve picked a role model. So then I think it’s real easy to go into a story time and say… And to frame the whole discussion in a way that gets the team to say the things you want them to say. To get the solution that you want them to build.

Maggie: I think it’s really important as a PM, or whoever’s facilitating, to not do that and let the team figure it out.

Alexa: Yeah, I think that’s an important clarification, right. It’s not that you shouldn’t be talking about ideas at all during story time. But, as a PM I try and be the last person to share my ideas. Because I want to influence the team as the least amount possible.

Maggie: Right. Because, we’re bringing the problems and it’s their job to figure out the solutions.

Alexa: What I’m always fascinated by is the process it takes to develop a shared language in all of the assumptions that we have. Even through we’re solving the same problem, every single time I go into a story time there’s always some context that I haven’t considered, or some idea that I haven’t considered, or something that’s really important to the user that another person on my team has thought about.

Maggie: Right, which you wouldn’t get if you sort of-

Alexa: Tried to influence.

Maggie: Tried to influence them.

Alexa: Yeah.

Maggie: Yeah.

Alexa: Exactly. So that’s step two. Painting a picture about the customer pain and the job to be done.

A quick tip is I’ll sometimes draw a picture of a user profile on the board. It’s like a silly way to get people comfortable. What’s really nice about Drift is we have a lot of internal customers so we’ll pick some of our favorite sales reps, or we’ll pick some of our favorite people on the marketing team. But, again, reminder that you are a facilitator not a dictator here. So, as much as possible you should be talking the least.

Maggie: Yep.

Alexa: So, step three is for you as a team to develop ideas and then open questions. So, questions that I help use to facilitate this part of the discussion are how might we solve this pain? What do we know that users are doing today that they’re are using to solve this problem? Then, some inversion. Like, what will this look like if it’s successful? What will this look like if it fails? Then, what open questions do we have around how we might approach these solutions? We kind of keep iterating over these questions and solidifying this list of open questions.

Maggie: Right. Then at the end of that you have… Just tactically you’ll have a white board that has usually some part of it which has outlined the person, and the problem that you’re solving for. Then you have this big jumble of open questions.

Alexa: Yeah. So, it’s like three parts. You’ll have the user, and the job to be done. Then it’s a bunch of random ideas and it gets kind of chaotic in the middle. Then on the right it’s your clarified list of open questions that you pulled out of that idea and brainstorm.

Maggie: Right. I think it’s… The really important thing to remember is that it’s not just that you developed this list of open questions, it’s that then you have to go one by one through the questions, decide which ones you’re actually going to answer and add a DRI.

Alexa: Yes. That’s key.

Maggie: Or, directly responsible individual. Because, if you think about it you go through this whole process you leave the meeting and you don’t decide who’s going to answer those questions you’ll never answer them, and you all just build what you assumed you’d build in the first place.

Alexa: Yeah.

Maggie: Which, I’ve definitely seen happen. If we were trying to move really quickly and you do a story time because you’re supposed to, but then everyone just does what they thought they would do.

Alexa: Teeing up Maggie’s next episode.

Maggie: Yeah.

Alexa: It’s also important for you to assign a date. So the way we work backwards from the deadline for each open question being answered is when you’re hoping to kick off that piece of work. So, I’m sure one of your next episodes will be the kick off.

Maggie: Yes.

Alexa: So, yeah. We try and say, “Here’s our goal for kick off.” Then, “Here’s when we need to answer these open questions by.”

Maggie: Yep. I think another thing that I try to remember is that you can come back to story time. So, there’s not a limit on you only get to do it once and when you do it that’s it. I think depending on the complexity of the problem you’re trying to solve you might come back and do it again based on what you learn when you answer those open questions.

Because you might uncover a technical limitation. This has happened to me before. We thought we were going to do something, all of a sudden we uncover some sort of dependency or thing that we just can’t solve. Then we’ll come back and re-story time with that constraint in mind.

Alexa: Yeah. One of my favorite things about story time is sometimes the team will say to me that I’ve made too many assumptions about what the user wants and we need more information from the user. So, sometimes story time ends by saying, “Hey, PM, you haven’t done your job well enough. We don’t have specific examples and we don’t have enough proof.” The definitely happened before.

Maggie: Yeah. I think also I’ve had… I had a story time a couple weeks ago where we decided that we had a pretty good set of assumptions that we were going in with, but we knew we wanted to get more customer research as early as possible. Because we wanted to test some of the big assumptions we were making the solution. So one of the open questions from the story time was someone go talk to these five customers and figure out whether we’re thinking about this the right way.

Alexa: Yeah. Cool. So, quick tip I always try and end story times with a meeting checklist, making sure I’ve hit everything on this list. So, the first Maggie said was make sure all of our questions have DRIs and due dates, which are your action items leaving the meeting to make sure that story time is actionable. Then, making sure we have a DRI responsible for transcribing all their questions and keeping our notes and ideas on the one-pager. So that one-pager, again, is that living document that kind of follows us through the journey of building products.

Then, one of my favorite and most important pieces of the story time is making sure that we have an agreed upon tag line that represents the story and the solution. So it’s kind of a way for the team to create a three or four word sentence that really summarizes the story that we’re trying to solve for. This anchors the team as they’re iterating and building and making their own micro decisions together. They can remember exactly where we’re trying to go, and what we’re trying to solve.

Maggie: Yeah, I think it’s exactly like the leadership principles we have as a company, which are things that we use to guide our decision making and tie break things and focus ourselves. Having a tag line as a team means that every time your making a decision, or every time you’re trying to do something you can just sort of check yourself against that thing that you’re trying to do.

Alexa: Yeah. It helps focus you.

Maggie: Yep. Okay. So, let’s think about the story times that you’ve actually done. What is the most unsuccessful, or worst story time that you ran?

Alexa: I think all of my… All of the first story times I ever tried to run. So, story time is kind of born out of the conflict of us trying to together as a team and figuring out what we were trying to build. We would always end those meetings with people fighting and butting heads about how their solution was right, or somebody else’s solution was right. There was really no structured way for us to get on the same page. So, I think the worst story times are one, making sure you’re not drawing out everyone’s assumptions up front. That’s why we try and do the full team get together and try to say, “This is my assumption about these, or pain. This is my assumption about the progress they’re trying to make.” That’s why it’s so important to do that up front.

Maggie: Yeah. I think the worst ones that I’ve been involved in that were definitely my fault were-

Alexa: It’s always our fault.

Maggie: It’s definitely always our fault.

Not engaging people in the problem well enough and not telling a good enough story. I know that there’s a million Seeking Wisdom and Build episodes about story telling and how important writing is. But, this is one of those moments where you can really tell how important it is because if you do a bad job of explaining why what you’re working on matters and is important and is interesting, the room is just going to be silent. We’ve all been there. There’s just going to be a team of people just looking at you. Sort of thinking about why this meeting is wasting their time.

So, it’s so important to come with that energy, examples, customer quotes. Just anything you can do to get the room sort of excited.

Alexa: Yeah. And I think what’s key about that is making sure you tell the story well in the one-pager. Because, I’ve seen story times fail where the PM will spend the first 15 minutes repeating everything that’s in the one-pager. Then you’ve wasted half of the meeting. Then the team is just kind of staring at you waiting for you to tell them exactly what to do.

Maggie: Yep. Absolutely. So, what was the best one that you’ve done?

Alexa: I think the best, or my favorite one, was when we were painting the job to be done we realized that to really understand where the user was coming from we needed to understand where we fit into their day-to-day process. So we drew out a user journey of this is what the sales rep does when they get into work. Here’s when they open Drift. Here’s when they might be leaving their desks, and here is where we might need to fit into that. It really helped everybody get excited about the little nuances of making sure we capture users attention.

Too often when we’re designing solutions we assume the best and assume that they care about using our product. They’re engaged, they already understand what it’s going to do for them. So, that was a really powerful moment.

Maggie: Yeah. I think making sure that your job to be done is well defined and scoped at the beginning leads to much better story times.

Alexa: Yeah. Always come prepared with specific examples. Specific things that customers you can name and bring up a picture of have tried to do.

Maggie: Yeah. What about, you mentioned taglines. What’s the best tagline that you guys have had?

Alexa: So, we were designing something for our ABM product. So ABM is account based marketing. It’s basically when your marketing and your sales team work together to create a targeted approach to try and bring an account into the business. So, marketing will send them swag, or try and create content to get their attention. So, our tag like was, “When you’re a target account you’re family.” It’s basically a plan like the Olive Garden tagline.

Alexa: But, so what we were trying to create was this fast lane experience where it made them feel welcome, made them feel like we already knew who they were. So, yeah. Our team likes pasta, so.

Maggie: Yeah. I think wherever you can, even if you don’t have a neat tagline based on Olive Garden, at least naming your feature. Or giving the project that you’re working on some sort of name the not only relevant to the engineering team and the design team, but also the full company is so helpful. Because then when people… It helps you get them excited, it helps you sort of communicate what you’re working on. I think it’s really easy… It’s hard to explain ABM maybe to someone who doesn’t have that matter to them in their day-to-day. But it’s easy to say when you’re a target account you’re family.

Alexa: Yeah. I think, I mean, it doesn’t… The tagline doesn’t always have to perfectly describe the problem. It can also describe how you want to solve the problem and plant a flag for the team. So, another example for a product we were building is we wanted to make it as wizzy wig as possible. Make it is that whatever the user sees is what they got as their output. So, that was kind of our hashtag, or our tagline for that story time. Which made it really easy because there was a lot of complexity in how we wanted to solve it, but that helped share the why and the where we’re going with the team. Then it was easy for us to solve from there.

Maggie: Cool. I think the only other thing that I would mention about story times and tips and tricks is a phrase that Trevor on our team always say, which is “Pencils not pixels.” So, again, I think we’ve all dealt with the sterotypical engineering team who might want to go very, very deep into some details. It’s really important to say, “This is our opportunity to think at the pencils not pixels level. We’re just sort of sketching out problems. We’re thinking about options. This is when everyone on the team gets to be involved.”

So, I think another point when I was on a team where we didn’t do story times, which is we would get to the point where someone’s building something and maybe it didn’t turn out the way we wanted. Then the person building it would say, “Well, this is what you asked for.”

Alexa: Yeah.

Maggie: Right, and they don’t have any agency over the thing that they’re building. So, they don’t really care about it. This allows you as a team to get everyone excited before you’ve done anything. So that by the time you’re actually building the thing everyone’s already bought into the problem. They’re bought into the solution. They’ve been involved in it from day one. So, it’s a team thing not just a, “My PM told me to build this thing.”

Alexa: Yeah. Another way to prevent the rabbit holing, like you mentioned, is to ask the question how might we develop this into a question that we can answer later on? And try and bring everybody back.
Maggie: Smart. All right. So, everyone listening we want you to do a story time. It can be hard at first, please try it out.

Alexa: It is hard at first.

Maggie: Yeah. They’re always hard.

Alexa: Tweet at us, we’ll try and share as much tips and tricks as we can.

Maggie: Yeah. So please do a story time. Tell us all about it. Leave us a review. I think we need some shout outs for Alexa in the reviews. I don’t think you’ve had any yet.

Alexa: Nope.

Maggie: So, six stars for Alexa. Thank you for listening. And that’s it.

Alexa: Thank you.

Related Stories

P.S. Join 20,000 of your peers. Subscribe to the newsletter for hypergrowth.

Every Sunday evening we'll send you a roundup of the best content and events from Drift and around the web. Make sure you're ready for the week! Subscribe now.

Subscribe Here