Transcript

Paul Ford There in the Steve Jobs book, there’s a moment where he’s getting a liver transplant and he wakes up and he yells about the interfaces on the different medical devices. [Rich laughs] Right? Like he wants to get those replaced. Cause it’s just like to his brain, he’s like this and we have to solve this right now. [music fades in, plays alone for 15 seconds, ramps down]

Rich Ziade So Paul, we got an email a week ago from one of our partners at Postlight.

PF And it was an email, not a Slack message. So that’s how you knew it was going to be serious.

RZ Yeah. It was a topics suggestion for podcast topics. And I don’t know if anyone really knows how incredibly thirsty we are to ideas at this point. [Rich & Paul laugh]

PF So let’s be clear here. One of our managing partners and also one of the people who founded the firm with us, Chris LoSacco, someone who’s worked with you for probably three or 400 years now.

RZ It’s been a very long time, almost 15 years, right? Over 15 years.

PF Chris is one of the most, it’s almost like if product management was something that you could identify in a child. I think you’d identify Chris as a product manager. There’s a very specific reason why, which is that a lot of times what we’ve seen, we’ve seen this pattern. People go, what does he do? What does he do? I don’t understand. He’s not a programmer. He’s not a designer. What does he do? And then they watch him interact with the client and look at some work and go, absolutely no way and make about 25 decisions in about an hour. And they go, Oh, that’s what he does.

RZ So Chris wrote us, Chris LoSacco is on, on the podcast as we speak, as we talk about him. Hi Chris, how are you? 

Chris LoSacco Hello! Hi, I’m good. How are you guys? 

RZ Good, good, good. And you sent us this note and you, you, you titled it beautifully and we, you titled it so well that we’re going to break this up into a few podcasts and it’s the six mistakes you’re probably making with your product, which, you know, I don’t, I’m not an SEO expert, but that’s pretty juicy right there as far as I’m concerned.

02:06 

CL That was not my intention, but I’m glad. No, I mean, and, and, and actually, you know, Chris was like, let’s come on and talk, talk about these and Rich and I immediately went like, this is multiple podcasts. So we’re going to, we’re going to use this as an opportunity to really frame how we do product at Postlight and talk about those mistakes. Because if anyone has seen it lived them, it’s Chris LoSacco. I mean, it’s actually worth letting people know what product at Postlight is not like you own a product or you in a part of product? Like your job is different from a product manager at a lot of large orgs. So maybe talk about that for a second and let people know what you do. 

CL Yeah, sure. I mean, we are a client services company, right? So we help companies across a number of different industries, all shapes and sizes. We’ve got some projects that are targeted efforts. We’ve got longer ones that are strategic partnerships. And my role is to be hands on some of them and also to help oversee and make sure that the quality of what’s going out is excellent and that we are doing what we said we would do for our clients and making sure that we are achieving the goals that they laid out for us when we first joined.

PF How long did typical relationships last?

CL Uh, man, it’s hard to say there’s, you know, there’s kind of a sweet spot, maybe around the six to nine month range, but we’ve got some shorter, more focused efforts and some multi-year engagements, so it can really span, span the gamut. But I think, you know, we endeavor to ship, um, and we like to ship early and often. So I would say in the first, you know, four to six months of an engagement, even if it’s longer term, we’re going to show value.

PF So we thought today, we would talk about, you sent us the six mistakes that people are making. And we thought today we would talk about the first two, which I’m going to, I’m going to read and then throw it back to you and Rich to really kind of dig into them. So the first one is being vague about your timeline and commitment. And the second one I think is pretty connected, which is waiting too long to ship. Right. So those, those two live together.

04:12 

RZ So the mistake is being vague about your timeline commitments, Chris?

CL Yes. Correct.

RZ Okay. Explain.

CL So yeah, it’s interesting that you asked the question Rich, because it almost seems like it could be a benefit to not have a clear timeline or clear commitments because it’s kind of tempting to think that it means flexibility [sure] that you can include anything.

PF And there was like a whole movement with engineers about five or six years ago, or, but he was like, deadlines are no longer effective. [right] They don’t have anything to do with engineering.

