Transcript

Chris LoSacco I feel like I can see the gears turning.

Michael Shane I know—they’re grinding is what they’re doing. [Everyone laughs.] 

[Intro music fades in, ramps up, plays 10 seconds.]

CL Hi Gina.

Gina Trapani Hey Chris. How are you doing today?

CL I’m doing great—how are you? It’s another wonderful day in the neighborhood.

[0:30]

GT Good, good. Shipping world-class software to our clients. [Both laugh.] I’m excited. We have a guest today joining us: Michael Shane, our head of digital strategy, is with us today. Hey Michael.

MS Hello both of you. It’s a pleasure to be on the Postlight podcast as always. 

CL How are you doing Michael?

MS I’m great. Yeah, I’m good, thank you.

CL You’re coming up on like half a dozen episodes of this year’s podcast. Pretty soon.

MS I know. Is that like a box of candy or like a wristwatch or a certificate laminated of some kind?

CL There’s a gold ring.

GT T-shirt yeah. Yeah we’re going to have to figure it out.

MS Yeah. Let me know what you come up with. I’ll be happy to come back for more. [Gina laughs.]

GT I wrangled the two of you to come onto the episode today because we use a word a lot at Postlight. We use it when we talk to prospects, we use it when we talk to our teams and we use it when we talk to our clients and we use it in general when we talk about software and it’s quality. We talk about how one of the things that Postlight does is deliver high-quality work to our clients. And I think that the idea of quality in software, in big platforms and digital and apps has a lot of different meanings to a lot of different people. And I think to Postlight, it has a very particular meaning. I wanted to talk about that a little bit because there are times when Chris and I will be looking at a website or an app or something. And Chris will just look at me with this, like face with this like, look of just like disgust on his face.

[1:56]

MS Oh, I know that face.

GT Like he just ate something bad, you know. [Everyone laughs.] Because there’s a screen or there’s a button, or there’s an interaction that’s just kind of janky. Chris wrote a great article, which we’ll link in the show notes about why health insurance websites are so bad. And he basically took that face that he felt because he had to log in to deal with a dental claim and turned it into a long article about what goes wrong when big platforms grow over time and make it really hard to get done the thing that you need to get done, which is just deal with your dental claim. I want to start with this. When I first became a web developer, this is back in the early 2000s, and I worked at a startup in like 2002 and there was a QA team. And so I would get assigned a feature that I had to build. Right? I’d get the design. I would get the functionality and I would make it look the way it was supposed to look. And I would make it, you know, when you press the button, it had to do the thing that it had to do. And there were all these like sort of error states. And then I would send it to QA. I would put it on staging and I’d send it to QA. And our quality assurance person would say, okay, it was visual. Does this look the way the designs said that it would look? And when I press the buttons, do the error states happen? Does the success path happen? And if it passed all the tests, then it got the green light to get promoted to production. And that’s the way quality assurance, QA, happens at a lot of software shops. And I think that there’s a lot of value in that, right? Like users shouldn’t be running across unexpected errors or no errors at all, just a broken page. But when we think about quality at Postlight, that’s one part of it. But that’s not bit of quality that we think about and talk about with our teams when we check in with them about how an engagement is going.

[3:33]

MS Right. It’s not the whole picture.

CL It’s not the whole picture.

GT It’s not the whole picture.

MS Yeah. So Gina, I think you make a really good point because the activities you were just describing, like you said, they’re part of assuring quality, but you were talking about quality engineering. And in fact, I’ve heard people use the job title lately or these days of quality engineer and the technical quality of the code, which has downstream impacts like stability, scalability, things like that. That’s essential. But as the person on this podcast episode with the smallest or the least engineering background, when I think about quality, I actually think about something like this, which is: every decision you make that doesn’t put your users at the center of what you’re doing reduces the quality of the thing that you’re building. Whether it’s an app, a platform, a product, middleware, whatever you want to call it. If you’re not thinking about the end users and the people who have to use your platform with every decision you’re going to reduce the quality of what you’re producing. And that’s key for us at Postlight. We try to approach everything holistically throughout the project.

