What is a Directly Responsible Individual? (Ben Grynol & Scott Klein)

Sometimes projects start strong and then mysteriously fizzle out. Often, it’s due to a lack of clean ownership, with no one employee assigned as the overarching point person. At Levels, we’re combating this trend by assigning DRIs, or Directly Responsible Individuals. In this episode, Levels’ Head of Growth, Ben Grynol, sits down with Head of Product, Scott Klein. They discuss what the DRI process looks like, our approach to the process here at Levels, and why it’s crucial to implement in a remote and asynchronous working environment.

3:06 – Ensuring projects get shipped

The benefit of assigning a Directly Responsible Individual is that it places ownership in someone’s hands.

As the team was growing, we were finding that there was a lot of energy and excitement around getting started on projects and I think people thought, all right, this person, sort of taking the lead, they’ve demonstrated their doing some research, doing some coding, doing whatever. Then weeks or months would go by and somebody would pop up and say, “Hey, what happened to that thing? I thought Schindler was working on it, or I thought David was working on it, or I thought Scott was working on it.” Then it would sort of come out, “Oh yeah, well, we ran into some issues and we couldn’t get them resolved or it just got slotted out because of higher priority stuff.” The main thrust of the directly responsible individual is to have somebody whose name is on the ledger to say, “You are the singular person responsible for making sure this gets shipped.” Shipping something can happen in one of many ways, but the point is that you’re the person on the line.

5:58 – DRIs can delegate

Just because you’re assigned as a DRI doesn’t means you’re doing all the work yourself. In fact, a large component of being a DRI is being a good project manager and delegater.

It’s important to call out that, even if you are acting as a directly responsible individual on a project, you’re likely to not actually be doing a lot of the work. I think that’s where this diffusion gets, especially dangerous, is you can do maybe the product management side of the work upfront to figure out, what are we going to build? How are we going to build it? How do we scope it, phase it? Let’s put some boundaries around it. Then you sort of can throw it over the wall to engineering and say, “Hey, all right, here it is. We’ve got design knocked out. Let’s go ahead and build it.” It’s easy at that point to, I think, just throw your hands up and say, “Oh well, it’s engineering’s responsibility now.” We directly wanted to avoid that bit of handing. I think it’s very explicit in the way that we have written the initial iterations of the directly responsible individual manifesto, if you will, to say, “Hey, at no point is anybody else actually on the line or responsible for getting this shipped.” You might not be doing the work and you might not be making all the decisions even, but you are responsible.

9:53 – Project management is a skill

The Levels team quickly learned that everyone has different backgrounds and styles, so the DRI process needs to have clear guardrails with wiggle room built in, too.

Some people were coming in with a mix of being really good at project management and very light on product management. It’s oftentimes the reverse. Somebody would come in and they’ve got really good customer sense, but they haven’t sort of orchestrated or been at the helm of understanding how to sort of drive the cadence, do enough check-ins, how do I work with my functional leaders? Is it okay for me to check in with engineering once a day, twice a day, once a week? It was interesting on the backside of seeing, doing the debriefs. David actually did a lot of really good debriefs with the initial round of responsible individuals. They all had different sort of vectors that they had struggled with or they wanted more clarity on. So, it’s interesting. I think that we are in the process now of finding, how do we put together a process that has enough guardrails to make it actionable, to make it understandable so that somebody that wants to be a DRI could come in and really succeed in that? But also gives some room for there to be some art and some jazz and for people to put their flair on it.

13:08 – How much power should DRIs have?

The next big question was determining the extent of decision-making powers that DRIs had, in order to keep things moving but also keep quality high.

One of the things that we ran into and that we’re sort of trying to define, like how do we bring in functional leaders and stakeholders, I guess if you could call them, in these specific areas to help protect and future guard against the roadmap as a whole or against quality as a whole? The worst case, if we sort of gave DRIs infinite power to just make all the calls that they want, we really open ourselves up to this roadmap capture across all of the DRIs, because if they get to decide exactly the quality bar that they want to hit on their own, or if a tension comes up between design and development or product, that they just get to make the call moving forward, we were worried that we were going to run into a case where overall the product was going to slow down.

15:34 – When projects snowball

Occasionally projects grow beyond the means and resources of one DRI.

One of the, I guess the edge cases where it does start to get fuzzy, and I think we’re too small to hit this right now, but I think, in the future, there’s definitely a sense that we may run some projects that cut across such wide swaths of the company. Let’s say we were going to do a pricing realign in five years. That is going to hit so many separate departments that maybe having an alternative, like second or third DRI amongst the really, really, really important contingencies probably makes sense. I don’t know what that would look like for us and I think we’ve got a lot of room to run.

18:45 – Budget extra time for projects

If you implement a DRI system, be prepared for things to actually take longer to ship, since your stakeholders will have increased management responsibilities.

In our case, taking a lot of developers and putting them on projects, we just noticed there was two things. One is our speed just slowed down tremendously. I think it was very apparent to us, three to four weeks in like, oh man, this isn’t something that we need to take lightly. It’s not like we can just assign a DRI and have it be a two to three hour a week job for them. It’s actually fairly substantial, especially for the projects that we’re hitting the member base. I think there’s a sense of custodianship there that people took very seriously and they wanted to make sure that they got right, especially the ones that didn’t have any product experience before. I think part of understanding this process and doing it well into the future is freeing up the DRIs from their other responsibilities so that they can focus on and make sure that they have the bandwidth to actually execute on this.

31:37 – When to break one project into multiple parts

Sometimes, the answer is that a project is too big for one DRI and needs to be broken into different pieces.

When I think about some of the newer DRIs coming into the process, these are the sorts of things that they might not know. We always have the best intentions when we come into a project. There’s a seed, there’s a figment of an idea around something. Let’s go explore and let’s see what we can uncover. Let’s talk to a bunch of members, we’ll talk to each other. We’ll use the app and have the CGM running. We always go in with the best intention of thinking, all right, we’ve already got a loosely bounded box that should be fine. But once you peek under the covers, you just realize, man, there’s a wealth of stuff for us to do here. There’s so much that we can do that this bounding box of what we’re considering a project that a single DRI is going to be across, it no longer makes sense at all. You are putting pieces of different puzzles together and hoping that it’s going to fit, and they don’t fit, and that’s frustrating. It’s a good indicator when your puzzle pieces are from mixed puzzles that maybe you’re dealing with two separate projects and not a single one.

