Transcript

Paul Ford I would like to do the mistakes of CEO’s, but that that’s like a fourth, that’s actually like a 400 episode podcast series.

Rich Ziade That’s a new podcast series. [music ramps up, plays alone for 16 seconds, fades out]

PF Alright, so, Rich, good to see you. 

RZ Yo! Good to see you too.

PF We are back for the third part of a three part conversation with our head of product, managing partner at Postlight, Chris LoSacco.

Chris LoSacco Hello there!

PF Chris, thank you. Good to have you back on. So look, let, let me, let’s talk about where we’ve been. Okay. What are we talking about? We’re talking about the big mistakes of product management, which is it’s always good to start with mistakes. Failure is interesting. Success, eh, everybody can claim success. Failure is fascinating. So the first episode was about being vague about your timeline, not nailing down your commitments, and then waiting too long to ship, to get stuff into the market. The second episode was about not paying attention to your tooling, not paying attention to the kind of systems that you use to manage the product, and also single sourcing your QA, just like hoping that the QA process will, will solve everything instead of, and what you should do is get everyone to take ownership. So we got two more big mistakes. And the first one, this one is kind of fascinating, right? And here it is here. Let me, let me just, I almost don’t even know how to say this, because this is exactly the opposite of what I would tell you to do. Chris LoSacco says a huge mistake of product management is listening to your customers. 

RZ Ooooff. 

CL You have to say the whole thing. Listening to your customers verbatim.

PF Okay. Alright. So what’s the, what are we talking about here? [Rich laughs]

01:48 

CL So here’s what we see a lot when we come into the organizations that we partner with. We see product platforms that just have feature after feature after feature that’s been added because a big company requested it or you needed to sign that key contract. And so you just keep adding things on to your product. We have seen so many teams that have been led astray because they just keep kicking on, you know, the next ask without stepping back and thinking critically about what’s ahead and how the product should evolve and thinking about features in the context of where you’re going. Can I, can I make a controversial statement? I think user research is overrated. [Rich whistles] [Paul makes explosion noise]. Often it’s misapplied and they just talk to people and they say, okay, cool, we’ll do that. And we’ll do that. And you know, we did our user research. we’re done. 

PF Listen, so that an entire cohort of experienced designers don’t suddenly jump through my microphone and spear me in the eyeball. When is user research good? 

CL It’s good in the context of a roadmap in a product and design team that is thinking about how to evaluate what you’re learning from users. I am all for talking to customers. I think that is a great thing, but I think you need to understand your customer’s problems and then bring good design to bear to solve those problems and not just take them, you know, exactly what they’re requesting and let that become your roadmap. Define your roadmap.

RZ Can, can I throw out an analogy here? And I think we’ll kind of say this in a different way. User research is uncompiled code.

CL Love that.

RZ Like you actually need to take that information and do a lot with it. You can’t just pump it through, it doesn’t work. It has to actually get processed. And it actually has to get turned into something else. Because, and this is not through no fault of anyone, users are biased, [exactly] users have habits, they have patterns they lock into, they have opinions and all of those, those are inputs, as far as I’m concerned. You need to take those inputs in. User research on its own is valuable, but if you’re going to be literal about it and about interpreting it, then you’re not really going to innovate. And you’re touching on design here. And this is a sense, I mean, a third of Postlight might’ve just quit when you said those words, but I don’t think that’s going to happen because our designers have come to appreciate that user research is one of numerous data points that get taken in and distilled down into the way you solve a problem.

04:40 

CL That’s, that’s right. I actually think our designers, this is really going to resonate with them because what we do typically is we take that user research and we do do the extra step of evaluation. What our designers do so well is that we’re after problems, not solutions. We want to go in there and understand what’s at the core of what they’re, what they’re saying and why they’re making a request for dictating a feature. And once we understand the problem, then we can say, okay, now let’s figure out the right way to solve it. And sometimes it looks similar to what we heard in user research. But other times it looks very different actually, but can be far more effective when you’re, when you’re focused on getting to the root of the problem.

PF Help me through this part, right? Which is, I’m going to talk to somebody about what they really, really want in this product. And they’re looking at me with big, bright eyes, and they’re going to tell me about all their hopes and dreams. And I’m going to nod and say, let me, let me see what I can do. And now I’m going to come back with something really different than what they thought. And they might be a senior stakeholder, or they might be someone who uses this tool every single day. And how do I help them understand that I heard them? And then I kind of ignored them.

05:49 