[4:36]

GT Right. We look at all of it. It’s the designs, the engineering, but it’s through a product lens. Is the product helping the user do what they need to do well?

MS Yeah. Let me give you a great example. I was sitting next to Chris in a room just last week and I had this experience where I didn’t pull up the website, but I was thinking about it and I knew Chris would appreciate this. And this website actually belongs to our HR platform. And when you go to this website and you click log in, it opens another tab. [Gina laughs.] It opens another tab. Why does it do that? Maybe there’s an architecture decision or somebody made a bad decision about how they were going to measure success. And then somebody made a subsequent bad decision to juice those metrics. I don’t know, but there’s no reason for a platform that I’m trying to log into to open a second tab in a world where I already have too many tabs. And so even though this platform is beautifully designed on the front end, it’s stable, it meets my expectations. It’s easy to use. The quality of the experience has been lowered because somebody decided that when I click log in, it should open a second tab. That’s a perfect example.

[5:41]

CL That is so well said. It is also near and dear to my heart. When people break the web by just willy nilly opening all these new tabs, that’s no—

MS You can’t just open a tab.

CL It’s a personal affront.

MS Yes. It would be like coming into my house and putting groceries in my fridge that I didn’t ask for. It’d be very strange.

CL Turning all the lights, not cool. There are layers to quality, which I think is what you’re both saying. And Gina, to your point earlier, the baseline level of quality is, does it work? Does the thing do what it’s supposed to do? Which is what a lot of QA, quality assurance teams, that’s how they internalize quality is: does it work? I am looking at the requirements. I am clicking through the interface to make sure that it meets those requirements and there are no obvious bugs or defects. But there can be, there are much higher bars of quality that you can hold yourself to and your teams to. Is the experience exceptional? Does this give me joy or delight as I am using it? Those are the kinds of aspects of quality that I’m looking for, that we are looking for. How can I get enjoyment or delight from a platform as I’m using it, even if I’m trying to get deep work done. That’s the real bar for quality. And I see it in things like the thoughtfulness of a navigation or really great keyboard shortcuts. Like these are things that are, can they be in requirements documents? Yes. But they’re also, there’s a feel, it’s a sense that you get when you’re using a software platform that things work thoughtfully considered.

[7:12]

MS And it’s not something you can put on a punch list either. I often think of the fact that astronauts literally live and die by checklists, but NASA still really cares about making the food better year by year. And they put a tremendous amount of effort and science behind things like that that have no apparent or overt impact on safety or the success or failure of a given mission to the international space station where they really might be caring about horticulture or something like that.

CL Right.

MS Because the overall experience absolutely impacts the long-term effects of the thing that you build.

CL Exactly. I mean, another example, another analogy that I feel like we could use is cars, vehicles. Because you can, you know, the baseline layer is, does it work? Can you drive? Can you turn on the radio? Like that’s the baseline level of, of quality. It’s bug free in that I’m not going to, you know, get into an accident if the antilock brakes don’t work or something, but the higher levels are, you know, is this car fun to drive? That’s like real true product thinking is: how do I make this a great experience when I’m using it? How do I put the position of the volume knob in the right place so that I am giving the driver maximum flexibility while not taking away from user journey, if you want to think of it that way. It’s so important. And I think it’s what differentiates good product teams from exceptional product teams. I mean, it goes back to what you said before, Michael: how are you putting the user first? How are you making good sound decisions that come back to, what do people want to use this platform for and how are we relentless in putting the right things in front of them at every single step along the way?

[9:02]

MS That makes me think of a really loaded, important idea that we’re all constantly butting up against and thinking about, which is MVP.

GT Yes.