45:17 – DRIs don’t need to know everything

While DRIs have increased responsibility, they should also feel that they are backed up and supported by the larger organization.

People are giving us their really personal health information, we have glucose data and we now have blood results for them. All of these small things add up to a large amount of trust that’s going to translate to engagement in the product, that’s going to translate into referring and friends and family members. It’s not necessarily incumbent on the DRI to really understand and know that as much as our head of design might or our head of PM might. As we think about the things that we need to bake into the DRI process, part of those is just giving them permission to lean on other people for those things to make those calls and just being able to trust that those are there. It’s to give them the space to not have to worry about missing something like that, so that they can focus more on the execution and making sure that the project is able to move forward.

48:07 – Let DRIs shine

One thing Levels has done is allow DRIs to speak about their project status and success in a company-wide capacity.

One of the things that I love that we do is, every Friday, DRIs with substantial updates get to get up in front of the whole company and share their updates. I really hope we don’t get rid of this for quite a while. One of the things that I find about it is that it’s very accessible to other people that are DRIs right now or that may want to be in the future. It’s really cool to see somebody come in, who is working in a domain that they’ve never worked before, with people that they’ve likely never worked before with either, to say, “Hey, we had this really cool moment where we got to engage the members and here’s what we learned.” Or, “I watched our engineering team really work into the night to ship something.”

Scott Klein (00:04):

The fundamental point of having a DRI is just not having the opposite of that, which is just a diffusion of ownership, like you want a singular person to be able to be on the hook, and for people to lean on and really like in a positive framing to know, hey, Ben’s got this. This isn’t something that I need to worry about. I might have opinions about it, but at the end of the day, there’s no expectation that if you, maybe, don’t voice an opinion, that you aren’t showing up in a way, or if you don’t contribute to your part. You’ve got a singular person that is responsible for getting stuff sourced, getting stuff shipped, and defined in a way.

Ben Grynol (00:45):

Here at Levels, we’re building tech that helps people to understand their metabolic health, and this is your front row seat to everything we do. This is a whole new level.

Ben Grynol (01:08):

Hey listeners, Ben Grynol here, Lead Growth with the team at Levels. When taking on projects, it’s always good to have a point person, somebody who can take on a project from start to finish. We’ve got this thing at Levels called the DRI, the directly responsible individual. What this person is, is somebody who basically is responsible for taking on a project from start to finish. For Scott Klein, head of product at Levels, he’s been thinking a lot about this lately, what exactly is a DRI? What’s the role of a directly responsible individual? What’s their scope of work and how should they work within the team? What type of resourcing can they do? What resources can we give them in order to learn, in order to be the most impactful team player that they can be?

Ben Grynol (01:51):

We sat down and we talked all about this idea of being a DRI, what it actually means, and we explored some of the things where it’s beneficial, some of the opportunities where we’ve learned things and opportunities to get it better. What can we do and how can you take this forward? It was a really interesting conversation to riff on this concept of a DRI and to think about how we might use it moving forward. Here’s where we kick things off.

Ben Grynol (02:20):

We’ve got this thing that we used call the RI, the responsible individual, and now it’s called the DRI, which is directly responsible individual. That’s sort of the point is that you have come in as head of product now and started to really drive things forward with this DRI process. What would be good to dig into is just like, what exactly is this DRI? Like, where did it come from and why do we use it?

Scott Klein (02:48):

Well, this concept isn’t new. I think, in part of our research, we found out that a ton of companies operate this way. We just actually just had a new person start from Apple this week and he was RI or what they call a DRI, a directly responsible individual at Apple. So, not a new concept, but the history of it was that, I think, as the team was growing, we were finding that there was a lot of energy and excitement around getting started on projects and I think people thought, all right, this person, sort of taking the lead, they’ve demonstrated their doing some research, doing some coding, doing whatever.

Scott Klein (03:22):

Then weeks or months would go by and somebody would pop up and say, “Hey, what happened to that thing? I thought Schindler was working on it, or I thought David was working on it, or I thought Scott was working on it.” Then it would sort of come out, “Oh yeah, well, we ran into some issues and we couldn’t get them resolved or it just got slotted out because of higher priority stuff.” The main thrust of the directly responsible individual is to have somebody whose name is on the ledger to say, “You are the singular person responsible for making sure this gets shipped.” Shipping something can happen in one of many ways, but the point is that you’re the person on the line.

Scott Klein (03:59):

There’s no diffusion of responsibility. I think in a remote and an async context, these things are especially important because we don’t have our normal social cues that we do coming into an office. You might walk down the hall and see somebody and go, “Oh, I meant to get them that by Friday.” Or, “Oh yeah, they asked me that question and I never really gave them a solid answer, like a go or a no go on a project, so maybe I should go back and get to them.” I think we found, because we have such long uninterrupted work hours, that things were just falling through the cracks and we weren’t noticing for weeks or months at a time.

Scott Klein (04:33):

That’s the thrust of what was going on with the directly responsible individual thoughts and why we made them a here.

Ben Grynol (04:41):

Yeah. The point you make about remote and async is so important because I think what happens is, so let’s just use an in-person work environment. It’s pretty easy for everybody to be in an all-hands. There’s literally a group of people standing around and everybody sort of nods their head at the same time and understands like, yep, this project is moving forward or it’s to retired, and that is the cue. But the impetus for needing somebody to be responsible for making decisions and closing projects out if they’re not moving forward and letting the team know, or updating the team if they are moving forward and saying, “Hey, here’s the time we’re allocating to this thing and it’s going to be two weeks or two months. It doesn’t matter the amount of time, here are the next steps.”

Ben Grynol (05:22):

But always having that one point person, it’s like, now everyone knows who to go to for, like David’s working on membership model, and that’s just the easy … That’s the line. If anyone has any question, David’s the person to go to. Then same thing with, like Tom is a person to go to for anything related to marketplace. So, it becomes a lot easier and more transparent across the entire company when there isn’t ambiguity around, well, I think Scott’s overseeing that, but maybe it was Ben, maybe it’s David, I’m not really sure. And then that’s where it gets really muddy in a remote environment.

Scott Klein (05:58):

Yeah. It’s important to call out that, even if you are acting as a directly responsible individual on a project, you’re likely to not actually be doing a lot of the work. I think that’s where this diffusion gets, especially dangerous, is you can do maybe the product management side of the work upfront to figure out, what are we going to build? How are we going to build it? How do we scope it, phase it? Let’s put some boundaries around it. Then you sort of can throw it over the wall to engineering and say, “Hey, all right, here it is. We’ve got design knocked out. Let’s go ahead and build it.”

