Transcript

Gina: You got to fail early. And noisily when I say I know, like, 

Chris: I think you’re right. Raise the flag 

Gina: Raise the flag early as possible.

[Intro music plays]

Chris: Hi, Gina. 

Gina: Hey Chris, how are ya?

Chris:  I’m doing great. How are you? 

Gina: I’m doing well, I’m doing well. I’ve got about 16 deadlines hanging over my head, um, 

Chris: As always. 

Gina: As always, but that’s what we do. We always have something that’s due.

Chris: I mean, that is the way of the world, I think. 

Gina: It really, really is. 

Chris: But, you know, most people are talking about why deadlines are not good and how to work around them. And I think we want to talk about why they are good. 

[intro music fades out]

Gina: It’s true. It’s true. We do. One of the things that we always get asked is like, how do you know how long a thing is going to take? Cause here’s the thing: most of our deadlines are self-imposed, particularly in our work with clients. We have said by this date, you will get this thing.

Chris: That’s right. 

 Gina: So we’re picking that up that deadline. 

Chris: But the analogy I always make is like, when you’re getting work done on your house. And I’m not, I’m not a plumber, I’m not an electrician. And if I need to have major work done, when I get people into the house to look at it, I need them to tell me, like, here’s roughly what you’re looking at, and here’s how long it’s going to take. And we, you know, our clients are the same way. They, they’re not software people. They’re not building products day in and day out. And so when they come to us, they say, ‘Okay, cool. You get it,’ but it can’t be open-ended, you know, Hey, we’re going to work on this as long as we need to work on it. That just doesn’t work in, in nearly every business context. And so it’s critical for us to say, okay, we’ve internalized your needs. And here’s roughly what it’s going to take and how long it’s going to take. And that might not be down to the minute. In fact, it is never down to the minute, but the self-imposed deadlines are such an important thing because they, they make sure that expectations are clear on both sides. 

Gina: This is the thing, right? If the plumber says, ‘I’ll get this to you by Tuesday and then Tuesday comes and goes and it ha and it hasn’t happened, like in your mind, not a good plumber. They said that they could do a thing and then they couldn’t do it. Right. So like there’s a break in that relationship. You’re looking for another plumber, right? 

Chris: Yes, it’s true! 

Gina: Like it’s a big deal. Especially if the plumber on Monday hasn’t said,’ Hey, you know what? I ran into an issue. It’s going to be Thursday.’ 

Chris: Right. 

Gina: So there’s, there’s a couple of ways to miss a deadline. The first is just to miss it. And at that point you’ve lost all credibility. The second is to say, okay, here’s why. You know that the deadline has moved. Here’s why. And here’s the new deadline. It’s very much about setting and managing expectations. 

Chris: Yeah. I mean, ideally exceeding expectations where you can, which is something we always strive to do.

Gina: Ugh, getting it done on Monday would be amazing. 

Chris: But you know, I think a lot of people wonder how do you do it? Like, how do you estimate when something is going to be done? But we like to say it’s an art, not a science. There’s not some magic formula where you can just plug in X, Y, and Z requirements and it spits out your timeframe for you. There’s work that goes into estimating what, what a software product needs and what it’s going to take. 

Gina: There are dependencies, there are known unknowns. There are unknown unknowns. I mean, you really, particularly in our business where we’re building software for clients, there’s a lot that we don’t know when we give a date. It is a, it’s a risky, vulnerable moment, but you’re like, okay, we’re going to work toward this date. You’re going to get a thing by this date. And it’s funny because. We’re a product shop. We build products, we focus on product strategy. We focus on product roadmap. We focus on solving business problems. And when you translate that into a date, you suddenly kind of shift into this like project mode, like ‘have to hit the date no matter what.’ and I think that there’s, like, sometimes a uh, conflict there. Like, what do you mean if you really, you know, a great product, a long-term solution? There’s no, you know, time is not, is not relevant. But here’s the thing. Our philosophy is that time is very relevant and that on that date, you may not see the entire product roadmap. You might not even see the thing that we thought we were going to have when we started, but you’re going to see a thing. 

Chris: Yeah. So speaking of a thing, like what is, what is MVP? What does, I mean, MVP gets tossed around. I feel like half the requests for information that we get talk about an MVP. So what does it mean to you and how, you know, how, how do we let that inform what we are putting forward to a client when, when they first talked to us?

