Transcript

Chris: God, even, even just hearing you describe that hypothetical example before made me exhale. I was like, ‘oh, I get it.’ Which is like, kind of crazy, but that was my instinctual response.

[intro music begins]

Chris: Good afternoon, Gina. 

Gina: Hey Chris,

Chris: It’s another episode of the Postlight podcast. 

Gina: I know. And we get to talk about product. I love talking about product with you. I really enjoy it. 

Chris: We’re a product company. We can talk about product endlessly. 

 Gina: We can’t stop talking about product. It’s all – That’s what it’s all about.

 Chris: That’s what it’s all about. You know, it’s very intentional that we call our designers ‘product designers.’ 

 Gina: Yes. 

 Chris: And we call our, you know, the people who lead projects are ‘product managers’. And that’s because everybody, you know, they have a product mindset. But it’s not necessarily standard in our industry. Right? A lot of people, if you say the word PM. 

 Gina: Yeah. The acronym. 

 Chris: The acronym. What they think of is ‘project’ manager and they think of, you know, how someone moves a project along, not a ‘product’ manager. 

 Gina: Yeah. We, we often get asked by our clients like, ‘so who’s the project manager?’ And we’re like, we don’t have that actually at Postlight. We don’t have project managers, not pure project managers. And it’s confusing in some context. 

 Chris: We expect that our product managers do project management. And in fact, some of our designers and engineers also do project management, if you wanna think of it that way in their sphere. It’s very common for us to have a lead engineer who’s overseeing planning out engineering work, and a lead designer in the weeds doing design planning, which is sort of like project management.

 Gina: Mm-hmm. 

 Chris: But it’s very intentional that we have ‘product’ in the title because we want everybody on the team to be unified around, ‘Okay. What are we actually building? And what is the user experience that we are enabling here?’ Whereas very often project managers are not thinking about, they’re not thinking about the thing. I mean the best ones do because they can’t help themselves. But the role, the, you know, the role of a project manager, in the pure sense, is ‘how do I make sure that things are on time, regardless of what the thing actually is,’ right? If you’re, if you’re a construction project manager, you’re not thinking about the quality of the building you are thinking about, ‘how do I make sure that the walls get erected on time? And how do I make sure that my plumber shows up when the plumbers is due to do the work?’ Which is pretty different actually from thinking about being committed to what’s getting delivered. What’s getting in the hands of real people. 

 Gina: It’s managing against deadlines. It’s managing resources. It’s following up on details. I mean, project management, it’s an important job. It’s a hard job, but it’s, it’s moving the project forward. The project has been determined and you are moving it forward to an end. Right. Whereas a product manager is thinking about why are we building the things that we’re building and should this task beyond the list, you know, instead of just can this task get done by this time? I mean, the tricky thing about a product manager is that you, like you said, you have to be a little bit of a project manager, but that product manager is thinking why and how, and how does this fit into the bigger picture of what the product is and is gonna be. And, you know, I think when things on the ground change, when, you know, when the dry well doesn’t show up or, you know, the plumber’s out sick, right. The project manager figures out how to work around that. Right. But the product manager is like, ‘Okay, how do we adjust to meet user needs? How do we adjust the whole roadmap to, to meet, you know, that MVP or that release? Like the spirit and this, the purpose of the release? How do we get there given the, the change on the ground?’ And it’s a subtle, but very important difference in the way that you’re thinking about doing the thing. 

 Chris: It’s actually not that subtle. I think you said it beautifully, it’s such an important point. A project manager is just thinking about the schedule more or less, and that it’s a critical job, actually. It’s a very important job and the best project managers are worth their weight in gold because they make sure that everything lines up. And it sounds straightforward, but it is absolutely not because a million and a half things come up, especially when you will reach, you know, projects of a certain scale or certain complexity. It is very difficult actually to line up all of the different tracks of work that you have going on. Whether it’s a software project, a construction project, uh, you know, you name it. They all have a similar set of challenges. But you’re absolutely right. That a product manager brings that Y element, which means that their ability to react to things is broader because they can then say we’re actually going to move the goal post a little bit, because we want to adjust the actual thing that we are making based on whatever is catalyzing the change. Some new bit of information, some blocker that has come up. And the best product managers are not just thinking about the schedule they are also thinking about, ‘Okay, I have a new set of constraints or a new set of inputs that I have to deal with. How can I make sure that we are still producing something of great quality and that’s gonna make a great experience for the people who are using the product. But also fit within the new information that I have on the ground? 

 Gina: This really ties back to the difference, I think, between a backlog and a, and a roadmap. Rich wrote this great piece on, on postlight.com about backlog driven development, right? Is that you’ve got this list of task in the backlog, customers ask for a thing, you know, stakeholder wants a thing, or like a feature request and bug reports, and it kind of gets stacked up in the backlog. And I think this happens, like I thought, you know, a large amount of product thinking is, is needed in the beginning when you’re defining a platform. But at some point when you sort of shift into execution, there is a, you know, there’s a good amount of project management. And then when you’re taking things off the backlog and making sure that they get done, it’s easy to shift into that project manager mode, right, where I’ve gotta list tasks and I’ve gotta allocate resources and I’ve gotta set deadlines and then I’ve gotta see them through. But the backlog is not the roadmap or shouldn’t be anyway. You’ve led the product group at Postlight for many years. And your background is in product. Like, how do you differentiate? How do you true up what’s in the backlog and what’s on the roadmap? And, and when do you say, okay, we’re not actually gonna do this thing in the backlog, or we’re gonna reframe this thing in the backlog. And when do you say this needs a shift? It needs a shift in the roadmap. Let’s, let’s draw out this roadmap and work back from that. 

 Chris: When do you say it? I think each team has to figure out the cadence. That makes sense for them. I have worked on teams where there’s a quarterly road mapping session. I’ve worked on teams where it’s every two weeks, you’re looking at the roadmap and I’m very purposely distinguishing roadmap and like backlog grooming. Just take a brief aside for a second here. If we take our software hats off for a minute. If you hear the word backlog, what do you think? 

 Gina: I think we’re, we’re behind. It’s, I feel like, you know, it’s a list of things that we were supposed to get done, but didn’t get done and that we have to get done. Like… 

 Chris: Exactly!

 Gina: I feel like I’m behind and I have to run really fast and catch up. Like I have to clear the backlog. I feel that’s just because of that, that term. 

 Chris: I think that’s what most people feel. It’s like, ‘oh, there’s been, I’m behind, there’s a traffic jam. I got like a bunch of stuff that I was supposed to do and I didn’t do. And now I’ve gotta. Figure out how to get them done as quickly as possible.’ 

 Gina: Yes.

 Chris: It sets a tone for a team that is almost opposite of how do we fully consider what’s going to make this product better that we’re working on. 

 Gina: Right! 

 Chris: Because you’re playing catch up against… And I, Gina, we have gone into clients that have backlogs that are literally thousands of tickets languishing in Jira …three, four, five years old that no one has looked at. There’s a point where you’re like, ‘this is not valuable anymore.’ Like, yes, there’s some valuable stuff in here, but when do we declare bankruptcy and look ahead because the backlog is not serving us. And when you have a team that is just thinking about slogging through these things, because they’re just they’re tickets.

 Gina: These are the marching orders, gonna just do the marching orders. Yeah. 

 Chris: That is not the environment where you, where you do your best work. Maybe there are some environments where, you know, it’s important to make sure that we are accounting for every little thing and, and backlogs could maybe be valuable there. But when you are working on a product, especially an early stage product or a platform, being myopic, when it comes to just a list of things that you are checking off, the list is not helpful. This is another distinguishing factor to bring it back to roadmap versus backlog. Roadmap implies a level of critical thinking that backlog does not. And the best teams as they’re looking ahead, they are thinking critically about what informs the roadmap. How do I look ahead for the next two, three, four quarters in some cases, the next two, three, four years of this software product that we are working on and how are we making good decisions about what makes it in and when then going on and executing on those things. The best roadmaps are also fluid, they change. They allow for new information or new factors to inform what they’re doing. And again, that’s why product managers are so critical because they can be the interpretation layer to say, ‘oh, here’s what we’re hearing. And here’s how that’s going to inform what we ultimately go do.’ Backlogs do not have, they don’t have the same connotation. They feel like they are fixed. The tickets are written. And so we are gonna go do the thing and if, if you have a new piece of information or a new, you know, uh, learning from analytics, you write a ticket about it. As opposed to let’s talk about this as a team and figure out how this affects what we’re, what we’re gonna go do.

 Gina: Definitely. I mean, I think a very, a very common scenario is, you know, you’ve got a platform and maybe it’s a white label platform where you’re onboarding large customers and you have, you have feature requests coming in from customers. Right. And so I’ve heard, I, I have friends, you know, who work in product to be like, ‘you know what? Customer makes a, makes a request. And now all of a sudden we have to build that because it’s just a big customer and they’re paying customer and, and that the exec wants it to happen. So, you know, we, we’re not thinking about product at all. We’re just responding to whatever, whatever our clients want.’ And that’s not the way, you know, you really build product. And it’s true, they’re right. It’s not the way to really build product. I mean, you have to take that request, but you have to look at it, instead of just putting it, you know, on the board for that week and pushing everything else down, you have to look at it and say, ‘what does this represent? How does it fit into the vision of the platform or, or what we’re trying, what problems we’re trying to solve the rest of the platform? Is the thing that they’re asking for, like, the right way to solve the problem that they’re having? 

 Chris: Yes. 

 Gina: Like differentiating between the suggested solution. And what’s actually the issue at hand. You can really see those, like globed ons, ‘somebody- asked- for- this- feature’ and they just need to ship it really quickly. But like, didn’t think about how it like fit in or integrated with the rest of the app or platform. You can see it. If you go into the settings of, of any very mature app, like you should see those, those check boxes and those slide and you’re just like ‘somebody asked for this at some point and no one else cared and no one uses it. and it just adds this whole other surface area for confusion, user confusion, and errors to happen.’ Uh, you can see it. 

 Chris: My favorite thing is when you go into like preferences and you see integrations to platforms that no longer exist. And you’re like, oh, yes. Yeah. 

 Gina: That was a, that was a thing that happened at some point.

 Chris: That was, that was a little historical artifact that got left in. 

 Gina: That was a business partnership, right, right, that, that fell off the radar. And literally no one goes in here and cleans these out. It’s true. It’s true.

 Chris: I, I wanna highlight something you said, which, which was so good, which is that when you get a new customer input, customer request, customer feedback, whatever. You have to ask yourself the question, ‘how does this fit in?’ Or I guess maybe ‘why’ is another way to say it? ‘Why does this fit in?’ And parcel out where’s the problem in this request and is this the right solution to that problem? Which you, you said so well., Better than me, before. And I think something that we try to do in all of our work at Postlight something, our design team is especially good at, our PMs are great at it, but our design team is especially good at, is getting down to the root question or, or the root problem, and then figuring out how to solve that root problem rather than how to address the customer request. Because I think if you’re a project manager and you’re, and you’re responsible for dealing with customer inbound, your response, completely understandably, is gonna be, I’m gonna file a ticket for every single customer inbound that we get. And the tickets become sort of defacto a set of work for the engineering team, which is completely backwards. You’re catering to the whims of what is being put in front of you without any assessment, any evaluation of what’s being requested here. And the best product teams and the best design teams do that work. They do the work to say, what is really being asked, what is the core problem? How do we solve that core problem? And then if it’s valid, how does it fit in? If it aligns with the vision, how does it fit in? And, and where do we wanna, where do we wanna do it? Like, how do we wanna address it? And that that’s where it comes back to road mapping. And that’s where sometimes you will have a customer problem that really resonates with the core vision of the product and it trumps a lot of other things that were in your roadmap. And you say, ‘we actually wanna ship this next quarter or this quarter, because it’s that important.’ Those things are really, can be really valuable and really impactful. And then other times you’re like, ‘actually the core problem here, it can be better addressed in a different way, and we’re gonna address it in a point release in Q4.’ and that’s totally, that’s totally valuable too. That’s the kind of thinking that you get from a good product manager, a good product team, a good design team that you won’t get if you’re just thinking about it as a pure project. 

 Gina: Absolutely. The thing is, I think that when you have a mature platform, particularly a platform that’s released and it’s out there and it’s being used. I, I think that what we see in our clients, what we see at orgs is that the product thinking starts to fall away and default to project thinking, to project management. Right. And then, you know, the, the platform sort of, you know, trucks along there for a while, but then, you know, you start to feel some of the friction and it starts to feel ‘okay, like maybe there’s another one out in the market that’s a little better. Oh, that looks a lot more modern.’ But you got project thinking, you’ve got project managers taking care of this thing. So often we’ll have clients come to us and say, ‘we need to shift our thinking.’ Like, like the really self-aware clients will be like, we need to become a more product lead org.. Like we’re not a product-lead org. 

 Chris: You’re right. 

 Gina: We’re just doing the tickets and, you know, but when we look around, like we’re getting our lunch eat, we can see that there’s so many other better. We haven’t kept up with like some of the, the best, you know, products out there because we don’t have that person who is A, doing the critical thinking or, B, has the, has the political clout and the power inside the org to say, you know, ‘I’m thinking about this. And I don’t actually think that we should work on this. Like does it doesn’t fit into our bigger vision. Let’s stay true to our vision or let’s simplify. Let’s sunset features that aren’t being used. Let’s remove complexity, right?’ Like that never happens. 

 Chris: But it’s critical. It so important. 

 Gina: It just sort of kicks on. Yeah. Yeah. How do you start to instill product thinking into an org that has, sort of, fallen into the project mode? I think it’s a tough thing, but it is a really a reorientation. 

 Chris: I think step one is to look at what you’re doing today. You’re right. That a lot of the orgs we talk to that are working on established mature platforms, it’s very easy to fall into this pattern. And so step one is like recognizing it. And what is it saying? Like the first step is admitting that you have a problem. Like you, you know, you need to be helpful. It is so great, but rare when a client comes to us, our prospect comes to us and says, we, we, you know, we’re not product led today. And we wanna be product led, I think step one. And I would encourage everyone. Listening is like, do a little self evaluation and say, are, are we making thoughtful product led decisions or are we just, you know, keep on keeping on, in the direction that we’re going, because… that’s step one. You’ve gotta give some autonomy to your team. You’ve gotta let them be empowered to make some of these decisions and to push back on some things and to say, ‘we’re not just gonna work on the hundreds of tickets that are in the backlog. We’re gonna put the backlog to the side for a second, or maybe there’s a maintenance and support track that is doing the critical items, uh, that are being reported. And there’s a separate track that is thinking about future looking.’ I would also say, you’ve gotta expand your time horizon a little bit here. You have to be thinking about quarters or halfs of the year, halfs of the year, as opposed to what are we getting done this sprint quote unquote. Or this month. Because it’s harder to make these broader strategic product led decisions when you are thinking about very short term. There’s only so much you can change, especially on a big platform, in a two week sprint or a three week sprint. You’ve gotta lengthen out a little bit. Last thing I would say is design is your friend here. Design can help because if you have a designer set aside some of their time, maybe all of their time, to making concept designs to sitting with your product manager and letting design help, not in a theoretical way, but in a very tangible, real way, draw out what the future could be. And these concept designs don’t have to be high fidelity pixel- perfect mockups. They can be wire framing, directional type things, but it’ll help get everybody on the same page and have a shared understanding what’s ahead and how can we then start to boil that down into a roadmap. Design is, is critical. As you are thinking about being, even if you don’t have anyone with the title, ‘product manager,’ thinking about how designers can play the role of ‘product thinker’ is really important, especially if you’re trying to change in already established culture, where you’re just working through the backlog.

 Gina: Absolutely. I mean, right. Defining that, that north star, that vision, and then starting from scratch. I mean, here’s the thing, like if, if you’ve got an established platform and you’re doing a lot of project thinking and you realize that that’s not working for you, you have to consider it’s like some, you know, what seemed like extreme measures, like maybe backlog bankruptcy, or like you said, doing that support and maintenance track. I mean, some of our clients, they’re just like, we’re gonna start something green field. We’re not even gonna try to have the same team that’s been working on the same platform, just keep going on the legacy. Like let’s just start with a blank sheet of paper. Yeah. You know, doing a concept design or, or design sprint, even if it’s not something that you wind up building. Just to sort of boil down, ‘what would this look like if we, it’s today 2022, we know what this platform’s supposed to do and and what the, what the you know, strategy is here and what are the key things that we would include’ um, is, is a worthwhile exercise. Cause because you can either decide, okay, we’re gonna start green field, start over and build a whole new thing. Or it can make you go look back at the existing platform and say, we’re gonna strip a bunch of stuff away or, or reimagine how, how it all works together.

 Chris: Right? Or, we really wanna focus on this one area that we discovered was, was really critical and underserved in the current platform, you know, the current iteration of something. 

 Gina: That’s right. That’s right. You know, it’s definitely a, a switch between that sort of like that strategic thinking and, and execution side. And you have to have a good, a good balance of both. But the, that the execution always sort of has to be led by the strategy. And I think that that’s tough in every, not just building product and running a business as you and you, and I know very well and, and anything it’s, it’s tough to switch those, switch context, but it’s absolutely key because after a while, if you’re just pushing task forward, but you don’t have that “why” crystal clear, you know, it’s not gonna be, you know, what, what it should be and what it can be. 

 Chris: You’re a thousand percent right. Here’s another one. There was a great Twitter thread that we were talking about the other day that called out the idea, as you move from project thinking to product thinking, ‘why’ is so critical. And another point that this Twitter thread made was move from, ‘how will we do it’ to, ‘how will we differentiate?’ What is differentiated? What sets us apart? That is so great because so many, I mean, we see it all the time. These big established platforms with these big established companies, I am personally partial to healthcare. I feel like there needs to be disruption in healthcare, but we that’s. We can talk about that in another episode. But so, so many of these companies just look at how, how are we gonna accomplish what’s directly in front of us. Even if there’s not a backlog, there’s a list of features that we know we want because the CEO decided, or because we heard from customer focus groups or we’ve gotten, you know, a bunch of emails to support@blah, blah, blah.com. And they’ve all said, we wanna do this thing. And so the, the work of the project manager or the project lead is how are we gonna get all this stuff done? And instead, a product person, a product thinker is going to say, ‘It’s not just, how will we get this done? How are we gonna differentiate? How do we go back to this list?’ And again, we’re saying it a lot, but think critically about the list and what are the things that we actually wanna focus on that are gonna set us apart? How will we differentiate? And those are the things that could really make a two, three, five X impact, as opposed to just taking on a bunch of features. And it’s it’s easy for you and I to say to each other, but I think it is hard. for people to do, especially when they’re in a context that has not prioritized that kind of thinking. 

 Gina: Yeah. This twitter thought is so great. It’s by Shreyas Doshi, he posted it in, in December of 21. It is, it is stuck in my brain since then. I, I bookmarked it and I’ve gone back to it a few different times. And, uh, and what, we will definitely link it in the show notes. What I really liked, he goes. Through a couple of examples of like, when you can see and hear project thinking versus product thinking. So if, you know, if you, and you know, we experience this a lot, well, you’ll be like, ‘you know, can we do X?’ and, and the project thinker is like, ‘well, we can’t because everybody else is allocated to Y and you know, that won’t be able to happen for another six weeks and we need to get, you know, another other.’ And it’s like, ‘no, no, no, but we need to do X.’ And it’s like, ‘Well, we can’t because,’ and it becomes about resources and deadlines and whether or not we have the time to do it. Where often what, you know, particularly high level stakeholders asking, ‘why aren’t we doing this because it’s so key to our strategy and our mission. Like it doesn’t, it doesn’t make sense that this thing,’ the implication is like that, you know, ‘it doesn’t make sense that this thing that we’re not doing isn’t higher priority because, you know, in my mind, it’s so aligned with our overarching strategy.’ And those conversations are so important because they, they clarify the overarching strategy or at least they align, you know, the, the project manager or the product manager with the stakeholders idea. Like it, like, if it isn’t clear, then like that’s a conversation that has to happen. Like, and it all has to go back to that, that strategy. Like priorities should be by, by the strategy. And that alignment is just so critical for everyone to be pulling in the same direction. 

 Chris: It’s absolutely critical. The best product managers will do this instinctually. They will drive teams towards alignment. And alignment with the north star mission and vision. Alignment with the leadership of their group or their company. It feels really good. And you’re like, wow, this project is really like humming along. This is great. We’re working on the right things what’s going on. And it is because of exactly the alignment that you’re describing that a good product person is going to constantly push for, constantly push the team. And sometimes that has real impacts to the schedule that was previously established or, you know, the roadmap that was previously written down or whatever it is. But that’s okay. It won’t feel like friction because when, when things are lined up like that, it just goes. 

 Gina: Right. What feels like friction is Fran, the CMO, you know, the chief marketing officer dropped in and said that she needs this page. So we don’t need to stop what we’re doing and make this page. Right. That feels like friction. But what doesn’t feel like friction is, this page is gonna explain to our users like the value of this thing. 

 Chris: Exactly. 

 Gina: And it’s gonna make so much better experience for them. And it’s, you know, we’re looking to increase our onboarding by 10%. Like let’s do this team that feels like, oh, I’ve got a mission and a vision like tho those are two different things. And I think that, that, that product thinker is able to translate the user request or the stakeholder request or the bug report and say like, ‘this is why this is so critical to what this product is trying to do’ versus ‘the customer, you know, an important customer, it made this request. And of course we just do whatever, the customer’s always right. and we just do it,’ you know! Which I think, I think sometimes can happen when you’ve got an intake from clients. And that just gets, you know, popped onto the backlog, right. And then, you know, prioritizing that week’s sprint. And it’s just sort of like, okay, I guess we’re just gonna be on this treadmill of customer requests forever. 

 Chris: This is what we’re doing now.

 Gina: This is what we’re doing now. And yeah, this is what we’re doing now. 

 Chris: You know, hopefully what people take away from this is they’re listening is we should be moving in that direction. Project management, good project management is critical. Good project management means, you know, people feel like they understand what’s happening at any given moment and that, and that is just as necessary for a good project. So, uh, hopefully point here is not misconstrued as like project management is bad. The ‘when’ and the ‘who’s doing what’ and ‘how does it all line up’ and making sure, like that is critical. Also brief aside, good project managers are also great communicators. And if there’s anything that we’ve learned in our business, client services lives and dies by good communication. And that you don’t need to be a great product thinker to be a great communicator. And I have seen good project managers at our clients that may not be great at product strategy, but they are excellent at communication. And that is tremendously valuable. So project management is so important, but if you’re thinking about a software product, really all software products, but certainly a big one, like a big software platform, like the ones that we like to work on, you’ve gotta have an element of this product thinking that is guiding your team and connecting the dots between where you’re going, why you’re doing it, what’s what your vision is, and then what’s ultimately in front of the team. And I, you know, again, your, your example before. Illustrated it beautifully, ’cause I just, I relaxed when it was like, oh, okay. We all get it. You know, uh, I want that for every, for every, every team.

 Gina: And yeah, and I wanna echo, echo what you just said. Sometimes you need to get stuff done in a great project manner and absolute God, godsend like, absolutely. Um, but that, that bigger thinking and, you know, the reverse thing can happen where, you know, there are times when you just need to get a thing done and you’ll be like, Hey, can we just, can we get this thing done? And the person’s like, well, let’s talk about why, let’s talk about the big picture. And you’re like, no, I don’t talk about the big picture. We just need to get the thing done, like, like that, that also can happen. But I think it’s, it’s, it’s good to identify. Like when are we doing the big picture? Why, how that product thinking product thinking versus project management, like what needs to get done in order to get this thing across the line because this task has to get done, you know. 