Scott Klein (06:27):

It’s easy at that point to, I think, just throw your hands up and say, “Oh well, it’s engineering’s responsibility now.” We directly wanted to avoid that bit of handing. I think it’s very explicit in the way that we have written the initial iterations of the directly responsible individual manifesto, if you will, to say, “Hey, at no point is anybody else actually on the line or responsible for getting this shipped.” You might not be doing the work and you might not be making all the decisions even, but you are responsible for the decisions that get made and you’re responsible for seeing through it that something gets shipped.

Ben Grynol (07:01):

Yeah. It lends itself to product, right? That was one of the considerations going into it where we were like, okay, well, this is for, let’s say shipping new product features. Actually, there’s something we’ll get into as far as what ended up happening when we first kicked this off, because it was pretty funny. Everyone sort of put up their hand to be an RI, when we called it an RI, but it lends itself to product where having somebody that is basically a PM, a product manager or a product owner in a larger product organization or a product function within a company. That’s sort of the way to think about it.

Ben Grynol (07:35):

But we’ve extrapolated this model across the company. So, we find that even in ops or in community, like everything Jesse and Braden have been doing for community initiatives, we still run point as far as, hey, Jesse, you are the DRI for this community project. It still has the same heuristic where there’s stakeholder consultation, if you want to call it that, there is team updates and engagement. They’re all the things that are required to actually create that transparency.

Ben Grynol (08:03):

Back to the point of what happened with product, as we thought initially, we were like, okay, well, is it possible to take people who don’t have prior product experience and turn them into like mini PMs? We thought, sure, you can do that. You don’t need to know a ton about engineering or design or product because you just consult those stakeholders. What ended up happening, like this was sort of shortsighted on our part, and it’s funny to say now, is we had so many people put up their hands to be DRIs to ship features that all of a sudden we were like, “Oh, wait. We don’t have enough engineering resources to actually build all this stuff.”

Ben Grynol (08:37):

Then I think that’s when you backed it off, and you were like, “Okay, wait, let’s revisit this so that it’s actually something that we can achieve.” That’s when I think you retired, the first thing was all the work we were doing on social, which was pretty cool.

Scott Klein (08:50):

Yes. A couple things there that we can pick apart. I think how startups or even bigger companies usually handle this is to have product manager leading a lot of these things, which is to say they’re sort of the DRIs in their respective companies. But one thing that’s very important to name is that product managers oftentimes double as doing the product work, which is to say they interface with the customer, they are working with their engineering and their design counterparts to figure out, how are we going to solve this problem? Where do we draw the line on stuff?

Scott Klein (09:21):

But they’re also acting as project managers in a way to make sure that things are resourced properly, people get unstuck if they have any blocking stuff. When we come to some disagreements that need to escalate or we need to bring some peers in to help resolve, they’re usually the ones that are doing the project managing. It was interesting coming into the responsible individual thing that we laid out, because yeah, a ton of people were super excited, raised their hand, and we were happy to just say, “All right, let’s give it a shot. And we were going to kind of, hey, let’s, almost trial by fire, let’s see where we’re going to run into issues here.

Scott Klein (09:53):

It was interesting because some people were coming in with a mix of being really good at project management and very light on product management. It’s oftentimes the reverse. Somebody would come in and they’ve got really good customer sense, but they haven’t sort of orchestrated or been at the helm of understanding how to sort of drive the cadence, do enough check-ins, how do I work with my functional leaders? Is it okay for me to check in with engineering once a day, twice a day, once a week?

Scott Klein (10:20):

It was interesting on the backside of seeing, doing the debriefs. David actually did a lot of really good debriefs with the initial round of responsible individuals. They all had different sort of vectors that they had struggled with or they wanted more clarity on. So, it’s interesting. I think that we are in the process now of finding, how do we put together a process that has enough guardrails to make it actionable, to make it understandable so that somebody that wants to be a DRI could come in and really succeed in that? But also gives some room for there to be some art and some jazz and for people to put their flair on it.

Scott Klein (10:54):

I think what we wanted to avoid is people feeling like they’re just like these robotic automata, just executing on, to the letter, a 400 page document about how to be a DRI. So, yeah, I think there’s going to be some push-pull there in the future, for sure.

Ben Grynol (11:08):

Yeah. That’s the thing with product roles or like, especially in a larger organization is … The heuristic that people use is, if you want to be a mini CEO, that’s basically what a PM is, right?

Scott Klein (11:20):

Yeah.

Ben Grynol (11:21):

You’re a CEO of whatever feature or project or part of a product that you’re shipping because you’re coordinating with all these different stakeholders, you’re scoping out what needs to be built. You’re helping to make decisions and guide things. And essentially, being a great PM is all about trade-offs, where it’s like, every stakeholder’s going to have different investment, even though everyone’s working together, it’s just, everyone will have a different lens on what the most important part of shipping that feature is, using that as an example.

Ben Grynol (11:53):

Then you’re making decisions to say like, “Yeah, we could take end number of hours to design this feature, but I don’t know if it’s going to ship quick enough to get the feedback that we need.” And then UX team is going, “Yeah, we really just want to ship this and start getting some conversations going.” Engineering’s going, “Don’t throw a hole by bunch of loosely scope things at us. Give us enough constraints so that we can start building some rails here.” That’s sort of what a great PM does and that’s analogous to what we’re doing with the DRI.

Scott Klein (12:25):

There’s something embedded in what you said that we discovered early on, which is every responsible individual that got kicked off really wanted their project to succeed and they wanted it to be great. They wanted it to be something that they were proud of, that they could ship, they could ship the best version of. One of the edges that I think is worth calling out is that, for folks that are normally outside of the normal, I say normal in heavy air quotes, development design and product flow, I think there’s a bit of unknown, or a bit of consternation around, well, how do we draw the line on quality here? How far are we going to go to make sure that this is good for our members? Because from the DRI’s perspective, they want it to be the best that they can.

Scott Klein (13:08):

But one of the things that we ran into and that we’re sort of trying to define, like how do we bring in functional leaders and stakeholders, I guess if you could call them, in these specific areas to help protect and future guard against the roadmap as a whole or against quality as a whole? The worst case, if we sort of gave DRIs infinite power to just make all the calls that they want, we really open ourselves up to this roadmap capture across all of the DRIs, because if they get to decide exactly the quality bar that they want to hit on their own, or if a tension comes up between design and development or product, that they just get to make the call moving forward, we were worried that we were going to run into a case where overall the product was going to slow down.