MS The biggest difference between building software and building a car is that with a car, it must be complete before you can drive it. It must be 100% complete before it’s safe to drive and can fulfill its mission and fulfill your goals for it. But software is iterative and it’s living. And so the definition of what quality means, you have to modulate it throughout that process. And you have to think about, well, what does quality mean on day one versus day one hundred. And the mix of pragmatism and panache in what you’re shipping is constantly changing, especially if it’s, again, if you’re working iteratively and we talk about MVP, minimum viable product, you’ve heard people offer better alternatives, minimum valuable product, things like that. And so it’s important to understand: how are we measuring quality at the different stages of the life cycle of a platform, because they’re not the same in the early days as they are when a platform is mature. But I think you always have to be making decisions based on putting users at the center and that will never lead you wrong. If you have the right team of experienced people, that’s never going to lead you down a path that’s wrong. You might need to make tweaks, but prioritizing anything else as number one, I think is going to require more effort over time and a lot more sort of policing in order to make sure you don’t step in any potholes.

CL I mean, yeah, that’s really well said.

[10:36]

GT I want to go back to what you said about pragmatism and panache. Because that’s a very interesting point. When you say pragmatism, Michael, do you mean functionality? It does the thing and panache means, you know, fit and finish and polish. I’m putting words in your mouth, but I’m curious, how do you differentiate those two?

MS Yeah. Pragmatism is as a user, can I accomplish what I believe I should be able to accomplish with this experience? In my opinion, you can never have 0% panache in your product. And I don’t know if it’s panache or panache, that might be a tomato tomato situation, but we can just roll with it. We should just, we should use both throughout this episode. So I don’t think you should ever have 0% panache. You always have to have something that expresses the vision for the platform and the people that are behind it. But pragmatism on the other hand, the platform is useless if it can’t do the thing that I’m expecting it to do when I show up to use it or when I launch it. Pragmatism is also things like does it feel snappy and spritely? If it’s an app, does it open quickly? Does it respond to what I want to do if it’s beautiful, but it’s unresponsive, that’s also no good. If you’ve got beautiful visuals and animations, but you haven’t thought about, pragmatically, what’s the range of devices that might be using this app. And I as a user with a slightly old, but perfectly serviceable platform, like an older iPhone or an older Android phone or something. If I get a stuttery experience, doesn’t matter how beautiful it was or how much effort a brilliant designer put into it because it, the decisions that led there—

[12:08]

CL That is so well said. We did a whole episode on speed and you’re a thousand percent right that there’s a hierarchy to how you should approach these things. And speed comes first because that will undercut every single other thing you are trying to do in your platform, whether it’s fit and finish or the panache stuff. It’s not going to matter if the experience is not fast and usable.

MS Yeah. So I saw a piece of research a couple of years ago that I will never forget. And the insight was that a slow or unresponsive mobile experience creates as much stress for the user as watching a horror movie, followed closely by, I believe, solving a really difficult or complex math problem. But the horror movie is what really jumped out. [Everyone laughs.] And that I knew this intuitively—maybe for some people math is scarier than a horror movie. I knew this intuitively, but it really crystallized this issue for me. And that is something I go back to often when I think about pragmatism versus panache, in my view, you earn the right to have panache and to sort of go for broke in that area by shipping something that is stable, responsive, snappy, effective, easy to use, meets expectations. You know, there are sort of minimum hurdles that I think you have to clear as a group of people making software and then you earn the right to—

CL Totally agree. The idea that you can earn it with the bedrock stuff is a great way I think for people to think about it, which is that you’ve got to nail the core and then you can figure out how to enable these other things.

[13:47]

MS And so when we’re working with our teams as we’re shipping software over the course of months, or, you know, a year or longer, we often talk about this idea with them of getting permission to do things. One of the sort of core ideals at Postlight is that even if a client shakes our hand and says, we’re going to do a project, even when we started shipping code, we believe we have to continually earn permission to work with them, to impact their business, to ship software, especially on their infrastructure and earning that permission is true not only on the technical side, but also when we think about things like panache and the best way to get permission, to experiment, to try something off the wall or ambitious, to push a design system or a brand system or something like that is to ship really solid, impactful, fast, impressive software. “Get permission” is a core idea that we talk about that I think is really connected to quality. And to this idea of what does it mean to balance a pragmatic approach to making software with the flashes and flourishes that you also want because great software can dazzle people and move people. And it’s really gratifying to do that, but it’s gotta be pragmatically good first.

