Transcript
Chris: I feel lighter. Just hear you talking about it. [laughs]
Gina: [laughs] Preaching the choir.
Chris: That’s right.
[INTRO MUSIC]
Chris: Hello world. I am Chris LoSacco, the president of Postlight, a New York City based digital strategy, design and engineering firm. And I am coming to you this week with my business partner, Gina Trapani. Hello, Gina.
Gina: Hey Chris. Good morning.
Chris: How you doing? Good morning.
Gina: Doing great. Doing great.
Chris: I was hoping to talk to you today about a sticky subject in developing digital products, which is when do you move fast and break things? And when do you slow down and clean things up?
Gina: Mm-hmm. The perennial question of all product teams.
Chris: Yes. And so let me start by asking you a question. Shouldn’t you always move fast and break things? Wasn’t this a whole Zuckerberg thing? Like…
Gina: This is the whole Zuckerberg thing. Mm-hmm.
Chris: You always have to be, constantly, you know, pushing the envelope and you should be going 80, 90 miles an hour. And if that means some things get broken along the way, so be it. You know, everything gets made up at the altar of speed when it comes to how you develop software. I have my own opinions on this, but I’m curious to hear, maybe we start, why not always go fast?
Gina: Yeah. I mean, this is, this is a great question. Move fast and break things. You know, Zuckerberg made this famous, or really came back and bit Facebook in the butt when they had major privacy problems. Like a big—like the platform kind of got away from them. They were breaking stuff that affected people’s lives, you know, in really terrible ways. You know, harassers and privacy and information leaking in the way that it shouldn’t. So “move fast and break things” really didn’t serve them, kind of bit them. I mean, it’s a—it’s a really risky approach, right? But I do think that it is appropriate for a particular time, right, in product and platform development. Right, Because you…
Chris: Say more about that.
Gina: Product innovation and getting something going, right, I mean, especially at the beginning of the life cycle, especially if you’re in a startup situation where you’ve got a brand new product, you don’t know that you have product market fit, you don’t really have the users yet, but you’re looking to do something new and something different and something innovative, right? And you know, that ability to iterate very, very quickly and see, “oh, we—we—you know, we didn’t get any update. We had this strategy. We shipped a thing. And we didn’t see any uptake from users.” That ability to say, “You know what, scrap that. We’re gonna try this next thing.” Right? And to move very quickly. Look, you’re gonna have, you have to be able to say at some point, like, “let’s just see what breaks you.” you and I talk about this in the business here. Sometimes we say, “You know what? We should try this new thing.” And it’s like, “Oh, but you know, is the domino effect gonna really hurt us?” And it’s like, you know what? In this case, like, let’s see, let’s see what breaks and we’ll fix it if it does, right? Like there is a sacrifice. Like there’s a—a moment where you wanna take that risk and for the sake of innovation or moving quickly. Because, you know, often, particularly in a startup situation, you know, you’re—the—your survival, like, depends on your ability to innovate and to find something that actually works, right? So I’m—I’m kinda—I’m defending and I never thought I’d be in this position to be defending Zuckerberg…
Chris: [laughs]
Gina: But I’m defending “move fast to break things” a little bit, because otherwise, if you’re at the beginning of trying to make something new and interesting and innovative and you think about every single thing that could go wrong for any move that you make, it also is just that—it’s a mindset, right? Like I think that he, he made this a mantra because he wanted people’s mindset to be, “We’re trying experiments every day and we’re gonna go pursue the stuff that works and we’re gonna sunset the thing that things that don’t, and we’re not gonna worry too much about getting it perfect,” right? Right now. And I think it’s appropriate, at the beginning.
Chris: I completely agree. I think you said a lot of interesting things there. I want to go back to something that you said at the beginning, which is when you’re trying to figure out product market fit, you have to be able to respond really quickly. When I think about prototyping, why do prototypes? Why build something in Figma that you put in front of users? Why build throwaways in the very beginning of a project? And this is why. Because you have to prove out some of your ideas. When you’re in the proving out phase, you do need to move fast and break things. You do need to understand because you need to try a lot of stuff, especially if it’s a greenfield project that does not exist yet.
Gina: Yes.
Chris: You’re not gonna get it right on your first crack. Or the odds are, you know, astronomically high that you’re not gonna get it right. And so you have to put a lot of things out there. And if you want it to be great, you’re gonna learn from the things that work and the things that don’t work. And that means you’re gonna have a lot of half done kind of broken ideas that just didn’t work that you need to shed. So I completely agree with you at the beginning of the project, and I think what you’re in that prototyping stage, and I mean prototypes in the—in the sense that you don’t intend them to actually be the production version of the platform…
Gina: right.
Chris: …you just build something as fast as you can to get the kernel of the idea, right? And then you put it in front of people and see how they use it, see how they react to it. So that’s number one. The other thing you said that I thought was really good was this idea that you don’t know where something is going to break necessarily. And so you might have to let it break to figure out where you have to shore it up.
Gina: Mm-hmm.
Chris: you know, we always, we—we talk about with our engineering teams, You know, the curse of premature optimization, where you think you’re building for millions of users and so you, you shore up parts X, Y, and Z of the platform and then you release it, you know, to real users and parts A, B, and C break and you weren’t even thinking about them. And all the effort that you spent showing up X, Y, and Z may have been wasted. And so it’s a different take on “move fast and break things,” which is sometimes you have to see where your true failure points are.
Gina: Yes.
Chris: And then you can figure out how to put them in the right spot before you invest a bunch of effort that may be wasted. And I don’t think this applies just to engineering teams, by the way. I think product people need to think this way.
Gina: Yes.
Chris: I think designers need to think this way. Designers spend, not always, but designers can sometimes spend a lot of time on edge cases and making all of these screens and states that, that, frankly just, they’re not core to what the product is, what the platform is. And it’s—it’s a—a set of work that just doesn’t move the needle very much. And it’s, and again, I come back to, in those early stages when you need to be focusing on what is the core of the thing you’re building. You want all of your energy across product management, product strategy, design and engineering to be going at the heart of the product and—and all that other stuff has to melt away. And that’s when I think of “move fast and break things,” that’s how I interpret it, which is, you know, make sure you’re focused on the core.
Gina: Yeah, I mean, I think that’s absolutely right. You know, you build a feature, you work on it for months and months, it launches, it doesn’t get used a whole lot, right, now, you move onto the next thing that may threaten the first thing that you did. But if no one’s really, you know, if no one’s really using it, it’s okay. You have to have a little bit of a mindset of like, okay, like I’m willing—I can’t get too attached, right, to this thing that’s not working. I need to be attached to the core vision, right? I can’t be attached to some costs or this thing that, you know, I was sure was gonna be, you know, great. And actually it didn’t turn out to serve the business goals or the user goals, right? Like, it—it requires some letting go of ego, some humility, some—some ability to, like, throw out your work, right? Like, you know, because something might break and it might not matter that much.
Chris: Right.
Gina: No one might notice. Or it might not affect the business. Then you go, “Well actually we don’t need this thing that was broken. We can actually—we don’t need to fix it. We can actually just sunset it.” That’s actually success, right? Cause the—the less software you’re maintaining in building, the better. The less…
Chris: One hundred percent.
Gina: [crosstalk] …Surface area there is, right? To worry about. This is a very, very particular mindset. I think it is one that smaller teams, I think can—can internalize a little better. I think the bigger that you get and the more process that you—you have and—and I think, you know, particularly in the case with Facebook, It started to really not serve them when Facebook was so big and that breaking something just had such large implications over a huge user base. Like back when they were like Harvard only, you know, like only this school and that school and they were, and they were still pruning themselves like, I think that made it made a lot, a lot of sense. So I do think it’s appropriate, I think it’s appropriate, especially like more in the beginning stages. I think it’s easier for small teams, but this is also, maybe this is a different episode, very difficult mindset for particularly a small team inside of a big organization to really internalize, Right? So you have to sort of build those—those walls around—this is why people start innovation studios, right?
Chris: That’s right.
Gina: We need to—we need to take away all the—you know, risk averseness of the—of the bigger organization and let people move fast and break things. ‘Cause we know that that’s only the, that’s the only sort of environment where, like true innovation can happen.
Chris: That’s exactly right. I mean, there is risk inherent in going after these new things. And I mean, breaking things is risky and, and breaking things in the context of the software that you’re putting in front of people. It has risk and so you do need to have buy-in from at least your team and hopefully the stakeholders that are looking at what your team is doing. But when you’re trying to invent something, or even when you’re trying to reinvent or reimagine, I mean, we’ve worked on projects where we are modernizing big existing platforms and the same kinds of things are necessary. You need to take risks and try a bunch of stuff and not all those things are going to work, and that’s okay, and you need to have agreement amongst your team and buy in amongst your team that like that is how you are going to approach it. And especially when it comes to engineering. But even design, even product, you need to be scrappy in the beginning because you do—you want to be able to throw things away. You want to be able to shed the things that don’t work. And if you’re too committed to what you designed or what you built, it’s gonna be harder for you to throw it away. But you reach this inflection point where once you have proved out the core idea, once you do have something that starts to feel like, “Okay, now we see how this fits, now we see where this is going,” then you move into a different mode where it is little slower, a little more methodical. You are thinking about the longevity of the platform that you’re building, and you’re thinking about not accruing too much debt, whether that be technical debt or design debt or product strategy debt, which is a thing. And your choices get a lot more considered once you go forward. And figuring out where that inflection point is is tricky. It’s not always obvious, especially to, you know, teams that are creating something from the beginning, to know when they move into, you know, that second phase of product development work. You know what I mean?
Gina: Yeah, definitely. I don’t know, A loose metaphor is like, you’re going on a trip and there’s like, you know, we’re deciding where we wanna go. That’s the beginning. The “move fast and break things.” Like—and this requires—and in our world, this requires changes to the team, right? Like you need a team that can function the best in these different, So—so in the trip, you know, you got those big sky thinkers, right? Who are like, “We could go here or we could go there, and these are advantages going here and there,” right? And then once you sort of figure out that—the general direction in which you wanna travel, right? And now, okay, you start to plot the path a little bit, right? “Okay, now we need the team that can move forward. But there are gonna be those forks in the road. Maybe we should take that other road.” And so like, I think that in the—that those beginning stages, you know, you want those strategists, those big thinking strategists that can connect, you know, what you’re building to the business goals and can think like very big and less specific, right? But then as you move forward in the project, you have to start to execute, right? You get a little bit more—the path becomes a little bit clearer. There’s a little less ambiguity and there’s more of just like, “we need to turn the wheel and move forward and start writing tickets, and start creating designs.” but there’s gotta be a balance, right? Cause there are checkpoints along the way. “Let’s look at this prototype. Oh, this didn’t go so well. Okay, now we, we need to make some changes.” And then, as you know, as you get closer and closer to where you know, the destination, right? It becomes very clear. “We just gotta put one foot in front of the other. We gotta get on this train.” You know, like, it—like, the work becomes pure execution, right? You know, it’s the—you know, the funnel—I think it’s the funnel of uncertainty. What’s it called?
Chris: Cone of uncertainty.
Gina: The cone of uncertainty, right? Like it gets, it gets sort of narrower as you, as you go along. I mean, you could argue that no software is ever done, so the cone never actually, you know, you never really actually made it get to the final destination, right? But if you’re working in phases, particularly in the beginning phases of a greenfield project or modernization project. What’s interesting about the modernization project is. I think, you know, when we see this with our clients, I think you think, “well we just need to upgrade this software,” right? Like, “it’s slow, you know, it’s kind of ugly and bad and we just wanna, we just wanna rebuild this, right? It should just do exactly what it does now, but like rebuild it and make it faster and—and look good.” But the thing that we see is that we start, you know, we come in and we often come in, maybe not necessarily industry experts, but software and digital product experts, and we start asking questions about first principles. Like, why does this do this? And the shocking thing is, is that most of the time our clients or stakeholders, Can’t answer that question. They…
Chris: They say, “I don’t know.”
Gina: They don’t know. They can’t answer the question. “Because it’s the way it is? Because I assume there are some other groups or systems that require that?”
Chris: “Because my predecessor made this decision?”
Gina: “Because my predecessor made a decision, and I actually don’t know—I don’t know what the history of the decision is? But my mandate is to modernize this thing. Can we—so can we just make it do that?” And so we—we try to press, right? Like, but why ? Why do you need this? Right? And oftentimes, you know, we’ll turn over some rocks. And we’ll say, like, “Oh, because this had to talk to a legacy system that doesn’t matter anymore.” Or like, “this was related to a business,” you know, “initiative that doesn’t exist anymore,” right? Like, so we can—we can strip away all this old stuff, right? I think that, you know, not to, you know, overtly sell our services here as a—as a digital partner, but—but like coming in as a third party who doesn’t know anything, who is completely free of like historical context and the culture of the place, just asking, you know, just very naive questions, “why is this the way it is?” And figure it out, nationalized this, you know, you really start to uncover a lot of cruft. And see that like, “actually we don’t, we don’t need this. Or what happens if we built it without this. The—Let’s break it. Let’s see what happens.”
Chris: Right.
Gina: You know?
Chris: I think what’s interesting about a project that’s in that stage of its life is that you can kind of do both things. Like there are probably ways where you could. Make what exists today a little bit better without breaking too much, right? And that’s when you go in with a scalpel and you say, “I’m gonna make some surgical updates here. You know, I’m gonna make one sub-process a little bit more efficient. I’m gonna make one API call a little bit faster.” and like those kinds of updates, without breaking the system, they can have incremental progress and start to, you know, make life better for someone using a front end somewhere. But you can also say, “What if we rethought this? What if we went back to first principles and said, you know, does this API really need to be designed this way? What is this,” you know, “service actually meant to do? And how can we make sure that we are building it from the ground up or close to the ground up with those things in mind?” And we’ve done that for our clients. We’ve said, “You actually need to reformulate where this fits in the stack.” And in doing so, that’s not a minor improvement, right. This is when you’re talking about, like, you know, “You’re gonna make this 10 x or 50 x faster because you can start from a clean slate.” And that, you know, that is not about breaking things, you know, just to break things. It is about identifying where, where’s that business value?
Gina: Yeah.
Chris: And then how can you rethink the tech to enable that business value?
Gina: Yes, absolutely.
Chris: Engineering is a craft, and sometimes, especially at Postlight, where you’ve got these really top shelf engineers who just really care about what they’re doing, their instinct is to, you know, make the code beautiful. Like, “I wanna, I wanna make sure that this is pristine. I wanna refactor this until it’s exactly what I expect…”
Gina: “I think it should be.” Mm-hmm.
Chris: … “What I think it should be. I wanna make sure that this is so easily maintainable for decades in the future.” And these are all like good instincts. But you have to weigh them, right, against, all projects are constrained by something.
Gina: Yes.
Chris: Time, budget, whatever. And you need to make sure that you are, you know, approaching the craft of programming, knowing your constraints, and knowing that sometimes you can’t rethink something from the beginning, and so you have to be a little more targeted in your approach. Or you have to think, “Okay, I’m going to carve off this one small piece, which I know is relatively straightforward and that’s what I’m going to attack and I’m gonna make peace with the fact that I can’t, you know, I can’t rebuild this whole thing from scratch.” Which is sometimes what you wanna do, especially when you’re coming into a new code base.
Gina: Yeah, I mean very, very much so. Like, I—I think that—that engineers wanna refactor, they wanna pay down tech debt. I think really good high end engineers hate the idea of “move fast and break things” or—or doing things kind of a little bit slapdash in the beginning just to see if it works. But I think that it’s so important, and I’m saying this as—as an engineer myself, like, it’s so important for engineers whose time is expensive and whose expertise is very specialized and who are treated—you know, engineers in our industry are treated very, very well. Right? But there’s a humility that—that every engineer has to understand that the code that they write in push is in service of the product, and the product is in service of the business. Right?
Chris: Yes.
Gina: And so I’ve seen situations especially on—on engineering heavy teams, where you have very well developed and well intentioned leaders, you know, who are like, look at the stack and say, “This area over here, this is garbage. We need to rewrite this so it’s in this language or that it’s optimized this way.” and I’ve seen product people who you know, kind of get—or—or the roadmap, kind of go off track a little bit because you have these engineering leaders who just really wanna pay down tech debt, you know, or, or rewrite this thing, refactor this thing because they don’t like it. Right? You have to be so careful about making the decision about whether or not that effort is the right effort to spend your time on. Right. And I think especially, I mean, you know something we talk about a lot, right? Like you have a non-technical PM and you have a very strong engineering leader, you can fall down the trap of paying down tech debt or, or refactoring stuff that already exists. And it stalls progress on the product and the platform, right? Like if users aren’t there, if it’s not serving the business, if it’s not serving the product, then—then it’s a waste of time, right? But also high performers and great engineers wanna work on code bases. That are modern and good, Right? So like, it—it—you know, it’s a balance and—and modern strong code bases are easier to update and, you know, easier to work with, right. So like you have to sort of weigh like the return on investment and that time paying town tech debt and—and refactoring, and your ability to move faster later, you know, And also like, what’s important for the product, you know, I think, I think there has to be a, a nice balance between, you know, moving the product forward and new and—and stuff, right, and—and shoring up what’s—what’s in place.
Chris: I couldn’t agree more. I think this, like, TikTok kind of motion…
Gina: Yes.
Chris: …where you, you know, you push the product forward and then you make sure that you come back and do those under the hood updates. Remember when Mac Os used to do this? They used to have like a big new feature release and then they would have like a, you know, “we’re gonna clean things up” release, Which is not about a lot of new features, but you just felt like the whole thing was more stable.
Gina: Solid and stable.
Chris: Yeah.
Gina: Mm-hmm.
Chris: They moved away from that. But I think that—that it—it’s such a good pattern. We—you know, we are not strict Scrum at Postlight. We don’t—we’re not agile to the core. But I think this kind of approach works really well if you’re in a regular sprint cadence, because you can make, you know, one or two sprints about new front facing features, and then you can make one or two sprints about, you know, shoring up what’s underpinning your platform. And it provides a nice balance for what is actually going to move the business forward and what’s going to, you know, be adding value to users and what’s gonna be adding, like long term, you know, stability and, and foundational updates to the software you’re working on. And I think both are important. And sometimes you have to invest in, you know, an under the hood improvement that’s gonna pay off in a big way for users, but it’s just gonna take a little longer than, you know, lighting up a—a—a new filter on the front end or something.
Gina: Yeah. Have you ever been in the meeting where the product leader, or you know, someone from marketing, or a leader at the company or on the product team comes into the meeting with the engineers and says, “We’re gonna do something completely new,” right? “We’re gonna build out our user acquisition,” you know, “we’re gonna completely change our user acquisition funnel,” or “we’re gonna totally change the way the experience here. We’re gonna,” you know, “make this—” And announce kind of a fundamental change to the product that the current platform doesn’t—doesn’t support and that the engineers were not thinking about and did not plan for. Have you ever, like, looked at the faces of engineers who realized…
Chris: [laughs] Yes.
Gina: … that the thing that they built, and like, were so convinced was so future ready and, like, could support anything the business—like, you see their faces just like drop. And—and have, have you been in that meeting and then–
Chris: Oh yeah.
Gina: Have you seen engineering leaders be like, “That’s not—we never talked about this.” Like, “we didn’t plan for this at all. Like why are we doing this? This is not—like this is gonna be months. Like this is a totally, completely new thing. Like, we’re not ready for this.” Have you ever seen this meeting? And then you see…
Chris: Oh my God, yeah.
Gina: …the product leader or the salesperson or the marketing person, just look at them dead in the eyes and be like, “This is what—this is what the business needs.”
Chris: Right.
Gina: [laughs] And then, you know…
Chris: [sarcastically] It’s a wonderful moment..
Gina: It’s—it is a wonderful—it is an unbelievable moment. And, and it’s this moment of like, “Oh, no. Like, we’ve got a lot of work. The—the business or the platform just took a turn that we didn’t foresee. And now like we’ve got a lot of work to do. Like we just didn’t, we just didn’t know.” and look, a good engineering team goes like, “Okay, how do we make this happen in the time that we need to make it happen?” You know? And then you have the product leader or the marketing leader go, “I thought you built this, like, incredibly flexible and adaptable and future ready platform, and all I’m asking is that you make the user funnel,” you know, “a little bit better. This shouldn’t be that big a deal. Are you guys a bunch of clouds?” Right? I mean, we—we actually, you know, we—we’ve had clients call us in and be like, “Can you just evaluate our engineering team? They seem to just, everything seems to be such a big ask and everything’s so slow. Is our platform actually good?” this was—I was actually in this situation. I was brought in as an architect and literally my—my job was to like, “walk me through—go through the engineering leaders, but walk me through your platform. What is your stack? What are you doing, and what is your—what are your processes?” Because the leaders, you know, the CEO and—and this were like, why is this taking so long…
Chris: Didn’t trust.
Gina: …to launch a… They didn’t—they didn’t trust the engineering team. And they were like, “we”—you know, “we ask for things that seemed very obvious to us from a—from a product standpoint, from a business standpoint. But you know, we have an engineering team telling us this is gonna take six months. What’s going wrong here?” and you know, in that particular case, the platform was great. Super modern, very well architected. If we had started a greenfield project, like, we would’ve done it the way that they did it. But it was, there was this like—there was this like tension, you know, and this feeling of like, “Oh, oh, that’s gonna take several months. Like, we didn’t, you know, we weren’t thinking about that when we architected this.” And so—so—so much of it is just like team dynamics and the expectation that things are gonna change and you’re never gonna get the code or the platform, the technical underpinnings of the platform perfect and ready for, you know, everything to just be a tiny little update.
Chris: I mean, that’s it right there. And I think the best engineering teams know that. And they embrace that.
Gina: Yes.
Chris: And they say, “We’re not aiming—we’re not aiming for perfection. We are craftspeople and we are gonna care about what we do. But we also know that there’s a limit to, you know, we can’t spend months on end refactoring. We’re not gonna, you know, there’s no value in that. And so we’re gonna figure out how to balance user needs with shoring up the things that we’re writing.” And that’s sort of what it comes down to.
Gina: Yeah.
Chris: Even in maintenance mode, like you need to be thinking about, it’s not just about refactoring. It is about providing continual new value to the people who are actually using your platform.
Gina: That’s right. And, and I think it’s important, you know, in maintenance mode and support mode, you know, you get assigned a bug, gotta fix this bug. And you know, I’ve seen engineers say, “Well this bug is because, you know, this whole part of the stack is kind of busted and not ready to do this thing. Right? So like, really we should rewrite this whole thing.” and you know, and it’s like, “okay, there’s a time—there’s time to do that, and there’s a time to put the bandaid on, and figure out how to serve the user in the best way without going all the way down the stack and refactoring the whole thing.” Right.
Chris: It’s—it’s the same thing with design. You know, we’ve had designers who are like, “you know, I don’t wanna just add this field. I wanna rethink this form.”
Gina: Yes.
Chris: And it’s like, I get it. But also you need to know when to add the bandaid sometimes.
Gina: Yeah.
Chris: And especially if it’s something that’s not used very much or just not going to like impact the business in any way. You just have to say, “This is not where we should be spending our energy.” There is a constant question in front of every team, which is where should we be spending our energy? And..
Gina: That’s right.
Chris: You have to have a good sense of your North star and your vision and know what, you know, where your product needs to evolve so that you’re doing that calculus every single time, every day. Well functioning teams are thinking about, regardless of where you are in the—in the life cycle, whether you’re at the very beginning or you’re, you know, 3, 5, 10 years in, you have to be thinking about where am I going? Where am I moving the platform, and how do I align my small, you know, micro decisions on a week by week or sprint by sprint level, to the ultimate goal of, of progressing this thing that I’m working on. And that’s gonna guide how you make these trade offs and how you understand, “is now the right time to invest in refactoring something, Or do I have to just put the bandaid on and spend my energy on the more important thing that is really gonna demand, you know, more attention?”
Gina: This is such a key, key, important skill for—for everyone, right? For every professional and every leader. But I see this particularly with like high performing crafts people who really care about the thing that they produce and wanna do the absolute best job. I mean like the best attributes, the cream of the crop, the like A plus—A plus performers. There’s a tendency to assign yourself work that is not as important.
Chris: Yes.
Gina: There’s a tendency to just wanna get it bright. And as you’re going through your work being like, “You know what, at some point I should really redo this form.” And you know, “I really wanna take a look at this.” Right? And then you wind up with this huge to-do list, and you’re spending your time doing the little pet projects and priorities because the thing isn’t perfect that doesn’t have a high impact. Right. And then two things happen. Either you get—and this happened to me as an engineer, I got scolded like in a—in a team meeting by my product managers early in my career.
Chris: Mm-hmm.
Gina: and was like, “Why are you working on this?” And I was like, “Well, you know, I just wanted to clean up and…” And it is like, “no, this is not important. Why are you working this.” and I was, I was actually embarrassed. But there, there’s one—two things. You either get scolded and you know, you get told, “stop doing what you’re doing and work on this important thing.” Or you wind up into, like, a nights and weekend situation where you work on the pet priorities during the business day and then you’re like, “Oh wait, but I have this other stuff.” right? I mean, ideally, a product leader or your team leader is pushing on the stuff that’s high, that’s high impact, right? And it starts—and if—if you’re putting your pet priorities, your nice-to-haves, your little to-do list in your mind, like “I just—I just wanna clean this little thing up,” ahead of those priorities, then you, you wind up a situation where you’re working unsustainable hours, right, to get it all done. So I think that like shedding the, like, “I would love to do this when I have time,” and like, and like letting go a little bit of everything being perfect and, and refocusing yourself on the highest impact things that you can spend your brain on, your time on, your effort on. Oh, it’s so key. I mean, it’s something I still—both of us, you and I talk about this all the time. Something I still work on a day to day basis, but I think it’s also really important for engineers and for designers and even product folks, you know?
Chris: Completely. I think this is a good place to leave it. We love talking about this stuff and if you are thinking, you know, “I really need to make sure that my team is oriented or in the right way or thinking about my platform or my product in the way that Gina and I are talking about it,” we’d love to hear from you. Please send us a note hello@postlight.com. We will give you advice, we will give you guidance, and if we can help, we’d be glad to talk about how we could help. We love hearing business problems of all shapes and sizes. That’s it. We will see you again in a week. Thanks everybody. Thanks for listening.
Gina: Thanks everyone.
[OUTRO MUSIC]
