Transcript

Chris: The more the works get gummed up, the more we have to make sure we’re degumming them. That’s not, that’s gross

[MUSIC INTRO]

Gina: Hello world. Welcome to the Postlight Podcast. I’m Gina Trapani, CEO of Postlight, and as always, I’m joined by my partner in this business and president of Post like Chris LoSacco. 

Chris: Hello, Gina. Hello. Hello. 

Gina: How are ya? 

Chris: Good, very good. 

Gina: I am looking forward to this episode because we got an email, we got a question. We love questions.

Chris: We love getting emails.

Gina: So please send them to us. Send me, send us your questions. 

Chris: Hello. At postlight.com. I feel like I should get a tattoo that just says hello@postlight.com. 

Gina: I got—I got that tattoo. I dunno where you’ve been. That’s on my—

Chris: [laughs]

Gina: …Well, I won’t say where it is, but… 

Chris: [laughs] you go to the beach and you just ask these people.

Gina: Exactly. I just show. I just show my forearm. 

Chris: Give us your product problems. 

Gina: Give us your product problems. We wanna talk about them. We got an email from our friend Kate. 

Chris: Mm-hmm. 

Gina: and she asked a really great question. So I wanna, I wanna read a part of the note that she sent us. 

Chris: Great.

Gina: Kate says, “Hi Chris. And Gina, I am increasingly running into an issue at work with how to account for small change items within larger product roadmaps.” so Kate is a product leader. 

Chris: Mm-hmm. 

Gina: “basically the small cleanup work that is required to keep a product functioning as you roll out bigger, bolder features…” 

Chris: Mm-hmm. 

Gina: “things like analytics clean up, smaller, like post MVP updates that were left on the cutting room floor, et cetera.” Kate’s question is, “how do you handle this? Do you keep small changes work separate from the larger big ticket items? Does this create confusion in sprint planning? Do you lump them together? If so, how does small change work ever get done, if it’s never gonna be truly, you know, a bigger priority than the next shiny features?” 

Chris: Oh yeah.

Gina: This is a big one.

Chris: Yep. 

Gina: And, “do you set aside sprint capacity solely for small? And how do you protect that resource when the shiny feature is late and it’s all hands on deck?” 

Chris: These are such good questions.

Gina: Really, really good questions. There’s always a list of…

Chris: There’s always a list!

Gina: …things.

Chris: Especially if you’ve inherited a product that has already had—You know, we talked earlier on the show about the different stages of a product’s life cycle. If you’re coming into a product or our platform that has already had months, years, sometimes decades of development, that gets put in, there’s gonna be a long list of things that hasn’t been addressed. But also, just like Kate lays out in this email, those things are not going to be the things that bubble to the top of the list.

Gina: That’s right. 

Chris: Usually they’re not the game changing new features. They’re not something that you want to introduce so that you can get a marketing impact from it. 

Gina: That’s right. 

Chris: You know, these are lower level things, and so how do you address them? This first question, “Do you keep the small changes separate from the larger big ticket items?” Is so interesting. And my gut reaction reading the note was, no, you don’t keep them separate. I don’t know if that gut reaction is correct, by the way. But. That was where my mind first went, which was you bring them together. And something that we’ve seen done really successfully in the past is you define a release where, let’s say 60 or 70% of the release is a new thing. It’s new feature development, it’s enhancement. And then 30 to 40% is those clean up items that go right along with it. And sometimes you don’t even talk about those items. 

Gina: That’s right. 

Chris: Or, they show up in release notes as “11 bugs addressed.” [laughs]

Gina: Right. 

Chris: You know? 

Gina: Right, exactly. 

Chris: And that’s as far as it goes. Or “improved performance” or “stability investments.”

Gina: Mm-hmm. 

Chris: And those things, they’re no less important. But because you know that they’re not going to speak to, you know, every, every user of the platform, you don’t have to emphasize them as much, and you can just sort of bundle them up and treat them as one big thing. One big unit of work that the team is addressing as a, as a whole.

Gina: Yeah, I mean, this makes a lot of sense to me. I mean, I think about this through the, I mean, this is a different lens, but the kind of the, the personal productivity lens, right? Like the—the big rocks and the little rocks. A pattern I’ve seen I think that lower or, or less experienced or more junior product leaders will tend to get really caught up in the little stuff and be like, “We can’t, we can’t move on until we fix this thing.” And I think that really senior product leaders, VP level, the folks who are thinking about the bigger roadmap are gonna really emphasize the big stuff. 