[15:01]

GT Definitely. Absolutely. And I do want to talk about the flashes and flourishes a little bit, because a very typical thing that our clients come to us, they say, you know, we often start with a competitive analysis. I want to see the best of what, you know, my competitors and what’s happening in the landscape. Right? And I think that that really shapes people’s ideas, someone who works in industry, you know, their ideas about what is good and what is possible in the industry is often shaped by the landscape in general, right? This is a point actually that you made Michael and part of the reason why we work across industries, and we like to look at what’s going on in, you know, big companies, small companies, different industries, different verticals, is that people’s user expectations aren’t set by vertical, right? People are using apps and platforms and websites for everything. So their idea of what’s good and what’s polished and what’s fast. And like what flashes and flourishes and what usage patterns are good and make sense and are intuitive, are shaped by the whole world. And that’s something that I think is such a great point and something that we have to impress. Like if we look at something that clients put together, we could say like, this just isn’t good. It’s just not good by the standards that a savvy user would expect these days. Like this feels old or clunky, or this new use pattern just doesn’t exist anywhere else. It doesn’t make sense.

[16:17]

CL Yeah. I’m so glad you’re making this point. Gina. I completely agree with it. It’s related to something that I sort of wanted to touch on, which is when we think about the flourishes and the panache and the extra stuff, I think sometimes people hear that and they think extra, they think, you know, oh, I’m going to add in animations or, you know, some special dance that the cursor does when I do something. This sort of like sprinkle on top. But the way that we think about it is that these fit and finish items, they’re not extra. They can sometimes be core to the experience, even though it’s not like speed instability type stuff. And I’ll give you a few examples. One of the ones is what you were just touching on, which is nativeness. Does it feel like this platform works and behaves the way that you expect other platforms to do, not the thing that you’re working on? So a windows app should feel like a windows app, an iOS app should feel like an iOS app and users understand this intuitively, even if they can’t describe it. My mom would never say to me, I was using an app and they popped up a web view and it felt super weird, but she would say that that back button was like, not in the right place or, you know, it opened something that I didn’t expect it to open. And that is a fit and finish type item that if you’re just checking off the requirements, you know, the boxes from the requirements document, you can be like, oh, you know, it doesn’t matter whatever we can, you know, we’ll pull in X or we’ll do this with Y like that could be an I frame, or that could be a web view, whatever. And what you end up with is like this hodgepodge of application views that technically work, and they could be fast, but it doesn’t feel considered. It doesn’t feel native. It doesn’t feel like it belongs. So nativeness is something that I would encourage people to think about. There’s two other things that I would put in this category of like, you know, fit and finish, but not extra. One of them is microcopy. And that’s like a little bit of a buzzword, but it really matters. It drives me insane when I see like three buttons in a view on an application and they all say the same word, like click here.

MS Also not accessible, not accessible to do it that way either.

CL Also not accessible for screen readers. Exactly. Right. Think about your navigation, your headlines, your calls to action. Like the way you name your tabs, the iconography you use, which is not quite microcopy, but you get it. Like the words that you’re using in your application are incredibly, incredibly important. And whether you want to think about that as like product management or content strategy or design, you know, you can interpret it as you want, but your team should be thinking about it because the words really matter when you’re designing an interface. And then the last one I’ll highlight is shortcuts. Shortcuts are great for fit and finish type things. And I, you know, I like keyboard shortcuts personally, as a user, but it doesn’t have to be keyboard shortcuts.

[19:16]

MS Who doesn’t?