CL I think you said it right there, Paul. It’s, is you have to make them understand that you heard them. There’s an interim step before you show them a design that is talking about the, what you learned, what you heard and sort of playing it back to highlight what’s underlying the feedback, as opposed to just saying, okay, we heard this thing, we’re going to go do this thing. Another thing that we do when we evaluate feedback is we don’t just take, you know, one interview or one discussion or one data point. You look for themes. You look for the through line that keeps coming up, right? Oh, it’s, you know, we’ve had a dozen people that referenced this same corner of the app that’s hard to use. That’s a clear hallmark that, you know, we need to go focus our energy there, or you know, something similar. 

PF How do you synthesize that? Does that come back as a deck? Do you write a report? Like, because user research, they always have those bigger reports and personas and it’s very impressive. 

CL Yeah. [Rich chuckles] Sometimes it can be a report. It can be a deck. It can just be a conversation, sometimes. As long as you’re taking that moment to say, we’re gonna stop here. We’re going to look at what we’ve heard. And then we’re going to do the design effort after the fact, as opposed to just starting to write the tickets after you have that interview session.

PF That’s the danger, right? The danger is that you hop into Jira and you, you know, and this is like, user stories are literally this right? Turning a user story directly into a ticket without that synthesis. And literally what you’re asking for here is for everyone to take a minute.

RZ I mean, I think if you look at a lot of the tools, a lot of the platforms that we’re asked to take a look, to give an opinion on or evolve or take forward, what you see is just layers and layers of interface, right. Just caked on. And what that is, is an artifact of taking feedback too explicitly. And just putting it in. So you get all this signal coming from sales, from customer service of things you should do. And what they do is like, you know, they said they wanted to thing so that three or more people can be invited, but then if you drop one of them off the invite stays. But that person gets a special workflow where they get to get invited to the meeting afterwards. And then you get someone creating that feature that just feels so custom tailored. So bizarre because we look at these things years later, right? Like we look at it and we’re like, what is happening with this application? It’s a Frankenstein. And what that is is, is the lack of sort of synthesizing all that feedback into a real cohesive product vision. Instead, you’re just being very explicit, very literal about what the feedback is coming in is right. I got to put it in, look, sometimes it’s the customer’s American Express and they want the thing and you got to give them the thing, [sure] like very explicit, like they won’t renew the license unless you give them the thing and you give them the thing, but you try to defend the integrity of the product. I think that’s the thing that often falls by the wayside.

08:41 

CL Yeah. That’s really well said. Another technique that we’ve used that is very effective is trying new things and then putting them in front of customers to validate them, to see whether they work, as opposed to just having a conversation and saying, tell me what your pain point is so that I can fix it. 

RZ When you say trying, do you mean you’re actually implementing the feature or you’re, it’s a prototype or both?

CL It’s a prototype.

RZ Prototype. Okay so you’re not making the full investment of actually implementing, you’re saying, take a look at this, click around.

CL Exactly. Take a look at this and click around. 

PF And like inVision or something. Right? 

CL Very often it’s inVision sometimes it’s a, you know, a little piece of code. It’s a component that we want to try. You know, it’s a new approach to a date picker or auto-complete within rich tax, something like that where we’re like, we actually need to have working software for this to feel right. But often it’s design. Often it’s inVision. And the benefit there, the power there is that you are now leading the conversation a bit and showing something that the person on the other side of the table may not have been able to think of. So they would never have said, here’s where, here’s what I want or here’s what I need because they couldn’t, they couldn’t even do the work to get there. You know? But if you, if you take that first step and of course, you know, you need to validate it. But if you take the first step, it could be a much more, you could take a much stronger step in the right direction because you’re taking a little more initiative to, to go in a certain way.

10:08 

RZ Well I mean users aren’t designers, right? I mean, they’ll tell you what they kind of want because they’ve been through pain, but they’re not going to think through all the way down to the bolts, what the thing should do. It’s not their job. Right. And that’s why we’re here.

PF Here’s where we are. Right. We, we, listening to your customers. Yes. Verbatim, very dangerous because then you’re not really doing your job. And so you need to communicate to them that you’re going to listen to them with a lot of respect. And then you’re not just going to scribe down what they need. You’re going to turn that into a working product where all the pieces and all the users have been considered, and that’s going to take time and it’s going to take thought. So you’ve got to build that relationship. 

RZ Yup. 

CL Yup. That’s it. 

PF Let’s move on to the very last mistake of product management, number six, forgetting to market your product internally. Alright. So wait, market your product. What does that mean? And internally, meaning inside the organization.