CL Right. But I think what many product teams miss is that ambiguity makes it hard to plan and it doesn’t just make it hard to plan internally within the team. It also makes it hard to plan around the org. There are a number of different sort of stakeholders at a company that are waiting for the output of the product team, right? There’s sales, marketing, editorial, customer support. They all need to be oriented around where they’re structuring their teams and making sure that their priorities are right. And the more play there is in what’s coming up, the harder it is for those groups to say, okay, I know where the product is going. And so I can make sure that my team is set up to do what they need to do.

PF Let’s take it from the other direction for a minute though, which is too many timelines, too many, uh, deadlines is also kind of fatal, right. I’ve seen a lot of PMs who come in and go, okay, well, why can’t I just have it in an hour? Like as a thought exercise, right? And then they’re like, well, what about two weeks? And they sort of put that time pressure on because they feel that otherwise things will spin out of control and they want to get something shipped. So I understand that motivation really well, except that then that also can create a death march environment really quickly. So how do you find that balance? Like, I mean, we’re back to estimation. What are, what do you do to give a good date to a project?

06:08 

CL I mean, a couple of things. I think you want to work with leadership in design and engineering to put rough timelines around things as opposed to specific timelines. I think it can be a natural instinct for PMs to say, I’m going to come in, product managers, to come in and say, I want this on this week and this on this week. And I agree like with what, you’re the point you’re making Paul that it’s like too specific, too deadline driven. I think you want to have a plan. You want to have rough goals. You want to have high level estimates and then allow for additional things to come in or things to change as you move ahead on that, on that timeline. But the important thing I think is to put some stake in the ground to put some goal line out that the team feels oriented around and that the rest of the org can look at as well.

RZ I think it’s worth, worth highlighting. You’re not just talking about the final goal line. [no!] You’re talking about wins along the way. 

CL That’s right.

PF I mean, we should, we should be talking as we’re talking about the mistakes, probably let, let’s talk about a product, right? Like what are we, what are we going to ship here that, and all the mistakes that get made could be a new app for a media company could be a new financial technology app. So I don’t know something that lets me trade stocks, which is something we’ve never built on mobile. Right. So, you know, I mean, here’s the first thing that always happens in my experience. If somebody, especially, it depends. If design is busy, they’re like it’s never going to, it’s never going to happen. If engineering is busy, they’ll give you a date, but it’ll be four to five years in the future. [right] So manage me through that, Chris, I know you want to build this. And you’ve told me that we’re going to, you know, really ship something good every six weeks. But I don’t, I, before 18 weeks, I don’t think I can even get you a line of code.

07:52 

CL Then and the first question to ask is what needs to change? How do we make this? How do we break this up? How do we make this a smaller deliverable so that it can still be valuable, but we can get something out the door. You know, this kind of relates to point number two, which we’ll talk about in a bit, waiting too long to ship, but there’s always an interim goal line. I think that you can set and communicate about that gives the team a sense again, of what they’re going after, you know, on a month to month basis.

PF What makes something valuable? Like a release that’s valuable, right? Cause to me, and if I’m a normal human being, I’m going, well, I want to use it. I want to use the app.

CL Yeah, of course use is a key like criterion for what makes something valuable, but there can be other things. I mean, maybe you want to try out an idea right? In a, in a UI or you want to experiment with a new flow. You know, onboarding is a common one, right? When you’re playing with, uh, an onboarding flow, you, you might want to start by doing it in a very rough way that is not intended to be used initially so that you can validate something and get, and then iterate. I think this is, this is a key thing, by the way, having a timeline and a roadmap and a set of commitments does not mean that you can’t iterate or change or grow. Oftentimes the commitment will be, this is a V1 of something and we want to get it out there, try it. And then there will be a V2. And we know that and that’s okay.

RZ Yeah. I, I’m going to say, I’m gonna put a more cynical spin on this to answer Paul’s question of what is valuable. How do you decide what’s valuable? To me, you are always buying time when you’re on a, on an effort. And if there is a checkpoint where you get to show some stuff to the stakeholders and you can get them excited, to me, it isn’t about the joy on their faces. It’s that they’re going to leave you alone for a little bit longer to keep going and to gain trust from those people that are in the room. So I like to orient around, okay. They haven’t seen anything in three weeks. It’s time to show them something. What can we show them that is going to get them to say, Oh boy, this is good. Let’s keep going.

10:02 