Gina: So an MVP is a minimum viable product. Something that, that, that works, that fulfills a need or starts to. Like hits right at the problem with no extras, no extras. No nice to have just gets to the very core of, of what the problem that you’re trying to solve. The functionality that you’re trying to, to, to put out there. With maybe hints toward what could come in the future, you know, like imagine, you know, that the picture is not quite filled in. But that, that key piece is what’s most important. The minimum viable product, meaning the product is, has a life like has a path forward from, from the very beginning. Rich, uh, one of our co-founders wrote this great piece and he rebranded it ‘minimum valuable product.’ 

Chris: Which I totally get. 

Gina: I totally agree with, right, because if you show value, if the MVP shows value, that means it gets to grow and live on and evolve and become its true and full self. The MVP is not the full and true self of a product. 

Chris: Yes. 

Gina: Um, and I think, you know, when you work in product, you, you really internalize that because you have to make trade-offs all the time. There’s so many nice to haves that we have to cut constantly and it’s painful and it hurts but I think, you know what others who haven’t built software and don’t understand the dependencies and how fluid, you know, making software really can be, and we embrace that, I think that that’s a real shift in their mindset. Like, ‘wait, this is so little.’ It’s like, no, but this gets to the core of what you’re trying to do.

Chris: And this is the first step. Like it’s a confident, first step that you can take. We’re not saying, you know, take the first step and then you’re done, you know, get off the track. It keeps going. You’ve now got a solid foundation, a solid base to build on. If a client comes to us, path one is we have to convince them that MVP is even something they need to think about. Much of the time people are coming to us and they already get it. They already know that they have to scope down what their first thing is going to be, especially when it’s a brand new endeavor, a brand new effort. You gotta start small and build on it. Most people, I think, recently understand that concept. That said, estimation is still hard. It is still tricky to figure out, ‘okay, if this is the thing we’re going to go do, how long is it going to take us to go do it?’ and we have some thoughts on that. We have some advice that we can share about what works for Postlight. But there are also a lot of things that don’t work and maybe it’s worth calling out a few of those. I mean, an obvious one that comes to my mind, is when we hear ‘well, that’s an easy part’ or, you know, ‘we don’t have to worry about that.’ Right? Well, ‘we’ll have permissions, you know, that’ll be easy.’ And anytime someone, an engineer, a product person, a designer says, ‘this will be easy,’ probe, you got to ask about that. You got to understand ‘what’s making you say it should be easy?’ Not just gut-feel, because very often ‘this should be easy,’ implies a bunch of assumptions that may or may not be true.

Gina: A lot of assumptions that may or may not be true. And that, that you may not know about. 

Chris: Exactly. 

Gina: And they may have other dependencies that haven’t been identified for sure. But, you know, early in my engineering career, because I think that this is, you know, a very common mistake that young, less experienced engineers make…, I would have mentors and say, just like, listen, whatever you think, however long you think it’s going to take just triple it, triple it, uh, just manage up to your boss. 

Chris: Which sounds insane!

Gina: Which sounds insane. But also you’re like, oh, okay. So. You know, covering my ass here. Just, you know, just, just that also does not work. That is not that, that, that is just brute force multiplier situation. That, that said, I think that we all, because we’re all sort of naturally technology optimists, and we know what’s possible see in our brain and you know, if you’re experienced, you’ve done it a bunch of times before you’re imagining the happy, optimal path. 

Chris: Exactly. 

Gina: Where you get everything that you need in order, you know, from the API and the credentials and the right people and no one ever takes a sick day and nothing ever comes up, uh, you know, in another part of the project that affects your part of the project. And, you know, just add in scheduling, you know, it was actually… Really, calendars are easy. I’ll just drop in this, you know, existing component. It’ll be no problem.” That’s what you see in your brain, because you’re like, this is going to be awesome. It’s going to go perfectly well.’ And. Never. 

Chris: It’s never the case, it’s never the case. 

Gina: Never the case. You have to have those places, you know what, where you’re like, okay, there has to be some elasticity here and let me manage expectations. Yes, let me estimate for the, not the worst case scenario, but the realistic scenario. Some things are going to go well and some things aren’t going to go so well. 