CL Inside the organization. So marketing your product is getting the word out about it, putting it in front of people, talking about its features and its plan.

PF So wait, what are my methods? Right? Cause I can’t run Google ads. I can’t, you know, I can’t do promoted tweets. 

CL This is tricky. Um, and it’s different. I think for every organization. Sometimes you can, you know, hold a monthly meeting where you are opening up your product roadmap and you’re doing demos, short demos, I want to say. I think a lot of this is what agile is after, right? They say after every two weeks you should be doubling software, but we’ve seen a lot of, a lot of implementations of this where it’s just not affected because people tune out. They just don’t care most of the time to see the small feature that, you know, you completed in a sprint, that was an item that was, you know, two thirds down your backlog. Like it just, it just doesn’t matter to people.

PF Cause it’s about, it’s about you, not them.

12:00 

CL It’s about you, not them. And you need to make it about them. You also need to put a little energy into the way that you talk about your product inside your organization, just in the, in the same way that the marketing team is putting energy to how you talk about the product outside the organization. We’ve had a success with a few things. We make videos. Sometimes it’s our product team. Other times it’s designers or engineers who are recording again, very short walkthroughs of a feature or something that we built.

PF How short is short?

CL Like two to three minutes.

PF Gotcha. And is it just voiceover and them moving the mouse around?

CL Yeah, pretty much. But the great thing about video is that it can travel. It can be shared around. It’s not just the person that you’ve given it to with the team you’ve given it to, they can, you know, talk about it with the teams that they’re talking with. And it’s great. We’ve had, we actually had, have had clients come to us and say, you know, we used your video to help sell another team on something that we needed to do because it’s a, it’s a little portable, you know, pitch that they can take around. So that’s great.

PF Let’s, let’s do one really quick. Let me like in not all three minutes, but like, okay, so here’s the video. How does it start? What are you showing me? Like, give me an example of something you could show me, how do you end it?

CL I would start it by giving context about, you know, a feature that we’re building. So if this is an editorial platform and we are, uh, letting you, uh, you know, we’ve created an interface where you could build custom cover animations on top of a story, you set it up in the first 20, 30 seconds and say, here’s what, here’s why we’re doing this feature. Then you dive into the actual implementation, you know, you screen-share and walk through how the feature is used for the next 30 to 45 seconds. And then you might give a little recap and say, here’s the first three places we see this being used. You know, we know this, there’s a story in the editorial pipeline. That would be great if we had this available, that kind of thing.

13:59 

PF Can’t emphasize enough, having watched a lot of these, the key thing is not getting it perfectly right in terms of the technical production and every mouse motion being ideal. The key thing is energy in the voice and a sense of enthusiasm about actually shipping this feature, right? Because people pick up on that just as much as they pick up on what’s good about the feature.

CL That’s very well said. It’s you should put the same thought and planning and care and energy into something like this that you would do. If it was going on, you know, your products homepage or the .com/tour, you want the same kind of feeling when you’re looking at something like this and it doesn’t have to be a, we like videos. It doesn’t have to be a video. It can be, you know, a short writeup or a set of screenshots or even well written release notes go a long way to just marketing it internally. If you’re just exporting out of GitHub or a bunch of Jira tickets and saying, here are the, you know, 32 things we shipped this month, it just it’s going to fall flat.

PF RS492 is done now!

CL Exactly. It just doesn’t make the same impact. 

PF I mean, videos are great. Let’s just be clear. Like all everything you said is is real, but a three minute video is a powerful artifact in 2020. 

CL Yes!

PF People like them. They react to them. They like to see software actually in motion. 

CL Exactly. Another powerful artifact that we use is stats. And not just any stats, but pick the ones that are meaningful to how your product is used and talk about them, send them around, right? If it’s a publishing platform, talk about how, how the editorial team is doing. If it’s a financial platform, talk about the trades that have, that have gone through the pipes, you know, on a given week or month, talk about the usage rather than the features. That’s another great way to market the product and also be real about how it’s being used and what the impact of the software is. This will require effort like it is, there are marketing teams that market the product externally. In order for the product team to do this effectively, like you’re going to have to spend some time on it. And that means that you have to budget, if you want to think of it that way, some of the team’s collective energy over a sprint or over a month to grabbing some of the design time, some of the engineering time and putting this together, we’re believers that it works. That it’s helpful. That it’s good if you take 5% of your collective energy over a given period and put it towards talking about the product, but it is something you need to be aware of and something you need to plan for.

16:37 