PF You guys are, you guys are actually in violent agreement here. And I don’t think one is cynical or one isn’t cynical. What Chris is saying and what you’re saying is the same thing, which is that the valuable release doesn’t have to be a complete product. It does have to be a social thing that people can interact with, talk about. And the more people who can kind of see it and see evidence of it and give feedback on it, the better. [yes] And then you have to manage and triage that feedback. Like you don’t want the CEO to be like, ah, I don’t like purple, [that’s right] but like the more social, the more like hooks it has into the community around it, the better. And so that’s a really interesting way to structure your releases. And actually, this is something I’d love for you to talk about Chris, because think about a software product, right? Like it’s got a lot of really boring non optical stuff underneath it. It’s got APIs and we’re going to write a little library at the kind of close to the SDK level to, you know, help with the analytics layer, you know, stuff that is utterly invisible except to a couple small groups of pretty highly trained individuals. Right. And now, but somebody is paying Postlight money in order to get the big thing in their head, out into the world. So walk me through that. Right? Like, so we’re, we’re, I mean, a lot of times timelines aren’t slipping, but people think they are because they can’t see or touch or feel what’s getting shipped.

CL I mean, it’s on the team to make some of those things a little clearer and less opaque, right? I think there are ways to talk about even infrastructure work, to translate them into how they will appear in the experience, which is something that we’ve done in the past. Right? We talk about how we’re going to have effects on speed or time to develop new features in the future or making things run smoother. As we go ahead, we can sort of editorialize those under the hood features when we’re talking to stakeholders. But the other I would say is these commitments and these timelines, they don’t have to be everything. It doesn’t have to be exhaustive to represent everything that the team is working on. Often it just has to be the key things that stakeholders around the org care about so that they know what is coming, that’s going to affect their world. And again, that they can sort of plan around those features or fixes or whatever that are, that are going to have a day to day impact on what their team is doing.

12:22 

PF Alright. So Chris, I want to build my little stock trading app. You’ve come in and we’ve been working on this for 18 months. There’s a team that’s already in there. They have, you’re telling me about roadmaps and timelines and commitments. We’ve already promised this thing. Now we did miss the first seven ship dates, but don’t, you know, [Chris laughs] like you don’t know how hard this thing is. Right. And so like, look, we’ve got, we’ve got a timeline. We’ve got commitments. I mean, we were going to ship last year, but we’re going to ship the next year and it’s all on schedule. So why did they bring in this outside firm? Like what’s going on here? And look, I know you, don’t like, you’re not a bulldog who likes to cause terrible pain, right? Like that is a situation that probably 90% of the software in the world is currently in is the like, Oh, it’s a little bit late. It was hard. I don’t know. But we’re agile. Everything’s fine. Unlocked that for me. And then talk about your second point a little bit too, which is people wait too long to ship.

CL Yeah. This is the thing. It is so common that organizations get in this setup that you just described where they’ve been working on something for nine, 12 months, maybe longer. And they just haven’t shipped it because they feel like it’s not ready. The reality is sometimes software is not ready. It can feel too soon. And that is okay because there is no substitute for getting real usage on your product, period. Whether that’s usage internally, uh, with working software that you’re beta testing with a group of people who are inside your company or usage with a set of early access customers or something like that, you will learn things that you won’t learn during the design phase. And the only way to start that process going is to break a piece up that you can make as working software and push it out into the world. If you’re working with a product that has gone on for a year plus, and you don’t have something, then you need to reevaluate what you’ve defined as that minimum viable product, that MVP the smallest possible thing that you can get out there. You need to take another crack at it and figure out something that you can ship and get in people’s hands.

14:32 

PF What about to like everybody, if I’m an engineering team, what I can, or our product team, I can turn around and be like, yeah, but we’re following agile. We’re doing everything right. We’re using the process. So what do you do then?

CL Yeah, I actually, I had a bullet in here in my notes that says: ”but we’re agile!” Agile, the process can’t be an excuse. Agile is about…

PF That’s it. That’s the title of the podcast. [Chris laughs]

CL So agile, it’s a means to an end. The point here is you’ve got to show working software. You’ve got to get working software into people’s hands. That’s what it keeps coming back to. Shipping builds trust, it builds trust internally with the people who are using it. It builds trust externally with your customers. When they see that things are changing. You know, one of our projects, a few years back, we came in, uh, to a large media company and their editorial team, when we had our initial meetings with them, they were just resigned to things, never changing. There were bugs in the software and they just figured out how to work around the bugs because they had no confidence that anything was going to ship. So, so part of shipping is about building relationships with the stakeholders you’ve got inside your own company to know that your team is delivering value consistently to these other groups.