Chris: That’s a great point. 

Gina: Because the market is waiting, ‘cause the marketing person is banging down their door because their execs and their bosses are like, “when is—when is the new thing? When can we make noise about this? How can we address…”

Chris: Mm-hmm.

Gina: So—but I do think that there is something in the middle. Right? So to go back to, you know, the way I think about this, like from personal productivity standpoint, right? Like, so I think this is Stephen Covey who is kind of this old school..

Chris: Seven habits?

Gina: “Seven habits of highly effective people” person. Still, his stuff holds up. And so he talks about, you know, the big rocks and the small rocks. If you imagine your life as a bucket. So in this case, you know your team’s capacity, and your timeline, you know, you can fill it with sand and gravel, right? 

Chris: Mm-hmm.

Gina: And then there’s no room to put in the big rocks, right? But you should start with the big rocks. 

Chris: Right.

Gina: What are the big, new, shiny features, the things that you, you know, are really gonna have the biggest impact and are gonna, you know, Address new user needs and all those things. But when you put in those big rocks first, there’s always like a little space, you know? And then you can fit in the little rocks in that space in between.

Chris: Yes. 

Gina: And the sand and the gravel, right? And I think that’s the right way. Start with the big rocks, but then bring in the little stuff alongside it because. It’s important and you’re, you know, you’re building trust with your users. If it’s speed, if it’s stability, if it’s analytics, like there’s a, you know, return, that stuff is important to address, but it shouldn’t, I don’t think that you should bundle up and separate it. Because like Kate said, it’s just never gonna get prioritized over the—the shiny new features. So I kind of feel like there has to be, you have to work on these things in—in parallel. 

Chris: Yeah, I mean, I very much agree. Let me offer a counterpoint though, and just see how you react to it, because sometimes I think there is a way to look at some of these feature, and basically back into a business reason why it makes sense to call this thing “the big rock,” you know, or this set of things “the Big Rock.” Analytics is a great example. We had a client a few years ago who was—they wanted to expand what their platform offered. They were in the insurance space, and when they were thinking about how to expand, they wanted to look at where are the parts of the platform that are used today, and how are they used and how can. Like leverage the actual usage data to guide us on where we should go next. 

Gina: Yeah. 

Chris: Which makes total sense, but they didn’t have good data, which is very common. Right. 

Gina: Very common. Because analytics is always the last thought. 

Chris: That’s exactly right. You’re not thinking, you know, when you’re creating a—a thing from scratch, like, “oh, I gotta make sure I–” I mean, very rarely, “I gotta make sure I instrument every piece of this so I know how it’s being used.”

Gina: Yeah. 

Chris: It’s very often you’ve gotta come back and retrofit. Like, “Oh, now I see how this has come together. And so I wanna make sure that I have the right events firing and the right triggers so that we can gather,” you know, “user behavior data.” and so what our team did was they made the case that doing a—an analytics investment, it’s not front facing. You’re not gonna get any immediate, you know, marketing value or customer value out of that. But it’s a second order game because once you do start to learn about what your users are doing, you’re gonna make much more informed decisions about what comes next. And so you could actually think about an analytics cleanup as the baseline, the foundational layer that’s going to lead to something that’s really impactful in the future. 

Gina: Mm. 

Chris: So I think that’s another way you can get at this right? Path number one is, “Put the big rocks in and let the—let the littler things sort of be the sand that fills in the gaps.” Path two is “Take these smaller things and combine them together into a big rock and then figure out.” But you’ve gotta justify it. You’ve gotta figure out what is the business case and how do I say this is why I can represent to you my stakeholders that this thing that doesn’t seem like a business impacting thing actually is, and here’s why we need to go do it.

Gina: This requires very smart and savvy internal marketing, right? Cause no, no exec wants to hear, “Oh, the engineers are paying down tech debt. What does that even mean?”

Chris: You’re right. You know, you’re right.

Gina: Or “you’re just—you’re spending your time just getting more—why?” Right? Like so you really, you kind have to sell it as like, just like you said, you have to have. That business reason… 

Chris: Right. 

Gina: …you know, to, to justify it. I mean, I think any experienced product leader is gonna, or you know, any product leader really is gonna know analytics, you know, we didn’t get it perfectly before release. Analytics, getting analytics instrumented perfectly shouldn’t hold up the MVP going out to the world.

Chris: No, absolutely. 

Gina: But, Like Kate said, you know, it should be on the cutting room floor. And ideally that’s a fast follow, you know, there’s the like release and then there’s like a, you know, we talked a little bit about like a TikTok, that TikTok cadence of releases. Right? Right. We have the, the big stuff and then the—the cleanup.