CL [Laughs.] I’ll give you a great one: mark all as read. Some people, you know, you wouldn’t think about that as like, I’ve gotta have that on top of my list, but let me tell you, when you are dealing with a ton of notifications in Slack or something like that, and you just want that shortcut. I know because I sat in firsthand some user interview sessions with one of our big clients who shall remain nameless, where people sit in front of software and they click the same button over and over and over again because the software’s not making it easy for them to do something quick. Search is another example. Let me search and jump to the particular place that I want to go. If I am a power user of this interface. That is a gimme fit and finish type of item, making it easy to get around using the search box, right? Browsers figured this out. A lot of platforms don’t do it, or they don’t do it well, giving users shortcuts to get quickly to where they want to get to, whether it’s a view in a mobile app or handling a bunch of stuff in bulk, these kinds of things make users feel great. You feel powerful. You’re like, oh, I was able to do a lot of stuff really quickly. I just saved myself a lot of time. And that is a fit and finished type item that often gets overlooked when a platform is getting created.

[20:28]

MS I love that you shared so many specific examples just now. And I—if you’ll allow me—I think you were making another point that is also really important, even though you didn’t say it explicitly. So I’m going to say it explicitly, which is that this mix of pragmatism and panache, we said earlier, how it’s at different stages of the life cycle of your platform, but it’s also the mix should be different at different points in your user journeys. So if I’m a user, depending on where I am, whether we’re talking about a funnel or something task oriented, whatever it might be, I need a different mix of pragmatism and panache, depending on where I am in my flow and what my mindset is. 

A really simple example of this would be e-commerce. There’s a really famous company. They sell phones. If you go to their website and you go to sort of, when you look at the architecture, they have some of the most impressive technically and visually ambitious product pages on the entire internet. And they’ve been doing this for a while. However, those pages which require a good internet connection, modern browsers, those are not the pages at the top of the architecture that as a user, if you want to understand features in a simple way or make a purchase, that’s not the first thing you’re going to encounter. Those pages are at a point in the architecture that align with a visitor who really wants to go deep and is saying, is signaling, dazzle me. And so deciding where to turn the knobs on pragmatism versus panache matters based on the mindset or the expectations of your user or your audience, and the examples you gave, Chris, are all examples of that thinking. And it’s deceptively difficult. 

You mentioned the search box example. It’s really hard to do search well. That statement in and of itself is almost like cliche at this point. But one of the things that we often say, or at least I say it, is that there is no product strategy without a content strategy. And content strategy is a really important practice at Postlight because the more technical side of content strategy is what makes great search experiences inside of contained platforms possible. But that can be deceptively difficult depending on where you’re doing the work, but a user doesn’t understand that, doesn’t need to understand that shouldn’t, shouldn’t really need to know that. All that we know as people, when we click a search box is what we expect to happen and what sets that, that expectation the best search experiences in the world. This takes us back to the really, really, really important point that Gina was making, which is that our expectations as people who interact with software are set by shared experiences regardless of industry or category. 

And especially if you are working in something, in an industry that is a little bit niche, as in you provide health insurance, or you provide a 401k or you sell tickets to sporting events, it’s important to recognize that even your most rabid power users, even the people who are using your platform the most often are using your platform for a small, small fraction of the time that they are interacting with other more day to day digital platforms. And if you’re not aware of what the best experiences are outside of your industry or your sector or your niche, you’re going to disappoint your users because you’re not the ones setting their standards or their expectations. And we talk to clients about this all the time. The technical term is out of category landscape analysis, which sounds way more clinical than what you just said. So, you know, it’s good to keep the romance in too, but it’s, it’s so important. It’s so, so important. Cause it’s easy to get blinders on. I mean, in a way I would like to think that’s why people come to a place like Postlight because of our breadth of exposure to businesses, industries, standards, and expectations.

CL That’s exactly right. We purposely keep a very wide aperture as we’re looking at the, what did you call it, out of network, competitive landscape?

[24:25]

MS Out of category landscape analysis.

CL Out of category, out of category landscape. I’m going to get that tattooed—

GT New offering from Postlight [Laughs.]

CL You just dropped a lot of knowledge there, Michael. That was really good. There’s one very small detail that I just want to quickly hone in on, which is content strategy, enabling some of these experiences. I think a lot of people just don’t understand what content strategy is or means, and that’s okay. We don’t need everyone to get all the nuance around content strategy, but you’re absolutely right that people have to be thoughtful about the stuff and how they surface the important bits of the stuff. That is important work too. And it ladders up to the overall experience and the overall quality. And whether you think of that as content strategy or product strategy or whatever, you can’t have a good search experience if you don’t know what the things are. I would also say sometimes product teams try to boil the ocean. They try to say, well, we’re dealing with a huge content set and we can’t really figure it out.