RZ And, you know, I think this is born out of, you know, Chris and I worked together at an agency before Postlight and I think it’s born out of just the constant need to convince people that they’re getting value. Right? And I think in very big companies, like if you’re a product manager at American Express, who’s responsible for the fifth dropdown fourth click for the next six months, you don’t feel compelled to convince anyone of anything. You’re just sort of your, your services. You’re providing a service to stakeholders. Whereas here, what you’re saying is, look, I’ve made some decisions. I made some pretty big decisions. I want to convince you that they’re good ones, right? And, and that is very empowering, not just in terms of getting people to buy into the decisions you’ve made, but into understanding the value of product management of like, of an understanding that this is not someone that is just taking a ticket and churning it through a machine. And it spits out a feature. It’s actually the future of the product. The roadmap is in this person’s hands or in this team’s hands.

PF I mean, look, this has, this is a huge thing, right? Because we’re, we’re moving very quickly, often. We’ve been in orgs, I remember once talking to a big financial work and they put it into a text box kind of on the homepage where banking customers log in. And somebody implied that, that had been six months of their life, right? Is that one box. Had to be global and a lot of discussion as to the copy that would go underneath it and translation and drop downs and all sorts of things. It’s a big box, important box. It wasn’t six months. It was six weeks. Right. And so, but that’s what they’re used to. That’s the framework that’s going to make sense to them. And suddenly you show up and you’re like, actually I took your destiny and in my hand and shipped software, and that can be, it’s less explosive to me, I think, than it used to be. I think we’re better. And we get better and better at managing the disruption that that brings. But the storytelling that you have to do around it is part of the job because otherwise the entire institution will rally and say, no, get outta here with all that change. It’s too dangerous. Whereas if they feel excited and motivated by it, they’ll jump on board. They’ll get really, they’ll get really into it. So what is a storytelling with little modular tools that you use over and over again as part of your practice.

18:49 

CL Yeah, that’s very real. The, I feel like the other side of that coin is people just not knowing what’s, what’s possible, what’s available, right? There’s a group that’s in the other, another part of their org and they don’t even know what that team is working on. An example of this in our work is, you know, we work with Goldman Sachs. You can read about that work on our website. We were building a desktop…

PF To be clear, I was talking about a different big bank before.

CL Okay.

RZ FYI.

PF Just, just want everybody know that. We work with, we actually work with a couple of big banks, anyway, go.

CL So we worked with them on a desktop windowing system that uses web technologies. And part of our work early on was just talking to the other teams at Goldman and saying, here’s something you can now do. You can take web tech and deploy it on people’s desktops. And that was a big deal. Just writing, you know, windowing system. Like it’s hard to hard to get a sense of what that is. And we had to actually spend some effort talking to…

RZ Selling.

19:45 

CL Exactly. Selling and getting, getting it clear in people’s minds. What was possible here now that we, you know, that we had built some of this infrastructure. It’s worth, it’s worth highlighting too, that sometimes you just need to talk with people like you need to set up the one-on-one with the salesperson or the customer success person or whoever it is and say, let me just walk you through what I’m working on. And it could be 10 minutes or less, but just taking that time to share what’s coming up. I feel like so often the product team is like, Oh, I just gotta be heads down building. Like we have our, we have our sprint, we’re going to just do our thing. And they miss it and taking the few minutes every week or every couple of weeks to zoom out and just talk about what you’re doing is so, so, so valuable.

PF You know what this brings to mind too, is that, so look, the thing you get taught over and over again, building product is like the user, the user, the user, the user. And a lot of times there’s something we’re building, especially if we’re building it for big org, it does have an end user. It’s a, it’s a customer of that organization who doesn’t work there and is going to buy access to service and we get access to them. And we talked to them and we, we try to take good care of them, right? Except that there are these 20 or 30 other users who are the marketing team and the sales team, we have to sell this thing. And the people who are going to update the content management system that does the marketing. And like, there’s like 20 little subsystems that are going to be part of their world. They might be tracking leads in AirTable or a Salesforce or whatever. And if we’re doing our job and we priced the project correctly and the schedules right, we’re dealing with all that too. Right. And so like, they’re your users as well. The people who log into the admin and they’re the ones who are going to determine a lot of the success of this thing longer term. How many other projects do we come into where it’s like the end user is looking at a webpage or logging into a thing. But the actual work we’re being asked to do is everything but that right. Cause it’s just such a mess to get work done. And so you think you might be able to skip it. You can’t, you gotta, you gotta have those conversations. Cause there are sort of like, it’s not like they’re the most important user, but they sure are as important as the end user.

21:50 