PF This is a real thing too. Like a lot of times you’ll be a year into that project and then they’ll ship something that nobody really wants.

15:58 

RZ I mean, the cool, the coolest, the Holy grail is when they’re so happy with what you just delivered or what you just shared with them. They’re like, get this right. They actually pull back and actually become less demanding and less suspicious. And they say, just keep going, give this the time it properly needs. We trust you. And just go. And, and that is the ultimate, right? Because there is implicit trust there that I think this is the thing that’s worth highlighting here. And first off, it’s very hard to get software, right? You ship off. And so you can see if you got it right.

PF Well no one, no one’s done it yet in history. 

CL Exactly. 

RZ No one’s done it yet, right? So don’t hold up for too long, right? Experiment, iterate. I mean, this is, this is commonly echoed out there from like the best software thinkers and the best product thinkers, get out there. But the other bit is don’t hide for too long because this is terrifying for the nontechnical people. They just don’t understand why something takes six months. Sometimes the thing does need six months. Sometimes the thing needs years, but more than anything else, there’s just, it’s like the family in the waiting room during the surgery, like they have no insight or visibility to what’s going on. It’s an incredibly stressful time. And then the surgeon comes out with, you know, the face mask on his chin, ready to talk to them about how everything went really well. There is a complete lack of control here that is in play, always. So how do you get the family comfortable? Right? The best doctors have good bedside manner and they talk to you and they explain things and they walk you through it. I had surgery a couple of years ago, the doctor, the surgeon left the room during the surgery because it was four hours to talk to my wife. And then went back in just to let her know that everything was going fine. Like that, I mean, I’m not saying that all surgeons need to do, but you see that the value that is it brought her trust level up, brought her temperature down. There’s just a lack of control. Now, the thing about surgery is there’s no like, Oh, could you please stop it? Don’t do it anymore. I would like to cut the funding and I want you to just close them up and call it a day. The truth is the stakeholders actually hold all the power, but feel very powerless in the world of software. Right? That’s a very strange dynamic, right? So like, Hey, listen, just trust us. We’re going to get this done. But you know, if they wake up and they read an article in like CIO magazine, that may be the end of it. You just don’t know. So I guess, let me push back, Chris. I want to, I want to close this by pushing back on both of these points, good software needs flexibility and needs that kind of open-endedness. In fact, we often set clients up that way. Like, look at the timeline it’s going to, it’s going to shift and the requirements they’re going to shift, even though they’re in a contract, they’re going to shift, they’re going to move around. So what are you talking about? Like, why are you being so rigid?

19:01 

CL It’s not about being rigid, I think. It’s that you can’t be completely open-ended. You have to put the guardrails up. We do allow for change in our plans. Of course we do. It’s software. That’s the, that’s the beauty of software, right? It’s not, you compare it to designing a and building a skyscraper. Once you’ve put the elevator in the elevators in, and it’s very costly to move it. Software doesn’t have to be that way. You can change things when you’re further down the road, but you’ve got to put the direction out there. You’ve got to put the guideposts out there so that your team can plan it so that people can plan while allowing for some change. I’ll give you a recent example about shipping early in a way that I think is not obvious to people, because I think it is common to be like, okay, well it’s good in theory, but in practice, how do I get something out there? Now we were working on a content management system and we published a form with a set of text boxes that had no formatting. Now, obviously formatting is a key part of a content management system. You need to be able to make text bold and add links and such, but we started with no formatting because we wanted to just validate the data. And we wanted to make sure that the interface flows were clear and we got it in the hands of people to say, look, we know that you’re not going to use this in production to publish the messages that you want to publish, but that’s okay. We’re trying some things. We’re going to add it as we go. And if there are things that are not feeling right, we can address them much more quickly than if we had waited until it was quote unquote, fully baked to get it in your hands.

20:24 

RZ Interim software is often a tool for dialogue, right? [totally!] Which is hugely important, right? People don’t view it that way because they view it as delivering the thing. I also think the analog of architecture of signing off on blueprints, submitting them to the, to the department of buildings and then getting to work on construction. And then once that step happens, the rigidity and the inflexibility is very, very real, right? Because you can’t change it. I mean, the architect shows up with a hard hat, but they can’t do a whole lot. Software doesn’t work that way. And I think, I think that’s something that people still to this day, we’re what are we 40 years in? Don’t know. They just don’t know. They think it’s like building a building.