Scott Klein (13:50):

We were going to have a really nice singular features launching, but that the overall roadmap and the overall because custodianship of the quality bar and the trade-offs that we were making, I think was going to get lost a little bit. Yeah, definitely an interesting piece to focus on around, how do we include other people without them assuming the responsibility of a DRI, but also being able to safeguard and protect against their specific functional area moving forward in concert with the other areas that they have sort of natural attention with.

Ben Grynol (14:19):

Something I’ve been thinking about is, is there a case where a DRI doesn’t work, like any company? Let’s take things to the extreme. You and I have a welding shop together, like something that’s way outside the boundaries of tech, we just have a great welding shop, is there a reason why we couldn’t establish a DRI? You are the DRI of whatever project it is. In my mind, the reason I ask is like, I was trying to challenge the thought process to be like, is this only applicable to tech? Subjectively, I don’t think it is. I think it applies to any business.

Scott Klein (14:55):

Yeah. I tend to share your view. I mean, the fundamental point of having a DRI is just not having the opposite of that, which is just a diffusion of ownership. You want a singular person to be able to be on the hook and for people to lean on, and really, in a positive framing, to know, hey, Ben’s got this. This isn’t something that I need to worry about. I might have opinions about it, but at the end of the day, there’s no expectation that if you, maybe don’t voice an opinion, that you aren’t showing up in a way, or if you don’t contribute to your part.

Scott Klein (15:27):

You’ve got a singular person that is responsible for getting so of sourced, getting stuff, shipped and defined in a way. One of the, I guess the edge cases where it does start to get fuzzy, and I think we’re too small to hit this right now, but I think, in the future, there’s definitely a sense that we may run some projects that cut across such wide swaths of the company. Let’s say we were going to do a pricing realign in five years. That is going to hit so many separate departments that maybe having an alternative, like second or third DRI amongst the really, really, really important contingencies probably makes sense.

Scott Klein (16:06):

I don’t know what that would look like for us and I think we’ve got a lot of room to run. I think for … Just to state it, the default for us should be to always have a single person across it. Then, if we do truly hit something that’s cross-cutting across that many pieces of the company, then maybe we can experiment with a structure where we’ve got two or three people running it and really advocating and understanding that, hey, there’s just, at some point, a singular person who’s going to max out on their ability to keep track of the different constituencies and the trade-offs and having those people to be able to directly talk to each other and be jointly responsible, might make sense at that large of a scale.

Ben Grynol (16:41):

Yeah. If you have a project that you’re a DRI on, depending on the scope of the project, it can be all of your bandwidth, right? The only thing that a person can focus on, because let’s assume it’s a very big project, as you alluded to, one that spans across the company. It’s not fast to ship because there’s so many pieces involved in actually getting it over the line. That’s one scenario. Then another scenario is somebody could have like five DRI projects. That’s still a lot to oversee because I think it’s also, given our phase right now, people who are DRIs are also independent contributors where … Or individual. Sorry, IC.

Ben Grynol (17:22):

In my mind, I was thinking side note, independent contractors, because every time I refer to IC, it’s independent contractor, thinking about on-demand food delivery marketplace. So, in contributors, ICs, people who are the directly responsible individuals are also doing a lot of the work in addition to still working, like collaborating across the team. So, it gets a little bit harder because bandwidth gets taken up, but it is possible, I think, to oversee multiple projects. It’s just, it gets a lot harder given our size and scale right now.

Scott Klein (17:55):

Yeah. We definitely experienced that. One of the things that I really appreciate about working here is that people are working on that growth edge personally at work, whatever you want to call it. We just had a wealth of folks raise their hand to say, “Hey, I’m here. Put me in coach, I’m ready to try this.” It was just sort of a V zero, pretty decently thought out process. But we didn’t know what we were going to run into in terms of friction or things that were unclear. So, yeah, we had, I think the vast majority of the development team in a way take on one or more projects in sort of varying sizes. Then, yeah, it was just a good reminder that there is a big role for people that are going to be doing product and project work at a company.

Scott Klein (18:42):

It doesn’t matter who’s actually doing that work, but in our case, taking a lot of developers and putting them on projects, we just noticed there was two things. One is our speed just slowed down tremendously. I think it was very apparent to us, three to four weeks in like, oh man, this isn’t something that we need to take lightly. It’s not like we can just assign a DRI and have it be a two to three hour a week job for them. It’s actually fairly substantial, especially for the projects that we’re hitting the member base. I think there’s a sense of custodianship there that people took very seriously and they wanted to make sure that they got right, especially the ones that didn’t have any product experience before.

Scott Klein (19:19):

I think part of understanding this process and doing it well into the future is freeing up the DRIs from their other responsibilities so that they can focus on and make sure that they have the bandwidth to actually execute on this. I don’t know why it wasn’t something that we didn’t foresee, but it was something that we definitely felt and I think we were able to make a couple small changes to get things back to normal, just in terms of our development shipping pace and make sure that we’re just aware of it going forward.

Scott Klein (19:46):

That it’s this thing that we need to allocate time to because people want to spend time on it. They really want to do a good job at this. It’s a new process for them. They’ve taken a little bit more time.

Ben Grynol (19:55):

One of the things that we have started to taking into account more is this idea of project debt too, which is so important, right? It’s like, let’s define two types of projects. So, there’s like a project that has multiple iterations, so you ship the first version and then you get some feedback and then you ship it again and ship it again and keep experimenting. Then there’s another one, we’ll call them contained experiments, where a project has some goal posts and there’s maybe not another iteration, but it’s still sort of floating around.

Ben Grynol (20:27):

Like you could do another version of it, but you’re not really sure. I think that’s where the DRI comes in too, to say like, “Hey, we’re not going to do more of this. We’re not going to do anything more to iterate on this one project or to update a feature because we need to open the doors for more experiments to test completely unrelated things.” It’s a hard decision to make, but it really just comes down to opportunity costs where it’s like, if we keep going down this, we’re not going to learn much more about this.

Ben Grynol (20:58):

Let’s say there are diminishing returns to like updating this one feature, but building out some entirely new feature might unlock something that we don’t even know about yet. Because it’s like, we don’t know what we don’t know about that one thing.

Scott Klein (21:10):