Chris: Right? The best performing teams ask those questions. When they’re doing this effort, the scoping exercise. They say, ‘what if, you know, what if X doesn’t line up the way we expect, what if we don’t get those API requirements? When we think about what, if there are some unique requirements around localization or, you know, those sort of gotcha kind of things? We have to say, okay, let’s build in some time for those, for those, you know, known unknowns, I guess, falls into that category that you said. I think the same thing applies to design. Frankly, we talk about it a lot with engineering, but we’ve had, we have an incredibly talented design team. And I think sometimes they look at things and they think, oh, I can see how this comes together in my mind. And so, you know, putting the pixels together and Figma is going to be really straightforward. When in reality, what our clients are expecting is not just a design of an article page, but they want annotations describing why things were made this way. They want, you know, the components broken out. They want to think about design systems and how we can reuse what we’re doing on a particular page in another place, we want to think about how the application comes together and the different permutations of, like, a nav structure. It balloons in a way that you don’t immediately think when you’re saying, ‘oh, I’m just going to do these six pages or do these six views. 

Gina: Yeah. It’s all those baked in assumptions. Another example is I remember this was a project that we did, we were talking about the client needs internationalization and localization. Right. We have to support multiple languages. And we were like, yeah, no problem. We know how to do that. No problem. But let’s unpack that at some point it was like, ‘well, what about right to left languages?’ And by localization, do they mean that if you’re in a particular country that speaks a particular language, that’ll do GEO AP, like that’ll know and go to the right language? What about the countries that have multiple languages? Like what about like, like you, you start to… and you’re like, oh, this is actually a huge deal. This isn’t just the ability to put, you know, English and Spanish versions of this content into this website. There’s a lot involved here.

Chris: Totally. Or sometimes it’s not, sometimes it is, we need English and Spanish on this website and then it’s like, okay, great then you can build that in. But, but, asking those questions and validating some of those things is critical as you, as you are, as you are forming these estimates. Knowing what questions to ask and what to, what to rule out and what to pull in can help you get so much better about what you’re putting forward, because ultimately you need to stand behind these dates. They’re, they are, at least a Postlight, they very much inform, they are a healthy constraint. They inform the amount of stuff, the scope that we’re going to be able to get done, and we put something forward and then we stick to it. 

Gina: That’s right. And I mean, on the backend, what we, we, we actually, our estimates for a project, we have a thing that we call it the TOT. The team over time. And we do it by person and month, like Duplos instead of Legos, right? They’re pretty big, rough, low-res estimates, right? Because we are not building the super detailed Gantt chart with like, you know, 25 tiny little lanes with the dependencies built in, and if this is two days late, then everything else in front of it gets – becomes two days late…. Like we actually don’t put that together and the statement of work phase, or in the pitch or proposal phase. Part of it is that we just don’t have all that information. Another part of is that we accept and embrace that things are going to change and it is on us to manage scope. You don’t, you don’t, you don’t define this all of the scope upfront is a, that is an ongoing conversation throughout the engagement. But the thing we do commit to and understand is that, on that date, something gets delivered.

Chris: That’s right. 

Gina: We might not know what that is now. So here’s the thing, like to me, if you miss a date, that’s a bigger failure than if you wait and deliver all of it three months late, right? It’s more success if you deliver less software sooner, 

Chris: There’s the pull quote right there: ‘Deliver less software sooner.’ I think that’s exactly right. And it has served us so well. It’s been critical as we work with client stakeholders to be able to see working software and then walk it around within the organizations. I also think for those who are working at a, at a bigger company where they’ve got senior stakeholders who may not be involved in their day to day, shipping something earlier, that has less is a far better outcome because you will be communicating something with your progress and you will be building confidence in your timelines, in your estimates because you’re showing something. If it’s too big to estimate accurately, make it smaller. 

Gina: Right. Phase it out. 

Chris: Cut it down, phase it out, bring it to a size and a place where you can feel confident that like, yes, this is an MVP. Or maybe it’s not. Maybe the MVP, actually has like three releases in it and you need to do an alpha and a beta, and then you get to your MVP. Because if you are laying out these 12, 18, 24 month roadmaps, and you’re just saying, cross your fingers and hang on tight. And eventually we’re going to get there like.. 

Gina: Like come back in 12 to 18 months. We’ll have something great. 