[25:28]

CL So we’re just going to dump it on elastic search and it’s going to do the best it can. And the reality is in nearly all sets of content, not every item is created equal. And so thinking about bringing it back to the user goals, right? The end user experience, and what are the things that they are—there’s probably a top 10% that you know, that they’re going to wind up at and you can make it, make getting to that top 10%, really, really easy, or really, really good. And is there still improvement in the bottom 90%? Yes. And at some point, hopefully your team, your collective energy can go against solving the wider problem, but let’s be honest. The top tier search engines have set the expectation for what people want full stop. It is that out of category landscape. And so you have to think about how do I approximate a Google-like experience while acknowledging that most of the time, you know, most teams can’t implement Google level results on a wide content set. Like it’s just, it’s a very hard problem.

MS Yeah. And you can always zero in, if you need to there’s, you can learn things from how Netflix does search. You can learn things from how Airbnb does search. And I realize these are all the biggest companies in the world. They’re household names. But that also means they’ve probably put by person hours exponentially more time into thinking about search than you have. Right? And it’s always worth considering. One last point about content strategy. Like you said, Chris, a lot of teams try to boil the ocean. And it’s so easy to do that when you’re looking at taxonomies and sort of the architecture of your content. But it’s important to remember that content strategy is iterative too. There has precisely been one platform in the history of the world that did not need a content strategy. And it was the original fart app on the iPhone when the iPhone first started supporting apps. That app did not need a content strategy. Every other platform that has ever been created, in my opinion, needs a content strategy. If you disagree, you can email me michael.shane@postlight.com. I’d be happy to hear from you.

GT [Laughs.] I think that all the fart app was a content strategy. That was a pure content play. One type of content.

MS A content model with one attribute: fart.

GT Exactly, exactly,

MS Exactly. Content strategy can evolve too. And if your product has an MVP set of features or an evolving set of features, then the same thing would happen with the content strategy. Because content strategy is simply a set of instructions that tell your platform how to understand relationships between the actions people can take and what appears on the screen, whether it’s video or audio or text or content notifications. All it is is an instruction manual for relationships within the experience of the platform and platforms evolve. So Chris, your point about not boiling the ocean is essential to making good decisions about quality and pragmatism versus panache and features and things like that.

[28:23]

GT The other important thing about content strategy and the piece and this, I think touches back to microcopy and the instructions, is like hitting that right note. Are the messages—are they cute? Are they quirky? Are they reassuring? Chris and I were looking at a financial product which shall remain unnamed the other day. We were in the office. And I was like, you know, the interest rate is really good. So like mathematically it’s great, right? But I’m like looking at these pages and it just feels off. It feels kind of just like gimmicky. And I don’t want anything that deals with my money to feel gimmicky. So I’m not going to do it right now. You could say this is marketing, but that’s also content strategy. The way you describe and present even visually what you’re doing, what the offering is, how you can do it has so much to do with whether or not the person’s going to go like, oh, I’m in or like, Hmm. I don’t know, that doesn’t, that doesn’t feel right.

[29:07]

CL Tone is critical. It’s not just marketing. It is the experience of using the product as well. It has a huge impact on the trust of the platform and the expectation setting really of the people that you’re doing it. Because I mean, you’re right, Gina. Like I remember that conversation and thinking like, you know, I’m not going to go with this financial provider because of this feeling. So it has a very real impact.

GT Yeah. I want this to be powerful and feel secure and solid and like well-established and like bulletproof, you know, and I didn’t get those feelings. Those are the feelings. Yeah. The other thing about quality that I think about a lot is that I always, I want to feel like the platform is sort of rising to meet me where I am and what I’m trying to do. And I think that really shows itself, particularly in apps and platforms where you have to do the same thing over and over like repetitive actions. So like an email client is a good example, a calendaring client, to-do list. Those apps where you’re just, you’re working in them all day long and every half-second that an action, you know, that’s added onto an action because the thing is slow or a little bit hard, like literally adds hours to your life, spent in front of a computer versus doing the thing you want to do. 