As you were talking, the word that really came to mind to me around project debt was just around clarity. I think that many times companies, and I’m very guilty of this, we can fall into the trap of letting things linger. It’s not that it’s taking up our time per se, but it’s taking up some mental resources because there’s still this open thread in a way. We launched the first version of nutrition, got some really good feedback. At that point, you’re sort of at a landing, you’re at a juncture point.

Scott Klein (21:41):

What do we do with this now? What do we do with these learnings? I think you’re correct in your assumption that it’s tough, from a human animal standpoint, to just close a door to say, “Hey, we’re done with this. We’re actually going to shutter it.” Even though people worked on it, we worked hard, we got some learnings, but there’s an attachment to the things that we build. We’re used to co-creating and being attached.

Scott Klein (22:01):

Ikea furniture is some of the highest rated ownership furniture in a way. I don’t think there’s a mistake there. I think it’s just that the work that you put into it, you’re necessarily very attached to it. It’s this baby that you’ve built. But you’re right, there’s sort of a period, I think when you decide, hey, this experiment didn’t work out or we’re just going to put this project on ice. We might even go ahead and remove it completely. There’s that period of mourning that you go through, but then it’s freeing in a way.

Scott Klein (22:27):

The sadness sort of gives away to possibility and newer experimentation, and just knowing that, hey, that was a phase that we went through something, or that we built something, it didn’t quite work out. But now, to have it actually close, means that we can focus and really turn our emotional attention elsewhere.

Ben Grynol (22:43):

Yeah. You hit on the Dan Ariely Ikea effect and behavior and the economics. When you build it, you overvalue it, right? You tend to think it has a higher sense of value than it does, and that’s natural. That’s just the way that we hold these thoughts cognitively in our minds about what something means to us. What’s interesting though, is like, if you’re building Lego or DUPLO, we both have kids, they’re building DUPLO, they can’t build something new if they keep trying to build on top of the existing structure.

Ben Grynol (23:12):

So, it’s like they have to knock them all over and put them back in the bucket and start fresh to be able to think in a new way, and that’s sort of the idea of project debt, where you scrap these ideas and you pull it back and this is no longer occupying real estate for free in your mind. Because you’re never, in the back of your mind, thinking about, well, it sort of looks this way or this thing is already over here. Even though I’m pretending to not pay attention to it, you’re still carrying that around until you close it out and everybody nods their head and agrees like, yeah, we’re all on the same page. This thing’s done, closed out. We’re starting fresh.

Ben Grynol (23:47):

Then it really does feel like a fresh start. To the point that you made about carrying that around, one thing that we’re learning is how expensive. This sounds absurd to even say, but like how expensive coordination time is. So, it’s like we under estimate. I think, naturally, humans underestimate the amount of time that things take. We think we can accomplish so much more in a period of time than we actually do. But one thing that doesn’t get scoped as well is team coordination time.

Ben Grynol (24:17):

So, it’s like, oh, this project’s going to be an hour. Well, if everybody reads it for 20 minutes and that’s eight people, times 20 minutes each, you’re like, “Oh, that’s well over an hour of like team time.” So, it’s just like, knowing that when we look at these projects and we say like, “So, we did this with that video project when we were scoping it.” Whether or not the hours are on the nose is hard to say, but like we are saying, “Hey, this is going to be whatever,” I can’t remember the number. Let’s say 50 hours of team coordination time, something like that, and then however much execution.

Ben Grynol (24:47):

It’s like multiply that by some rate and you get a pretty expensive outcome. You’re like, “Is this worth this to us or should we explore new avenues? That’s where retiring project debt really makes sense.

Scott Klein (24:59):

Yeah. There’s maybe some nuance here that, just as there can be diffusion of responsibility at the start of a project, there can also be at the end. This video project is a great example where you were tasked with doing the phase one of it. To do some experiments, you recorded some scrappy videos with Casey. We put them on some of the articles. I think absence of very clear definition of the role of a DRI, that could have just lingered into eternity, and these things just collect. They manifest these little barnacles on the product. It was relieving in a way for you and I to have that conversation to get to a definitive note.

Scott Klein (25:39):

And more to the point that you knew that driving that conversation, even though you weren’t solely responsible for the outcome, that you driving that conversation, part of your job, it’s part of your responsibilities. Just because we ship to members, you’re not done yet. You still have communication responsibility and we got to figure out what to do next. Now, the answer to, what do we do next? May be nothing. And maybe, hey, we’re going to reevaluate in four weeks. But there has to be an answer.

Scott Klein (26:03):

If we sort of apply the same reasoning at the front of a project, I can give example of where some of this definition might help. A lot of my product time, right after I changed roles into head of product, was working on something that we were calling Guided Journey. It quickly became apparent to us that Guided Journey was encapsulating not a singular thread inside the application. By guided journey, we mean things like onboarding tasks, what content we’re going to surface to you, how do we do personalized scoring and recommendations? All of these things came forth from all of the customer calls that I was working on.

Scott Klein (26:40):

It got to the point where we were wanting to get started on the development. I was really struggling personally to actually get the pieces arranged, even before designer engineering had kicked off any of their work, it was hard for me as the product person to get all the pieces arranged in such a way that made sense that, hey, we should do this first, we’ll do that second, we’ll do the other thing third. What was useful, and I think I only knew this because I had experience being a product manager before, is that the thing for me to ship was not this grand master plan about this big project called Guided Journey.

Scott Klein (27:16):

The thing that I ended up shipping was to break the project apart into four separate projects. They each were consumable on their own. They each could get their own scoping and phasing. So, that little judo of being able to say, “Hey, I’m still responsible for shipping something, but what I’m going to ship is four separate project plans that I’m now going to delegate out for other people to work.” I think these are the sorts of things that the checkpoints or the eject points that we put into the DRI process that make it really important and really easy for somebody to come in that doesn’t have product experience and be able to say, “Oh, I have permission to maybe just cancel this project outright. It doesn’t look like members want it.”

Scott Klein (27:54):

Or, “I have permission to break this up into smaller projects so that we can consume them because it doesn’t seem like there’s actually dependent overlaps here. We can just do these separately and that would totally be fine.” Part of my job now is being able to call on my experience from the past to be able to sort of note these things and say, “Hey, if this is what you’re going to ship, you can call that shipping, but it’s not going to languish in the space where you don’t know how to sequence it. It’s not going to languish in the space where you think you should cancel it, but you don’t feel like you can make that call.

Scott Klein (28:24):