Chris: The cleanup.

Gina: Right. 

Chris: And make sure that you’re, you know, your situation is solid under the hood, which is just as important. 

Gina: Yeah. I mean, in terms of, like, resource management, I think that there are times when, like, small wins can really benefit the team. You know, say if you have engineers or designers just grappling with this really complex problem and this long term project for months and months and they haven’t, like, shipped a thing in a while, it can feel nice. And I mean, I do this even just in my regular—just my to-dos throughout the day.” Let me just get a quick win.” 

Chris: Yeah. 

Gina: “Let me just reply to this email. Let me just,” you know, “knock off this quick thing.” And if you have, you know, a small ticket thing or you have a new person on the team…

Chris: mm-hmm. 

Gina: …who’s just learning the code base or learning, you know, “Hey, can you come in just tackle this one ticket?” you know, we—we’ve heard of companies that like, you know, day one, you ship code, right? 

Chris: This was a big GitHub thing, right? 

Gina: This was a big GitHub thing, right? Day one, you ship code, right? So you wanna have those really small tickets there ready for someone to pick off when they’ve got some time. I mean, the reality is, is that if you’re working on these big features, there’s gonna be a little bit of downtime, there’s gonna be some—not downtime, there’s gonna be dependencies.

Chris: Mm-hmm. 

Gina: “I’m waiting on design for this.” You know, “my brain is stuck on this thing and I need a break.” And if there’s like an easy way to pick up something and say like, “I ship something and I accomplish something today,” that’s really motivating I think, to the team who’s been, you know, heads down on something for a long time.

Chris: Yeah. 

Gina: And say like, “I ship working code. Like I, I got something done today.” You know, even though it’s small. 

Chris: Yeah. I mean, I love this point and I love the idea of building momentum. That’s, So important, especially if you haven’t had it, right. 

Gina: Yeah. 

Chris: If it has been weeks or months since you’ve had a release and you’re like, “Man, I just need to start the ball rolling.”

Gina: Yeah.

Chris: Those small things, they don’t even have to be small necessarily. They could be a little bit larger and if you chunk them out or break them down so that you can start to again, get a cadence going where you’re like, “I—it’s—it’s normal to push to production. It’s normal to, you know, get a pull request review and get, get something out there.” Those things are really important and they’re good candidates for—because maybe marketing or sales are not gonna be as interested in them. It’s a, it’s good to use those to build the muscle. I would also say, you know, something to think about for teams that are in this predicament is sequencing. Because very often when you put the big rocks in first, they take up a lot of your energy.

Gina: Yeah. And so when you’re thinking about, 

Chris: Okay, I’m planning a two week or a three week iteration, I’m gonna prioritize the big thing, right? The big tent pole feature first, and then we’re gonna fill in the rest of the gaps. Sometimes though, it can make sense to start your sprint with a few smaller things, even if you’re not shipping it. you, you know that the big thing is coming, or maybe you divide the team and say, We’ve got an architect level engineer who’s starting to lay the foundation or build the scaffolding for the big feature. And then we’ve got another person, or another two people on the team who are thinking about knocking out a few quick wins or a few smaller things, or a few, you know, tech debt items while the infrastructure is being laid. And then once it’s ready, all three people are heads down on the main feature. 

Gina: Mm-hmm. 

Chris: So thinking about how to sort of get creative with how you parcel out the work and sequence the work..

Gina: Yes. 

Chris: …so that you can maximize. How much you’re getting done, especially if you’re bundling these sort of disparate types of features into one release.

Gina: Mm-hmm. that’s really smart. 

Chris: Yeah. 

Gina: That’s a really smart approach. There’s also, we should talk about like what is, what are the consequences of not doing those little things? Like you and I have talked a lot about like systems and platforms that just get sort of new stuff added on and caked on over time. And then things get slow. One screen doesn’t line up with the other screen… Like it starts to, the whole system starts to feel…

Chris: Exactly. 

Gina: …clunky…. 

Chris: you see it.

Gina: …inconsistent. 

Chris: Mm-hmm. 

Gina: And now I’m watching seven progress bars sequentially go from one end to the other while I’m trying to off, you know…

Chris: totally.

Gina: …all that stuff. And, you know, it’s hard to, you know, as a, as a product team, I think it’s hard to say like, we really wanna avoid getting to that place, right? Because when you do get to that place, it’s like, you know, you’re gonna have your CEO or your CMO be like, “why does our app just feel like such a grind…