CL It’ll build so much good will for what your team is doing if you take a little time to invest in the relationships with those people, the folks who are not seeing the consumer interfaces as you say Paul, like necessarily. It’s it’s again, it’s just so valuable to take the time to walk through the, the things that are not usually talked about and can be easily sort of overlooked or forgotten. A little bit of energy here to, to as I’m calling it, market it internally. But just to, to frankly, build the relationships with the people who use these interfaces, those goes such a long way.

RZ Well, I think, I think the other thing worth noting here is that it creates, I mean, just to speak to the political benefits, it creates advocacy. Cause you’re not going to be in the room for a lot of meetings where your product is getting discussed or what is that team over there doing with this point release and why has it taken and then to have people outside of your team, chime in and defend and give you space and leveraging that trust is a very big deal. People forget product management, the whole notion of it is brand new. It is really new and its value is still being scrutinized today. I think it’s taken hold in a meaningful way, but still to this day, many people outside of this, these disciplines don’t distinguish a product manager from a project manager or I’m going to say it, IT. Oh, he’s in IT. And that’s the end of that. Right?

PF I’m going to say it! I’m going to say IT out loud! DBAs!

RZ Alright let’s wind this down so I can turn my air conditioner back on. [Chris chuckles] This is great. Uh, Chris, I mean thank you for your wisdom and generosity and sharing that wisdom. What a great series.

CL These are, these are the things that work really well for us across all of our work. And, and I’m excited to share them. 

PF What I love is that this emerged spontaneously from Chris just doing this job. And going like, I got to get it out, which is exactly what I want from my corporate advice is someone going for God sake? 

RZ I agree.

23:53 

PF That is, like, you know, big smiles and nice tone, but there is how many disasters have we stumbled into and, and every now and then we make one of our very own, but less and less and less as time goes on, this is the real stuff. And look, everybody makes the thing about these mistakes. Let’s just run them through being vague about your timeline. Well, why would you do that? Because my God, if you commit and you miss it, you’re going to look terrible. Waiting too long to ship. Well you’re trying to get it right. Neglecting your tooling. You want to let everybody use the tools they want. Single sourcing your QA, look, we’re going to, we’re going to let the QA team do their good job. Listening to your customers verbatim. I want to help my customers. They want to give them exactly what they want. Forgetting to market your product internally. Why do that? People are going to see the good work we’re doing, and I don’t want to waste anybody’s time. We should just be building, right? So it’s like, these are so organic and so easy to back into. And yet they can, you can just shoot both of your feet off with a sh a foot shooting gun if you do them. 

RZ I think, I think some of these are counterintuitive. I think that’s, what’s, that’s the big thing to learn here.

PF Well, look, shipping product is hard and making mistakes is easy. So, so there you go. Three parts. Rich, what is, what does Postlight do and why should people get in touch? Or honestly, do we even need they, if they listened to this podcast, they know it Postlight does.

RZ Yeah, I mean, we do ship software, fundamentally, but we solve big digital problems. We bring all sorts of perspectives to bear from product design, to architects, to engineering…

PF Say the S word. Say the S word. Say it.

RZ To…strategy…

PF Strategy! That’s what I want to hear.

RZ Okay. 

PF We’re a digital strategy firm. We also do, and we ship products because otherwise you just all talk. [Rich laughs]

RZ That’s, that’s our, that’s our slogan to take down the big consulting firms. Just all talk.

PF That’s right. I love a good digital strategy. You get that 500 page PowerPoint. And then they’re like, I dunno how we build it, but it’s definitely is going to use a lot of AI. And you’re like, Oh no. Then that limps across the line. We help you think the big thoughts. And then we actually make them executable with an eye towards today’s modern pandemic constrained budgets. 

RZ Oh boy. Wow.

PF Yeah, no, we’re here to help. 

25:57 

RZ You’re gonna give them a coupon code, Paul? [Rich laughs]

PF It’s COVID-19.

RZ Reach out!

PF So look, I mean, people want to get in touch. Where do they go? 

RZ Oh, you go to postlight.com. We bought that off GoDaddy, but it has matured beautifully. There’s some great case studies on there and you can reach out to us. There’s a form on there. 

PF Scroll down. It’s got some nice animations. It’s good. The site, the new site tells a good good story. [Rich laughs]

RZ It does. Chris. Thank you again. 

CL Thank you guys. 

PF Alright. Let’s get back to work. 

RZ Have a good week. Bye.

PF Bye!

CL Bye! [music ramps up, plays alone for 4 seconds, ends.]