It’s up to you to get something shipped. So, whether that is do the project, break the project apart, cancel the project, put the project on hold, you’ve got one of those four options, and we need to be very, very clear about which one we’re picking.

Ben Grynol (28:36):

Yeah. When you broke it apart, it really codified some of the ways of approaching that project in general. With it, it was a lot easier to see, okay, this part of the guided journey falls in product. So, when we use the word product, we basically mean app, right? But there’s, in Guided Journey, there are parts that are content driven, there are parts that are operations like ops onboarding driven, there are parts that … Name a function within the company, there are all these different aspects of where Guided Journey might have a little bit more lift required.

Ben Grynol (29:11):

But before, by just lumping it into this thing that we call Guided Journey, and say, “This lives in product,” it just feels like a big undertaking, and it’s not entirely clear that it’s even the right approach. Then it just feels overwhelming and it like everyone is stretched on bandwidth because it’s like, we’ll all find a place to start, but is it the most impactful use of time? That’s where it gets really hard to say, because it’s like, well, we actually need to solve for like, back to the way that you broke it apart, we need to solve for this first thing before we can even tackle some of the other downstream things like, so part of Guided Journey being personalized education or personalized content that applies to a person’s interests.

Ben Grynol (29:57):

It’s like, well, if we go and we create all this content, but we don’t have, like we say, “Great, let’s create content that applies to a person’s interest.” Then we don’t have rails within product that it actually can lie on. Then it’s like, well, was that the right outcome? Did we test it as fast as we could? Are there ways where we can find out individual interests and then design around that to unlock what features might be like? There are so many different avenues, but just going, guided journey, here we go. It’s just, it’s such a big undertaking.

Scott Klein (30:33):

Two things there. I mean, I think you’re hitting on the, how do we assess these things independently of each other? The content recommendations piece is really, really separate and distinct from personalized scoring, for example, we may want to go of five possible things we could do for content. We may just want to do the first two. Maybe that’s the biggest bang for the buck, we get 95% of the results out of those first two phases. But regarding scoring, we may want to spend weeks or months on it more than we might do for content.

Scott Klein (31:04):

Being able to, like defining the atomic unit of what a project is that a DRI is responsible for, I think lets us have good mental frameworks around, how do we make these decisions independently? What is the value that we’re independently going to be providing to our membership? One other point to bring out up about the Guided Journey break apart was that when we went into it, it was not at all obvious that that was going to be the case, that this thing was going to grow in definition to be so big that it was going to be untenable as a singular project.

Scott Klein (31:37):

I think that’s, when I think about some of the newer DRIs coming into the process, these are the sorts of things that they might not know. We always have the best intentions when we come into a project. There’s a seed, there’s a figment of an idea around something. Let’s go explore and let’s see what we can uncover. Let’s talk to a bunch of members, we’ll talk to each other. We’ll use the app and have the CGM running. We always go in with the best intention of thinking, all right, we’ve already got a loosely bounded box that should be fine. But once you peek under the covers, you just realize, man, there’s a wealth of stuff for us to do here.

Scott Klein (32:12):

There’s so much that we can do that this bounding box of what we’re considering a project that a single DRI is going to be across, it no longer makes sense at all. You are putting pieces of different puzzles together and hoping that it’s going to fit, and they don’t fit, and that’s frustrating. It’s a good indicator when your puzzle pieces are from mixed puzzles that maybe you’re dealing with two separate projects and not a single one. We didn’t know that in the beginning, but we know that now.

Ben Grynol (32:39):

On that point, you were making a boat, really tapping members, tapping into the insights, the feedback that we get and saying like, “Are we on the right track as far as what we’re building?” Because that’s also a path that companies go down to often where they start building things that people don’t really want. There’s a fine line between making decisions based on the feedback that you have and saying like, “Yes, we are going to build this, or no, we’re going to ignore this. We’re going to punt it because it’s too big of a build or it’s not right given the current scope of our business model,” whatever it is.

Ben Grynol (33:12):

But that’s something that we try really hard to do is take this feedback into account and then say, “Where are we falling short?” I think you have, it’s sort of this team mantra now, and you’ve painted this picture that every Friday forum we’ve got clear eyes, full hearts, which is a great mantra to have.

Scott Klein (33:29):

This is probably the hardest part of being a product manager is writing the line between believing that things can be better and knowing that you have a team by behind you that can make them better. And also just having to be honest about where things are at. I think I introduced that mantra. A, I just love the TV show, but B, I thought it was a great way for us to hold that duality in our minds as we go forward. I think that there’s always a sense at a start up company that you have to walk against the wind for many miles at a time, but that you also aren’t lying to yourself that the wind doesn’t exist. There’s definitely a sense of wanting to, I think if you lose either of those, we can maybe paint the opposite picture.

Scott Klein (34:15):

You get disconnected from reality. In a way, most companies die because they just don’t get adoption. They don’t die because some competitor killed them. They die of starvation. They just never get to enough usage, enough revenue, enough eyeballs, whatever you want to call it, to get to play and to succeed. The other one I think is just having people that can be pessimistic, that aren’t trusting of their work counterparts, that are easy to point out ways that things cannot work. We say a lot of yes and here, I think as a way to build upon, as opposed to in competition with, or to break down, or to try to paint false dichotomies. I think that’s the other, maybe, bad place that you can go if you don’t have clear eyes, you don’t have full heart.

Ben Grynol (34:56):

Yeah. If people aren’t pushing back, that is actually a death sentence to startups. There’s the fine line. Sometimes people just push back on everything and you’re like, “Okay, this is not good pushback.” But you do want people to challenge things, right? I say it because there have been times where I’ve got one friend that pushes back on everything, and you’re like, “Okay, there’s no need to push back on that kid’s cartoon. There’s no upside in that.” I’m just being hyperbolic about it. But there are times when you need people to challenge your assumptions about the direction of a company or a product or a project.

Ben Grynol (35:34):

That’s when it comes down to being introspective and being honest with ourselves and be like, “Okay, do we really have product market fit?” Back to the whole death sentence part is like, a lot of companies trick themselves into saying like, “Yeah, yeah, we’ve got product market fit. No, no, we’ve got it. People love what we’re doing.” It’s like, it’s exactly the whole like Rahul Vohra’s outlook on product market fit. It’s like, how disappointed would somebody be if they took it away? If it’s like a 10 out of 10, I’d be so disappointed.

Ben Grynol (36:03):