Chris: We see it all the time. And it’s a recipe for disaster. The longer the time frame, the worse your estimates are. Like it is, there’s gotta be some law named after somebody. I imagine that the longer the timeline, the worse the estimates, it’s just, it just how it goes. 

Gina: It’s true. And, and, and the bigger risk that, the thing that you’re delivering is not at all what people’s expected, right? Like these early small releases, reset and realign expectations. It’s something to have a conversation.’ But what about this? We never talked about that. What do you mean? Tell me more, where is that, in the priority?’ right. It aligns everyone’s expectations along the way. And it, and it just creates like velocity. Software takes time and costs, money and momentum and inertia and positive, like positive feelings about like the progress is being made. That doesn’t happen when it’s like, ‘see ya in 12 months we’ll have something really good for you and 12 months,’ because that’s why, you know, you’re gonna, you’re gonna disappoint. 

Chris: You’re gonna disappoint. We have a structure that seems to work pretty well. We don’t do story points. Some people are very into agile and story points and let’s make sure that we are estimating everything down to the, you know, the most granular detail that we can provide. That doesn’t really work for us. But we do have a system that is somewhat similar- based around t-shirt sizes, small, medium, large, extra large. And small and medium are pretty self-explanatory. Like small should be one quick session, and I get it done. Medium is less than a day. Large is more than a day. And then extra large is that’s where you got to start to wonder, like, is this too big? Can I break it down? Yeah. 

Gina: How do I break this down? Is, is the question about XL? Like if a, if an engineer saying ‘I need a whole week, headphones on, to get this on,’ it’s like, ‘Wait. Why? What’s going on there? 

Chris: Yeah. Can we, can we cut it? Can we trim it in some way? 

Gina: Can we cut it in half and trim it? 

Chris: And t-shirt sizes have been really effective for us. They let us build up a timeline with a high level of confidence, but they don’t require– I mean, I, earlier in my career, I sat in planning sessions, that would be, you know, multi-day affairs where you try to get the entire team to story point every single ticket. And I don’t think there’s any improvement, frankly in, in the confidence of your estimates spending that much time upfront. But it does require a ton of time and energy from the entire team to go through that exercise. It works very well for some teams, but in my experience, it’s far better to get a good approximation using t-shirt sizes that get you most of the way there, if not all of the way there. And yeah, it’s going to change a little bit. Our relationships with our clients, uh, embrace that change. And our, our key stakeholders know that when we put a date forward, we’re going to be confident in it. But as things evolve, because they’re going to be seeing the software, there’s going to be, there going to be changes and we’re going to incorporate them. Um, and that has worked really well for us. 

Gina: It has, it has, but let me ask you what happens when you’re mid-flight and you look at your timeline and you look at what needs to get done, and you’ve go, ‘oh, no, we’re not, we’re not on track. We’re not going to hit this.’ Have you felt that right? It’s like that shot of adrenaline or that moment that one of your team members comes to you and goes like, like ‘we’ve got a problem. This thing that we were, you know, we, we assumed it wasn’t going to be an issue, that it was going to take this, like, it’s actually, this is really hairy.’

Chris: Yeah. 

Gina: ‘Like it’s gonna take three more weeks.’ What, what do you, what do you do? What do you, what do you do then? Because my instinct is to go hide in the woods. 

Chris: No, no, no. 

Gina: That is the exact wrong thing to do is go disappear in the woods and hope that no one sends you an email the day that it’s due. But with that, I mean like fight or flight like that kicks it. Uh, 

Chris: yeah, I mean, I get it. I felt it. But step one has to be communicated. First of all, you got to get on the same page with your team about what you can and can’t do, right? It happens. Something balloons. Can you change the scope? Can you adjust your approach? This is not just an engineering conversation, by the way, this is the whole team. Because sometimes what you actually need to do is redesign the feature and that needs a product manager. It needs a designer. You need to rethink. Okay, ‘search’ became something that’s way bigger than we thought. Can we have a, a modified version of search? Can we have a title only? Can we, you know, this is just one example. But thinking about how the experience could be 80% there, if not a hundred percent there, but you can cut yourself down to like 30% of the work or less, those kinds of choices are really important and they require the whole team. So that, so I would say, get on the same page with your team, and then you’ve got to get ahead of it. You’ve got to communicate. You’ve got to go to your stakeholder and say, listen, ‘this is where we are, and we think the original timeline is going to change and here’s how we’re going to mitigate it. We think if we want to stick to the original plan, it’s going to be an additional X amount of time. We’ve come up with another option. We’ve maybe it’s a couple of options. We think we should go with path A. There’s also path B in path C.’ You should always have a recommendation. 