Chris: right.

Gina: …to use?” Or “our platform feel like—So why, why are things so slow?” You know? And it’s like, “well, we pushed too hard on building all the new stuff and just kicking it on and we didn’t go back and smooth out the edges and and do the optimizations and, you know, make sure that the whole thing kind of feels, feels good all together.” 

Chris: Right, right. You made a great point before, which speaks directly to this, which is internal marketing, and I think people earlier in their careers assume that everybody sort of sees the software effort in the same way. And so they know, or—or they think that if there’s items in the backlog, Everybody knows we just have to go tackle those items. 

Gina: They go do them.

Chris: …right? 

Gina: Yeah. 

Chris: It’s not a given, actually. You know, it’s like a car. Like a car with an internal combustion engine needs regular maintenance. So that things are working smoothly and that you don’t have bigger problems down the road. And it’s the same thing with software. You need to continually invest in these quality of life under the hood improvements because they are going to make sure that you are preventing bigger problem, user facing problems down the road. 

Gina: Mm-hmm. 

Chris: And the more that you know, if our product managers and our engineering leaders can internalize that they need to make that clear and make the case, You know, we’ve also seen situations where the business leaders get held hostage, which is not good. It’s, it’s actually one of the things that we try to work against at Postlight, right?

Gina: Yeah. Yeah. Tell, say more about that. What do you mean? 

Chris: Well, a pattern is like an engineer says, Well, we can’t do X, Y, or Z until we…

Gina: until we do these five months of refactoring the platform. 

Chris: Right. We need to clean up the database and upgrade react and blah, blah, and I’m not… Those things can be valid. But it’s, it’s with an air of like, I’m in control and you don’t get to make the calls here and it’s really unhealthy. 

Gina: It’s really bad cuz then you know what happens? This, the leaders reach out to a shop like Postlight and say, my engineering team is saying our platform is completely not scalable and we can’t do anything for five months. Like, Is my engineering team bad?

Chris: Right.

Gina: Or are they right? 

Chris: right.

Gina: Like we, we had this situation, I got called in and, and to be like, are are we doing, Like, why are we moving so slow? Or is this just bad? And, and it was like, Oh no, you actually have a very smart engineering team, but they’re not, you know, explaining to you well, or, or making it clear to you why the work that they’re doing is important for the business. 

Chris: Exactly, Exactly. It, it always needs to orient around what is the business outcome that we are driving towards? 

Gina: Business outcome. That’s right, that’s right. I mean, look, we’ve seen situations where engineering teams do get carried away and go like, Oh, like, well, we’re fixing this. Why don’t we refactor that? And, and you know, you start to, you start the work that is less impactful, but it’s just there and it’s clear in your mind that you should do it. And then a few days go by and then it’s like, what’s going on here? What are you working on? Why..? Why are you wor—I mean, this is the product leaders you know—I think one, one of the biggest jobs is, is to be able to express that. Why are we doing this? How does it connect to the business? Are we spending our energy the right way?

Chris: Exactly. People understand the concept of preventative maintenance. People understand the concept of I have to invest in. A thing to make sure that that thing has a longer life going forward. I mean, you could even think about ourselves, right? Going to the doctor and getting a checkup once a year is good preventative maintenance so that your body continues to function, right?

Gina: That’s right. 

Chris: For as long as it could in an optimal way. And when we’re thinking about a software effort, it’s the same thing. I think it is incumbent upon the team’s leadership to make that clear. And you can call it whatever you want. You can call it internal marketing. You can call it clear road mapping. You can call it future planning and future presentations of, of what’s coming up. And we’ve seen lots of different tools and approaches for this. And we have a few that we like, but there are, you know, there’s a lot of ways to do this effectively, but you have to do it. You can’t just assume that all things naturally sort of fall into place, you know. You have to make sure that you are proactively setting people’s expectations and making clear why you need space for these kinds of smaller cleanup type things.

Gina: Yeah, I mean, The difference between, I’m gonna go have a couple of doctor’s appointments the next couple of months versus like, I’m gonna go to a wellness retreat for, for four months and this is a bad, I’m really stretching this metaphor here, but like the legacy..

Chris: I see where you’re going. 

Gina: We can’t move forward. Our platform is in such a state that we can’t move forward until we refactor the database and we rewrite this whole piece of the, of the middleware because in a faster language, because we really can’t go and—you know, that hold—holding leaders hostage to be like, we need, you know, three months of heads down time to do these invisible upgrades. That’s a bad scene. 