Yeah, that’s product market fit and it can be with a segment or it can be with like a large broad population. But in general, if people are lukewarm and they’re like, “Yeah, I wouldn’t really care.” It’s like, do you actually have product market fit? It’s like, probably not. That’s something to always keep in the back of one’s mind because that can apply to a business product or even just like a feature.

Scott Klein (36:25):

When we think about the DRI process and the definition, one of the things that I’ve had to, I think really drive forward is, especially with the newer DRIs that don’t have product experience is, what are the things that you need to instrument to be able to gauge your success? Part of building a project is not just shipping the actual code bits to get it done. Take a engineering standpoint. We’re shipping a lot of telemetry that goes into Datadog. We’re shipping a lot of tests that go into our test suite that’s going to run as part of our build process. From the DRI standpoint, there’s a lot of instrumentation around funnel tracking, clicking on buttons, discovering who actually goes through with the thing.

Scott Klein (37:06):

I think absent, very sober, clear eye data around usage patterns and how much people are actually engaging with your thing, you’re just looking for other signals around it. You might look at how many encouraging tweets that got sent out about a feature launch, or if our investors received it well. All of those things are nice, feel good things to have. I’m not saying we should dispose, but it’s very important that, as a DRI co-board that we, or group, we get very good at building into the definition of completeness around a project, the ability and track, is this successful? If we think about our success beforehand, like let’s not just run a post hoc, like attach onto something that seems to be going up into the right, but did we have a sober view of it beforehand? And do we have a sober view of it now? Can we honestly say that this is worth investing more in?

Ben Grynol (37:57):

Yeah. It gets back to the whole idea of being data informed versus data driven too, because sometimes decisions can be made around something that’s like, the data will tell you one thing, but it’s actually not the right outlook. Data might say, hey, this thing isn’t good. But when you dig one layer deeper and the macro data is like, ah, this thing’s not that good. But once you drill down into the micro data points and you’re like, “Oh, there’s just a ton of drop off. The step two drop-off was the broken part.” And then that gets fixed and then you rebuild whatever it is and the flow is way better. And you’re like, “Oh, we just like fixed the friction there and it’s a 10 out of 10, as far as like usefulness to people.

Ben Grynol (38:40):

Maybe one reference point, just to riff on it, is user referral. Right now, if we were to say, hey, if we glean the insight that was like, users don’t refer levels to other users, right? It’s like, well, it’s pretty hidden in product. We’ve never promoted it. We can reduce a bunch of friction. If we did that, would it improve? If we incentivize it, would it improve? These are all the data points to take into account, but sometimes if data is looked at in isolation, it’s like, oh, this thing isn’t a good feature. It’s like, it actually might be a feature.

Ben Grynol (39:15):

I’m using user referrals, not that, that’s a feature, but there could be some feature that’s actually benefiting members or users, they just don’t know how to find it or there’s so much friction to actually using it.

Scott Klein (39:27):

Yeah, this is the sort of perennial problem, I think. It’s even harder to teach, I think, if you have somebody who’s coming in with without much product experience. There’s a wealth of examples in either direction of people that built something, it got a decent amount of uptake, but not great and they thought, we just got to do that one more thing. And it just never works out. Their company goes under, or folks are like, yeah, the referral engine, it’s quite hidden. There’s context to the data that’s sort of listed in the performance with the definition of it.

Scott Klein (39:58):

We look at something like a click-through funnel, but embedded in that definition, there’s just so much around how users might discover it, what types of users are just going to poke around the app and stumble upon it. Are those types of users that might refer their friend using a link like that? Again, a wealth of examples on the other side, where you make one small change, it makes all the difference. I think about even Superhuman, the product, what features does it have outside of Gmail right now? I’m not sure, but speed seems to be a defining feature that allow people to really embrace the product and really get behind the ethos of it.

Scott Klein (40:35):

They’re sort of using the product as signal for what they care about. Asking users, do you care about speed? Of course, they’re going to say yes, but there’s this imagination gap of not knowing what they don’t know. For us to be able to make a calculated bet, this is such a defining feature we feel that it’s worth sort of spending on development time to run that experiment to see if it will work out. I don’t know how you teach that. I think there’s something that’s maybe a little bit of history, just being around this stuff for a while, some people have a good sense of it.

Scott Klein (41:06):

But it’s easy to delude yourself into thinking that, that’s the track that you’re on and it’s not actually. So, yeah, I don’t know how we’re going to solve that in the future. It’ll be something that I’m sure we encounter.

Ben Grynol (41:15):

It’s a hard one to solve though. Let’s refer on the Superhuman example, being able to articulate the feedback is the hardest part, right? Speed. Well, what does speed actually mean? This is getting a bit academic and nerdy, but is it latency? The reason I’m using that is like, the latency of notion, I love notion, but the latency of notion hurts my heart every day. I find it very frustrating. It’s a huge point of friction. Rahul talks about when they first started building Superhuman, how they figured out, based on Chrome, how they figured out how to get things as close to the wood as possible so there was no latency.

Ben Grynol (41:54):

And you’re like, oh, you’re really going on speed. So like, is that speed? It’s like, yeah, that’s speed. What else is speed? Is being able to hit GT to go to your scent items and use whatever shortcuts you use, or H for reminder, is that speed? Is being able to hit certain hot keys to do snippets, is that speed? It’s like, well, the answer is all of it, but this is back to the whole articulation part or feedback, is like, when somebody says I need it to be faster or like, now let’s relay it back to Levels.

Ben Grynol (42:22):

I find the app hard to use. It’s like, well, what’s hard? What they actually mean is like, I’m making this up right now, what they actually mean is like, the home screen takes too long to load or syncing my data. That’s where we have to decipher these things. To your point, it might just be a matter of, the longer you’re around it, the easier it is to really drill down on feedback to keep asking questions to whomever, to say like, when you say speed, or friction, or the app is hard to use, is it the syncing that’s hard to use? And you keep probing until you get to the point, you’re like, “Oh, I see what they mean hard to use is like,” and it ends up being something totally different than what the mental model of what hard to use, air quotes, actually was.

Scott Klein (43:08):

I think back to the DRI process, I spent a lot of time trying to show, or trying to do just enumerate why having functional leaders around and stakeholders around is important. I think this is a great example. I can pull on my own experience here. I come from Atlassian where we did HipChat and then, or HipChat was acquired by Atlassian. They sort of ran it internally. At some point, Slack started to really gain ground. The decision was made to actually rewrite HipChat from the ground up. It launched as this … Actually, funny story, the code name internally was Banana. I don’t know why I remember that, but we eventually called it Stride and it was supposed to relaunch as a competitor to Slack. It just never quite made it. A lot of really good people put in a lot of really work.