Chris: Defining the ‘why’ doesn’t always have to be like a big, you know, half day offsite where you’re having a big discussion. 

Gina: Right. 

Chris: Sometimes defining the why is a simple question and answer. Sometimes it’s implicit. Like once you get to a point where you’ve got a product team and a product manager who have internalized where the mission is, these things start to happen organically like almost, or automatically exactly. Mm-hmm like you don’t have to constantly be going back to first principles because you’ve already established a shorthand about how the mission is going to implicitly decide, you know, whether something gets in or out or whether something needs further consideration or it should automatically make it on the list or should automatically be disqualified. Like this, it starts to happen. If I can talk up our MTA team for a minute, the team that’s working on the platform that we built for the transit authority that runs the subways and buses here in the city. Like they have gotten to this place where they are in close communication with our stakeholders and they get the mission so intrinsically that when something comes up from a user it’s, it’s pretty clear where it’s gonna slot in before a conversation has even happened or has even been had. 

 Gina: Yes. 

 Chris: I would throw that out there just to say like, there’s, there’s a way where this actually gets pretty easy. It, it can seem very daunting when you’re working in a project led organization where you’re like, how am I ever gonna turn the tide here? But there is a very, you know, well functioning, efficient future if you commit to it and give your team the resources to get there. 

 Gina: When everyone internalizes the mission, there is, there is a, a momentum that happens and it goes, you don’t have to assign task anymore. People understand, oh, this makes sense that this is what we’re doing. We’re excited about getting this done cause it gets us closer to the mission. It’s the internalizing mission. 

 Chris: That’s the hard part. 

[outro music begins]

 Gina: That’s, that’s, that’s the hard part. And right, and so there’s that work of alignment. There’s that work of, of thinking about it that way and talking and framing the tasks, you know, as client requests, you know, versus like this is gonna make things better for the user. It’s important. It’s I think it’s more important than ever to make great software. This. To think about great software this way, versus just as like, I, I got all these tickets in Jira and I’ve gotta, I gotta mark them as done. I mean, it’s a big shift, but it’s some of our favorite work to do, honestly, with some of our clients. Yeah. Especially clients I’ve recognized, like this is the direction we have to, we have to become more of a product led org in order to compete and reach our business goals. Like. That’s the great work. 

 Chris: That’s the great work, Gina. If somebody is listening to this and they’re like, I think I might fall into that bucket. Like I would love to talk to somebody about how I can move my org towards more product. What should they do? 

 Gina: Chris? I’m so glad that you asked, they should send us a note at hello@postlight.com. We’d love to hear from our listeners. We read every single message that comes through and we love to chat. Um, we love this stuff. It’s what we do. Hello@ postlight.com. Get in touch. 

 Chris: Thanks for chatting. 

 Gina: Thanks Chris.

[outro music takes over & fades out]