PF I was thinking, in construction, you have the white, the white shirt, fire department, people walk through like the, uh…

RZ Yeah, yeah, yeah. The marshals.

PF Yeah, the marshals. Like the senior leadership. Right. And they look at things to make sure that you’ve met. Like, there’s a lot of compliance. There’s no white shirts in software. [right] Like there’s no, there’s no point where a bunch of guys show up unsolicited and are like, I need to walk through our API calls. [that’s right] So those, those metrics, those external quality metrics, people can kind of cheat on them. Look close this out. Chris, tell me, so let’s say I am in the middle of a project where people are, how can you tell if something’s going well? Right. Like, so we know it’s kind of easy to tell if it’s going poorly because nothing shipping and everyone is kind of pointing fingers at each other. But what is your instinct? Your, what is your instinct when things are rolling along? How can you tell? 

21:50 

CL Sure. A few things come to mind. The first one is a regular release cycle that can be every other week or every week or even every month, but a regular release cycle. That’s getting software out into the world. That’s number one. Number two, a beta program. Some way to test features, that’s a key.

RZ Beyond the team.

CL Beyond the team. Yes, exactly. It can be internal, by the way, it can be, you could be beta testing with customer success or beta testing with sales, but having a way to try software is, is a key hallmark of a well functioning team in my view. And then a third thing is breaking features down. So not waiting until something is complete, checks every box, rather it checks a few of the boxes it’s enough to validate and it moves ahead.

RZ Very cool. Alright. So let’s recap the first two points in this series, the first is being vague about your timeline and commitments. Don’t be vague, pick little wins, little goal lines, all along the way and give clarity to what you’re going to deliver.

PF And also make, make sure there are things that can be communicated outward. [exactly] Not arbitrary. Like we hit the X57 and then no explanation.

RZ It’s worth punctuating this point you’re making Paul, which is, how you communicate this out.

PF Yeah. They’re not wins unless everybody knows their wins. 

CL Bingo. 

RZ Yeah. Don’t send links to Jira. To non-engineers who are out there. Talk to them about what they’re going to see.

PF I mean, I have to say we have a weekly status email that goes out to the MTA and I see it in the Slack and MTA is our client. We talk about them on our website. So, and boy is that a set of things that were done that are really clear? Like when I read that, I’m like, okay, I know what these are. Even if I don’t know exactly what they are. Cause I’m not on the project. Like it’s, it’s stuff that obviously that I, you know, with one or two steps, I would do exactly what is happening there. And that that’s key. There’s not, it’s not just like adjusted, you know, you know, nobody says like, you know, the worst, the absolute worst is when people say, you know, we’ve had a great week grooming the tickets. Like we had a great week doing meta work. [yes] So we’re really ready to work now. This is going to be good. And then the next week they’ll be like, Oh boy, you should see the tickets. They are just even better than they used to be. [Chris laughs] [music ramps up] I swear to God as a leader, you can get away with that for about, you know, three sprints, because you can always pull a meta card. And then by the third, the person, if they’re, if they’re keeping an eye on things, it’s going to go. No, no, no, no, no, no. Wait, wait, wait. So that that’s a danger zone.

24:22 

CL Yes. 

RZ So two great points, give timelines and commitments, communicate them out and communicate them to the team. And don’t wait too long to ship. They’re kind of connected to each other. Don’t hold up for too long. There is more coming and we’re going to do it in future podcasts with Chris. Chris, thank you so much.

CL You’re welcome. 

RZ We are Postlight, a digital strategy design and engineering firm. I didn’t get you. I didn’t let you say you’re welcome. Sorry, Chris. [Chris laughs] I had to, I moved into sales mode. I mean, I’ve run into, I moved into prod, company pitch mode. 

PF Chris is a managing partner that’s used to this dynamic from the president and CEO. [Rich laughs]

RZ Reach out hello@postlight.com. We’re a digital strategy design and engineering firm done some really, really cool big sprawling work for some great clients. Check us out at postlight.com. Have a good week. Thanks Chris.

CL Bye!
PF Hello@postlight.com. [music plays alone for 3 seconds, ends]