Scott Klein (43:55):

But I think Slack’s trajectory at that point seemed insurmountable. So, they ended up canceling the entire project. But in the post board, I talked to a couple of Stride product managers. So many of these conversations, I found myself sort of lamenting, there wasn’t really a feature gap. It’s not that I could upload bigger files in Slack or I felt like Slack organized their channels differently. Even if you get to feature parity, there was something really intangible about, when I launched Slack, I just trusted the loading spinner.

Scott Klein (44:30):

There’s an intangible, if I’m clicking on my keyboard and there’s maybe 10 milliseconds of better timing before the key shows up on the screen, those are things that you feel but that you can’t quite enumerate. I think, as we talk about the DRI process, it is not incumbent on them to really understand these things. This is why we surround them with all of these great people that we’ve hired as functional leads. People like [Allen 00:44:54], people like Andrew, they’ve been around this their entire career. They get it. They are tasked with being the guardian of these principles to say, “Hey, we’re going to do this because it makes sense for our product and I know that because I’ve spent my entire career doing this.”

Scott Klein (45:06):

It sort of alleviates the DRI from having to make that call, that trade-off, things that they might overlook. Do we need a loading spinner there? Yeah, we do. It’s something that people want to grow to trust. The minute that they stop … People are giving us their really personal health information, we have glucose data and we now have blood results for them. All of these small things add up to a large amount of trust that’s going to translate to engagement in the product, that’s going to translate into referring and friends and family members.

Scott Klein (45:36):

It’s not necessarily incumbent on the DRI to really understand and know that as much as our head of design might or our head of PM might. As we think about the things that we need to bake into the DRI process, part of those is just giving them permission to lean on other people for those things to make those calls and just being able to trust that those are there. It’s to give them the space to not have to worry about missing something like that, so that they can focus more on the execution and making sure that the project is able to move forward.

Scott Klein (46:04):

They’ve got really good people around them to make sure that the actual execution and the polish is at the right level, such that our member base is really going to trust what we’re putting out.

Ben Grynol (46:13):

Yeah, that’s exactly it. The biggest thing is also exposure. So, it’s not just saying like, “Hey, Allen and Andrew are available.” It’s that everybody is able to learn from each other. Granted we’re in a stage, we’re small enough that we can have nice intimate book clubs and they’re great. But even things like that, giving exposure to learning new concepts. So, if somebody doesn’t have a lens on, let’s use it working backwards, right? The Amazon Book, where it was just like a good macro business book, and sure, it’s narrative driven about the stories.

Ben Grynol (46:47):

You learn by reading that and then you learn from others by hearing everybody discuss their outlook on it, their viewpoints on it, and that’s how you learn about things that, if you haven’t had exposure to, what are network effects, how do you get those spinning up? What does it actually mean? What makes a good strong network? When does network density matter? All of these nerdy little things. That’s just, it’s like some silly little examples. Those are the things that give people when they’re taking on these projects, it gives them a lens to actually be able to learn about it so we can create these conditions, but without giving those opportunities.

Ben Grynol (47:23):

That’s maybe something that happens in larger companies is people get siloed to roles and then they never really get a lens. You come into like an ops role, let’s say, and then you never really get product experience, or you never really get a lens on engineering. Right now, everybody if you want a lens on engineering, if you want to learn, anybody can just look at what’s happening in threads in the engineering forms and probably pick up a lot of things. And if they really want to dig one layer deeper, it’s like they can ask anybody on our team anything they want to keep learning. “Hey, what are some resources I can dig into to learn more about whatever it is?” In other organizations like in-person companies, when all of these teams are siloed, it becomes very hard to make those connections.

Scott Klein (48:07):

Yeah. One of the things that I love that we do is, every Friday, DRIs with substantial updates get to get up in front of the whole company and share their updates. I really hope we don’t get rid of this for quite a while. One of the things that I find about it is that it’s very accessible to other people that are DRIs right now or that may want to be in the future. It’s really cool to see somebody come in, who is working in a domain that they’ve never worked before, with people that they’ve likely never worked before with either, to say, “Hey, we had this really cool moment where we got to engage the members and here’s what we learned.” Or, “I watched our engineering team really work into the night to ship something.”

Scott Klein (48:49):

Or, “I thought, I was sure that we were going to approach it this way. Here’s like, we’ve got database tables and we’re going to put the pieces here on the screen.” And our design team really rethought, well, what’s the problem we’re actually trying to solve here? And is there a different way that we can go about doing it that isn’t so complicated? That puts a burden on the user. These are the sorts of learnings that, as the DRIs themselves get to circulate amongst each other, I just like that it’s a lens where, if our head of design gets up to talk about some design concept, not through any fault of his own, because he doesn’t do this, but it’s like, okay, cool.

Scott Klein (49:24):

The guy that’s good at design is talking academically about design. I think people engage with it differently when it’s somebody who is specifically set at the top to have responsibility for stuff and gets to have these magic moments where they get to peek under the covers of here’s all these other functions that we have at the company. They actually do some really cool stuff. And to be able to get a front row seat that I think is exhilarating. I think it’s part of why I was a founder in the past and why I’m continuing back into startups that I really get to sort of peek under the covers and you’re in the trenches with people at the same time.

Scott Klein (49:56):

I do hope that we continue these Friday shares because it’s really encouraging to hear these personal stories about how people have these insights, we have these breakthrough moments, or we just get to do cool stuff together. I think that it not coming from the functionally, it’s oftentimes a good thing.

Ben Grynol (50:18):

Give me one sec. I’m going to go grab Nico here. Pam had to go pick up the kiddos from school and I hear him crying upstairs. I’m going to feed him while we do this. Okay. One sec.

Scott Klein (50:29):

All right. I’m going to go grab some water. I’ll be right back.

Ben Grynol (50:32):

Got to say this is the first time I’ve ever fed a kid while podcasting. Always a first, right?

Scott Klein (50:37):

Yeah man.

Ben Grynol (50:39):

I hope you have your kid in your arms right now too.

Scott Klein (50:43):

Dude, he’s nine months today. He’s babbling. He’s way too loud for a podcast.

Ben Grynol (50:47):

That’s hilarious.