When we started working on our project, we built a platform called mercury for the MTA. And it was a platform for sending messages to riders, real-time messages to riders on subways and buses. And by real time like, literally down to the minute, like these trains were delayed and these messages had to go out very quickly. You have people, staff 24 hours a day, composing these messages and sending them out. And we spent upfront, I mean, in the first four to six weeks, Chris, like a lot of time on that composed box because we were like, this is where these folks are going to live. And everything that feels, you know, that there’s friction or drag in this compose box is going to matter. So like one of the things that we did early on, because, you know, you’re referring to subway lines and subway stops, we wanted it to be really smart. So if you mention, you know, there’s a delay on the F train. If you wanted to enter a stop, there would be an autofill, but it would prioritize all of the stops on the F line. So that was more likely that the stop that you wanted to enter was close to the top. So you’d have to scroll through, you know, like, like a dropdown. I know this is very difficult to explain this interface. We need a screen share to show it off. But it was one of those things where it’s like, how do we shave just as many seconds off of, you know, the time it takes to compose this message and then press send because that time, you know, means that it’s going to get out to riders quicker, quicker, and that the folks who do the very good work of keeping the subways and buses running in New York City can like get on with their lives and get, get more done. And we can really reduce that time to go out. It was a lot of time on these libraries that we were using inside this compose box to get it just right and get it really smooth and slick, but that’s the main experience of the platform. And I think it went, you know, a really long way with our users to feel like, oh, like this platform’s actually trying to help me get things done. And so I like being here if it’s helping me get stuff out to my customers more quickly.

[32:10]

MS The thing that stands out to me about the flow that you just described Gina, is that what you just described to me sounds a lot like live dynamic search results, which is something that, for example, Netflix set the standard on years ago, and I guarantee you, most of the people working in that control room at the MTA who live and breathe on this platform, sending messages that are critical for riders, have experienced search on Netflix. And even though they can’t make the connection, this echo, this harmony between the two experiences is something that they sort of feel in their bones that really, really matters. And there’s a lot of technology and a lot of sorcery that the genius engineers at Postlight created to make that possible. But none of that matters, what matters is how the people sending these messages every day to millions of riders in New York City, how they feel while they’re using it. And they feel supported, they feel validated. They feel taken care of because the platform feels responsive. If I could say one thing at the start of every project, it would just be to say, greetings everyone. As we begin work on this software platform, please remember we are all going to die someday. We have a limited amount of time on this planet. [Gina laughs.]

CL Oh my God. 

GT Lifehack.

MS And this software should never take away a moment of time that could be better spent elsewhere. 

GT It’s so true. 

MS Is that too dark? Might be too dark. I don’t know.

[33:34]

CL I mean, what an opener. Can you imagine? Hey, nice to meet you project team. Strap in.

GT As a middle-aged person it really resonates. [Laughs.] Well, on that note—

CL That’s where we’re going to end it?

GT Yeah. I think that’s where we’re going to end it. Life’s too short. We’ve got to make better software. If you’ve got software you think could be better, you should get in touch with us. Tell us about it at least. Drop us a note. Hello@postlight.com.

CL In all seriousness, we would love to hear about a problem that you can’t solve, a platform that just isn’t working, something where you’d like to add some of these fit and finish type quality items to really take your thing to the next level. We love that. We love that kind of work. We would be happy to help. We would love to talk to you. Michael and his team of strategists are uniquely equipped to sit with you and hear your problems and figure out how to translate them into amazing software experiences. Hello@postlight.com. It’s a real person on the other end of it, by the way, you’re not going to get like an auto response or a bot. We have someone who reads every single email and we will respond to you. So we’d love to chat.

GT Thanks for coming on this today, Michael. This was a lot of fun.

MS It’s always a pleasure.

GT Let’s get back to work.