Chris: That’s a bad scene.

Gina: It’s a really bad scene. Because look, the leaders at your company, there’s a clock ticket in their heads.

Chris: Always. 

Gina: Their competitors are beating them out. They’re losing users. You know, the more time and—there’s—you know, you’re paying salaries and days are ticking by and that you feel it, you feel like, you know, invisible progress is, feels like no progress. Right?

Chris: Right. 

Gina: But a lot of this work is invisible right? So that’s why, that’s why I’m, I’m sort of, you know—Kate, I don’t feel like I have the, the exact right answer, but I’m definitely leaning toward the do it alongside the big rocks, right?

Chris: Yeah. 

Gina: Like that, the two work streams of the, the small stuff alongside the big stuff versus like bundling up all the small stuff. Although again, maybe once in a while for one sprint, it’s worth saying we’re just gonna burn through this part of the backlog that is..

Chris: And here’s why.

Gina: …and here’s why. 

Chris: Yeah.

Gina: And here’s why. 

Chris: I mean, there there’s one more sort of question that we should come back to, which is how do you protect that resource when said shiny feature is late and it’s all hands on deck? And this is a great question. Because sometimes you have to change a plan. 

Gina: Yes. 

Chris: And you have to say, actually…

Gina: “this is a higher priority right now.” 

Chris: Exactly. Yeah. The big shiny feature is more important. 

Gina: Is more important. 

Chris: And I’ve been in these shoes as a product manager, and it sucks because you’re like, I know that we needed to clean up these six things, and the fact that they’re getting pushed…

Gina: “set these people off on that journey…

Chris: yes. 

Gina: And now I have to say to them, ‘Actually, stop.'” 

Chris: Right. 

Gina: “Come back, do this. You know, stream, work stream.” 

Chris: Right. 

Gina: Very disruptive. Very annoying for them. You know, like it’s..

Chris: But!

Gina: …sometimes you gotta do it. 

Chris: Exactly. Like, that’s my, my, you know, as I read this now, from the seat we’re in at the moment, it’s like most of the time it’s gonna be the right call to prioritize the front facing thing and say, this is the thing we’ve gotta get done, and we have to figure out a new plan to address the smaller…

Gina: the other things. 

Chris: The other things, right? 

Gina: I mean, look, they’re gonna show themselves, right? If you can put it off and there’s another bigger priority, right? Like this is prioritization, like then, then you probably should.

Chris: That’s right. 

Gina: If you’re in, if you’re in that state with the big feature being, being late, which is a terrible state to be.

Chris: Yeah. 

Gina: Also, you should ask yourself whether or not adding another engineer is really gonna fix the problem. But that’s maybe a different, different conversation. Like, does, does more bodies, you know..

Chris: All hands on deck? I mean, that’s, that’s very true. . 

Gina: Yeah. 

Chris: These are the tough challenges of product management.

Gina: Yes. 

Chris: Like figuring out how to best use your resources on a, like sprint to sprint or day to day level. Like it’s challenging. The best functioning teams are really good at sort of like addressing that and shifting on the fly when they need to. But it’s hard and it takes work. And you know, something we’ve realized through trial and error is you’ve gotta make sure that the team has a chance in the very beginning when they start working together to really understand how this process happens. Right? We’re not big believers in like, you must do strict Scrum or something like that, right? But you do have to understand how are we allocating work and how are we responding when things change? Because that is a fact. Things will change. And so making sure teams know how to course correct and adjust and hand things off, because you’re totally right. Maybe pulling an extra two engineers onto the big feature is not gonna help, right? And so letting them continue on the path to clean up the smaller things is actually fine and the right allocation of resources. 

Gina: Yep. 

Chris: But unless your team really understands how they’re doing the work together, it’s gonna be hard to make that call.

Gina: Well, this is a great question for Kate. There is no real right answer. This is a, a, you know, a kind of thing that you get better at kind of over time. 

Chris: Mm-hmm. 

Gina: And these are, these, like you said, are the tough problems of leading a team. If you have questions about prioritization or road mapping or figuring out how to, you know, explain what you’re working on internally and externally and get that, that good cadence of, of shiny new features, but also maintenance support. We’d love to hear from you. Reach out to us. 

Chris: Absolutely.

Gina: send us a note at hello@postlight.com and, I mean, we love this stuff. 

Chris: This is great. Thanks Gina. 

Gina: Thanks Chris. Bye.

[MUSIC OUTRO]