Gina: ‘This is what we think we should do.’

Chris: ‘This is what we think we should do.’ 

Gina: Yeah

Chris: It’s so important that the whole team be invested in this. You don’t want just the engineers or- Just one thing that’s really bad is when one engineer feels the responsibility for a key feature and then it’s all on them. And you’re like, man, I just hope you, Sally pulls through and gets this done. And maybe she’s going to have to work weekends and… No, that’s the wrong way to do it. You want the whole team invested in what you’re doing and if that requires rethinking a few things… So be it, maybe you have to rethink a few things. 

Gina: It’s true. Being upfront and catching those things as soon as… like the sooner, the better.

Chris: The sooner the better… 

Gina: You never want to be the day before the deadline going ‘we’re actually, we learned, we learned today that we’re not gonna make the deadline tomorrow.’ at that point. 

Chris: Right. Because something like something’s gone wrong 

Gina: Like something’s gone wrong. Like, and this just, this takes constant communication, internal team communication to be, to be in touch. And it can’t just be like PM tapping, you know, a designer, an engineer on the shoulder and be like, ‘How are you doing? Are you on track? You know, because it was of course, like. 

Chris: That only goes so far. 

Gina: Yeah, on track, I got this. And then you go like, oh, no point where you’re like, I have to break news, bad news to my PM. 

Chris: Right. 

Gina: I’m going to, I’m going to stay up really late tonight when I see if I can do that. And then, um, you gotta fail early and noisily. When I say fail. I know, like,

Chris: I think you’re right. 

Gina: Raise the flag as early as possible because you know what, w what’s I think this is a catalyst bad news delivered early is just news. 

Chris: That’s right. I would also say this is one of the things that scrum does well, which is regular demos. And I think this is very, it’s a very good antidote to, um, you know, I’m just going to hold up and hope for the best, because when you’re showing your progress every two weeks or every week or every three weeks, or it’s on some regular schedule.. You’re not looking to, like, hold people’s feet to the fire, but it is a good natural accountability method because you’re just looking at what’s there and what’s not there. So. You got to show your work 

Gina: and internally as well as the stakeholders. 

Chris: That’s right. And so it can, it can help overcome this instinct of ‘I know I have something big. And so I just want to go,’ to your point, like, ‘I want to go lock myself in my room and code until 3:00 AM and hopefully I get it done.’

Gina: Yeah. 

Chris: If you break things down so that they’re small and then you’re regularly showing your work, it helps to, you know, shine a light on these things in a very, hopefully healthy, positive way. If the team is supportive and working with each other, it’s not going to be the end of the world. If you’ve got an engineer who, or a team who has underestimated a big feature, because you can react to it, you can break it down, you can catch it early, etcetera, etcetera, 

Gina: You know, in our business, because clients come to us and say, I need to build software. You know, how long it’s gonna take, how much is it gonna cost? And we know that they’re going to other agencies and also getting ‘how long is it going to take, how much is it going to cost?’ Um, something that we have to work against, you know, a lot just during our sales and proposal process is being realistic, right? Our initial estimation of how long it’s gonna take and what kind of teams is going to take, you know, where people aren’t working on weekends until 3:00 AM, has to be realistic. And that can be some bad news because of a realistic deadline, you know.. 

Chris: In the beginning, you’re saying? 

Gina: In the very beginning. And when I say it’s bad news, it be, you know, the longer it takes, the more people it takes, the higher the cost. And we are, we want to win business. Let’s just, you know, let’s, let’s be honest. Right? So, so I think it can be really tempting to be like, ‘well, we can cut this, we can cut that, and if things go, well, we could probably get this done, you know, in three months instead of six months.’ But that’s that we never want to be in a position where we’re handing the team a mandate and a timeline unrealistic to, to begin with. 

Chris: It sets us all up for failure. Like it’s not good for our team. It’s also not good for the clients. They may think. Great. I mean, it goes back to the plumber analogy, right? It’s like, ‘great! I’m going to get my pipes fixed on Tuesday!’ And that was never reality. So being – breaking the bad news delivered early, it’s just news, breaking it early, um, and resetting those expectations in that conversation.. It’s so important. 

Gina: Yeah. And I mean, look, we’ve had, we’ve had prospects come to us and say, we really want to work with you, but, but we got, you know, somebody else said they could do it for half the cost and half the time. And, and we’re like, look, this is your decision. This is your business, but you should know. That it is not, it is not possible to do this in that amount of time. They are underestimating. There’s a possibility you’re going to be set up for a world of pain when it comes time and they realize this is much bigger there. And you’re going to get, you’re going to get hit with a bunch of change orders to get something. So we’re, we’re being, we’re being upfront with you and honest about you with you about what the stakes. We think that this is what the stakes we built off. Everybody takes that, receives that really well, whether or not they decide to go with us. They’re like, we appreciate you saying it. At least gets them to ask more questions of the, of the other partner, you know, offering, uh, ‘I’ll get this done by Tuesday,’ when really that like that part it’s going to take till Friday to come in.

Chris: Exactly. 

Gina: And you’re not going to find out until Tuesday. 

Chris: And sometimes we have prospects who go with those other, those other opportunities and we say, ‘okay, Best of luck. If your situation changes, please feel free to reach back out.’ We’ve had a few people who reached back out. Um, yeah, because sometimes it doesn’t go very well. The other thing that’s just worth highlighting, you have to also stick by your word because there are some situations where you put a stake in the ground. You do have a deadline at a timeline, and it’s the scope that you. And when things don’t go your way and you try to re-scope and you know, you can’t make it work. Like sometimes you do have to add another two weeks to the end of the project or something like that. And it’s been very important to us and it’s critical to the, I mean, the ethos and the reputation of the firm that we put in that extra time. And we, we stick to what we said we were going to deliver. And so do we believe that the timelines are important and that estimation is important? Absolutely. It is. It is critical in all the ways we’ve been. But in those rare instances where it needs a little more time and energy to get it right, we’re going to get it right. I think that’s the other thing that is just important to recognize is that when you do have to go a little above and beyond a little over to, to stick the landing, you gotta stick the landing.

Gina: Definitely. And, and, and sometimes how hard the deadline is, is, is one of the things that should inform your estimates. 

Chris: Great point. 

Gina: For example, if we were scoping a project, say that was an app that was going to be, you know, had to go live for the Super Bowl… 

Chris: Hypothetically! 

Gina: Hypothetically! the Super Bowl date, that’s not gonna move! That is a hard deadline. That thing has to get done by that date. And then that has to inform some of your, your, your estimates. There’s no like, ‘Hey, we’re going to need two weeks.’ That’s not, that’s not a possibility, right? This is one of the questions that we ask when we speak to a client, how hard is your deadline? What dependency? Is there a launch? Is there a, is there, what’s happening in the world that it guides that? And often it’s like, you know, not a hard deadline. We want it by this time, but not a hard deadline. And sometimes it is very seasonal. It’s tied to an event, it’s tied to a business need that has date debt that isn’t going anywhere. And that’s something that should inform, you know, how we, how we staff and scope it out. 

Chris: Absolutely, absolutely. 

[outro music plays]

Chris: Well, this is a, this has been great, even though this is hard, we actually love this. We love pulling, uh, our digital strategy team into a room and then getting them to tap a PM, a designer and engineer, to work with a prospect, figure out what they need and then figure out how we can get it done for them. And it’s something that we are constantly learning and evolving how to do better with this company, with this group. If someone is. A project that they’re thinking about that they want to get their arms around. What should they do? Gina? 

Gina: I’m so glad you asked. They could send us a note! Uh, to hello@postlight.com. We, we really do love the stuff we love talking about what problems you’re facing, asking all the right questions and putting together an idea of how, you know, what it would take to get it done. It’s, it’s the best part of the job. Every day. We talk about estimation in one way, one way or another. So do get in touch. hello@postlight.com. 

Chris: We’d love to hear from you! 

Gina: Um yeah. And we’re also on the social media as well as Postlight. 

Chris: That’s right. Thanks very much. Talk to you soon. 

Gina: Thanks Chris! Back to work. Bye. 

Chris: Bye!

[outro music plays louder]