Transcript

Gina Trapani: I love your car analogy, because I can imagine folks listening to the show and arguing with me, being like “No, no, no, but you have to be able to sit in the car in order to drive the car, right?” But, but…

Natalie Kurz: But you don’t!

Gina: But you don’t! We actually don’t, right?

Natalie: I mean, it’s going to be uncomfortable and you’re not gonna enjoy it…

Gina: Right. (Laughs)

Natalie: But that’s not the point!

[POSTLIGHT INTRO MUSIC]

Gina: Hello everybody. Welcome to the Postlight podcast. I’m Gina Trapani, I am the CEO of Postlight, and I’m very excited about my co-host and guest. I think you’re a co-host and a guest today, Natalie.

Natalie: We’ll call it both. Double duty.

Gina: Call it both. Double duty, double duty. Natalie Kurz, our head of product design here at Postlight. Hey, Natalie!

Natalie: Hello, how are you?

Gina: How are you? Great to see you.

Natalie: You as well. It feels like a hot minute since we’ve done this, so…

Gina: It’s true. It’s true. We had you on the show before, you’re a veteran, but it’s been a while and this seemed like a great opportunity. You wrote an article for, on Postlight.com, the Insights section of Postlight.com. The headline just really caught my eye, because I am a person with a particular psychology. (Laughs)

Natalie: Yup.

Gina: And the headline was, “No one wants to waste time on rework.” And we’ll link this article in the show notes. And I was like, “Correct.” (Laughs) No one wants to waste time on rework. Having to redo something is the worst! Like, when you’ve already done it. I should admit, I’m coming to this with, you know, my background is in engineering, so it’s always like “How do you make things more efficient, how do I write this bit of code to make it super reusable in all these other places, and how do we automate things and get things done sooner?” And now I’m, you know, leading an organization, we build software for clients, which means that we’re extremely deadline-driven.

Natalie: Yup.

Gina: And you need to have the final final final final final version of the thing.

Natalie: “V2 Final_UseThisVersion.” (Laughs)

Gina: “_NoReallyThisVersion” (Laughs)

Natalie: Exactly.

Gina: And you lead our design group, and it’s funny, ‘cause I still… Postlight’s teams are cross-functional, we have product and design and engineering all working really closely together, but I will never be able to quell that instinct deep inside me that’s just like “The engineers gotta start building, so the design has to be done. The design’s done, right? I can start building? ‘Cause when it’s done, I can start building.” So, tell me a little bit about… you have this incredibly zen, chill, open-hearted…

Natalie: (Laughs)

Gina: …view on rework. Tell us a little bit about how you view design work, and the times you have to double back and redo stuff.

Natalie: Yeah, absolutely. First, I don’t know if I’ve ever been called Zen and chill, so thank you for that.

(Both laugh)

Natalie: I’m gonna count that one as a first. Yeah. So this was something early in my career, was definitely something I felt, you know, working with engineers it’s like, “No, you must have pixel-perfect, you hand it off.” And that’s really the core of what waterfall delivery is, right?

Gina: Yes.

Natalie: We’re gonna get all the design done, and then we’re gonna give it to engineering and they’re gonna get all the engineering done. So, as I’ve started to learn about Agile and learn about the benefits of Agile, it started becoming more clear that, like, final is never final. Right? ‘Cause again, we’re not… I’m not building a car and then I deliver it to someone and I can’t change it. Right?

Gina: That’s right.

Natalie: The things that we do are constantly shifting, and they should be. They should be constantly changing, right? If you have a product that you haven’t changed in ten years, it’s probably woefully out of date.

Gina: Right. Digital product.

Natalie: Digital product. Yes. Yes.

Gina: But I guess all products. I mean…

Natalie: I mean, to some degree, yeah.

Gina: Yeah.

Natalie: But specifically digital, of course. You know, so as I started learning about Agile, I started understanding “Okay, there’s room for learning.” ‘Cause that’s really what it comes down to, is, to me, I don’t look at rework as a pain, right? It’s not a pain point, it’s an opportunity for improvement. And so, you shouldn’t rework just because you feel like doing it a different way now. Right? That’s not a good reason to rework. But you learned something new. Or a requirement changed. Maybe your stakeholder came in and said “You know what? Actually now our goal is this, we gotta pivot.” Right? Or, we did a whole bunch of useability testing and found out the way we thought this was gonna work, it did not work at all.

Gina: But isn’t that the point where the entire project team should take their torches and pitchforks and say “No! You said, you can’t change!”

Natalie: No! (Laughs)

Gina: “But you said this, and so we’re gonna do that!” Isn’t that time for a revolt? C’mon, you can’t… can you change halfway through? What’s that about?

Natalie: Yes! No, and that… but that is a reaction I’ve gotten, on many occasions. And no, but I think the goal is that no, you have the whole team bought in to the fact that, like, this is exciting! We just learned something new. We have a chance to make this better. We have a chance to meet this user need in a more effective way. Let’s take that time. And so, going into your project with that mindset changes how you approach it from day one. And that’s really the key.

Gina: Yes.

Natalie: You can’t all of a sudden, midway through a project, decide this is how you’re gonna work. Right? This has to be a conscious decision from day one, because everything you do has to be built upon this idea of leaving options open, and leaving things flexible. And so, from everything from the way that you design things to how fast you design them, right? So, even taking a very agile approach to design. So instead of saying “I’m going to design this entire shopping cart experience from start to finish,” right? 

Gina: Mhm.

Natalie: Just saying “I’m gonna design this one small part and test it, and make sure I got that right. And then I’m gonna design this next small part. And while I’m designing the next small part, engineering’s building the first part. And as I design the second part, I might find out something I did in the first part actually doesn’t work. So I’m gonna go back and fix that.” And what we don’t want to have happen is there to be this friction between engineering and design, of that exact thing. “But you said it was done, I’m not gonna waste my time.”

Gina: Right.

Natalie: But the goal is that you’re being very scrappy, you’re being very fluid, and… you know, they only have to redo a small part. Because it’s not like they’ve built the entire shopping experience and now you go “Whoops! Sorry, learned something new, we have to change the whole thing,” and they have to redo the whole thing. Right? So you’re redoing it in very small chunks, because you’re building it and designing it in very small chunks that work together. And part of this, you know, is very dependent on your engineering team too, to build things in such a way where they’re flexible, using clean architecture techniques. Right? Decoupling frontend from backend. All of those types of things. So that when there is a change, it’s not like you’re starting over from square one.

Gina: That’s right.

Natalie: A great example of this, and this is… this is kind of, I think, that aha moment for me in my career, where we were trying a project really using this agile design process, right? Where we were designing in very small chunks, we were doing a ton of useability testing, and they were building it like… we were not two months ahead of our engineers, we were maybe two days. Right?

Gina: Wow, very close.

Natalie: Like, it was a very tight cycle. And everything we’d been building was testing really well, and we’d gotten through a really good chunk of this case management system. And then what we did is, we did this kind of innovative form of useability testing where lots of different departments touched this. So, in their silos, everything was working. But we actually brought together an entire roundtable and said “Okay, we’re gonna watch this thing move through the entire process now. We’re all gonna… you’re gonna hand off like you would for real, you’re gonna see what this other person’s doing.” And in between those cracks there were tons and tons of issues. During those handoff processes.

Gina: Mhm.

Natalie: And one of the big things was, we were told, you know, they had… it was a document management system, a case management system. So, they kept talking about how they need to send documents to each other. And sometimes there could be a message attached. And that’s how we built the system, right? That was the architecture, so the document was the main object, and you could attach these messages. And what we ended up finding out was, that wasn’t working. Because what they actually wanted was, or what they actually needed was, a way to send messages and sometimes attach documents.

Gina: Aah. (Laughs)

Natalie: It was the inverse.

Gina: It was the inverse, yup. There’s a big difference between those two things

Natalie: There’s a very big difference. But everyone kept talking about, most, ‘cause… some of the more vocal people, documents were the main way, they were communicating via documents. So the messages were just addendums to the documents. But it didn’t apply to every single situation. And so, we completely cut off the ability to do this other critical part of their jobs. And had our engineers built this in a very brittle way, that could have been months of time to redo. We got that redesigned and re-engineered in two weeks.

Gina: Oh, that’s amazing.

Natalie: I was impressed by how fast it went. I did not think it was gonna… you know, it was one of those, when I told the engineers I was kind of like ducking for cover, like “How much are they gonna kill me knowing that we have to change this?”

Gina: Right. (Laughs)

Natalie: Bracing for the worst storm ever.

Gina: Right.

Natalie: And they’re like “No, that should be pretty simple. I think… yeah, let’s get in there, we’ll give you an estimate.” And it was totally fine. And it made… had we launched it the original way, it would have been a big failure.

Gina: I mean, it speaks to the fact that the engineers had built a system with flexibility in mind.

Natalie: That’s exactly it.

Gina: And it wasn’t so rigid, right, that it couldn’t be changed, that things could change. And this is what you mean by, this is a mindset throughout. It’s funny, though, that you were like… (Laughs)

Natalie: Yeah. No, I wasn’t sure! It was a big change. (Laughs)

Gina: The listeners can’t see your face, but it was like… wincing. Like, “I, so about this message thing, could we change the entire paradigm? How bad would that be?”

Natalie: Right. ‘Cause it’s, you know, and certainly things like “Oh, we need to change this form field to this other type of form field,” those are easy changes that I very rarely have had anyone ever push back on. But massive changes like that…

Gina: Yeah.

Natalie: You know, it was the first time in my career that I really had kind of run into that, where it was even a possibility. There were times in the past where I’d run into that, like “Ooh, we did this wrong, wish we could do it again but that ship has sailed for whatever reason.”

Gina: Right, right.

Natalie: Like, timeline or, you know, client’s like “No, keep moving.”

Gina: Right.

Natalie: This was an opportunity where it was like “No, we really do need to change this, and it could be a massive change.”

Gina: “This is a fundamental paradigm misunderstanding that we had. We just didn’t realize.” Yeah.

Natalie: Exactly. And up until that point, we’d been testing and everything had been testing well. So it wasn’t even like we could’ve caught this earlier.

Gina: Yup.

Natalie: Right? It was this very unique situation where, like I said, it was in between these cracks, in between these handoffs in this very very complicated workflow that it fell down.

Gina: Yup. I mean, I think back to the beginning of my career, which is, you know, 25 years ago…

Natalie: Mhm. Yeah.

Gina: …when I first started doing engineering. I’m dating myself and I’m totally comfortable with that. (Laughs)

Natalie: Nope, I’m right there with you.

Gina: Yeah. And I mean, you mentioned earlier, the waterfall approach, right? It’s the approach that you take when you’re building a house or an airplane or a car. There are full and complete specs and requirements, and materials cut to exactly the size that they need to be so that they can run through the factory and get assembled, right?

Natalie: Yeah.

Gina: So all… everything gets defined… and you don’t, there’s no change midway. I mean, can you imagine building a house and being, “Actually, this hallway? Should go over here.” That’s a huge…

Natalie: Or “Actually, I need three more bedrooms. I forgot to tell you about it.” (Laughs)

Gina: Yeah, “I forgot to mention.” Right. That doesn’t work. So, yeah. I remember in the beginning of my career, I sort of developed that, like, self-righteous indignation of the engineer who’s at the end of the flow, right?

Natalie: Right.

Gina: Because the way waterfall works, you’ve got product up front and they’re defining… I remember these just, pages and pages of requirements and feature descriptions…

Natalie: Yup.

Gina: Just describing every single last edge case, use case, the whole… and now the product specifications are set. They get approved, the stakeholders are like “Go,” and then design is like “Alright, I have to design this thing.” It gets passed over the wall. The waterfall is like, right?

Natalie: Yup.

Gina: And then it flows down to the next level, right? And designers have to design what’s in the specifications, right? And then the designers are done. And then the designers pass on to the engineers, right? And then often, so often it would happen where by the time we got to the engineers, we’d be like “Wait, this… but we didn’t think of this,” or “But this doesn’t make sense in practice,” you know?

Natalie: Right.

Gina: Because you’re just never going to be able to describe in words or imagine, even the smartest and most experienced people, the things that you just didn’t know, or what it’s going to feel like when you’re actually using it. And this is what this change, this mindset change from waterfall to agile, which is that: We know that there are things we don’t know, and so we’re going to approach this with the idea that things are going to change. The only constant is change.

Natalie: Yeah. It’s the unknown unknowns that get you every time, right?

Gina: Mhm. Mhm.

Natalie: And I think, to me, that’s the true differentiation between the waterfall-agile hybrid, what I call Wagile, and a lot of…

Gina: Ooh! Tell me about Wagile! (Laughs)

Natalie: (Laughs) Wagile, right?

Gina: That’s like… [inaudible]

Natalie: Where a lot of project teams, I think, fall into. Where you’re calling yourself agile, engineers are involved in design decisions up front, which is great. That’s a key piece of breaking down that waterfall, right? Is, like, talking about how are we gonna implement this thing that’s in my head, this thing I want to design? Getting engineers’ perspectives. That’s all great, and I see that a lot of times when you start transitioning from a waterfall into an agile. But the piece that usually doesn’t happen in that transition, which is what I call Wagile, is that agile design. Right? It’s usually waterfall up until it gets to that point of engineering now starts to look at it, and then it becomes agile. Right?

Gina: Mm.

Natalie: So it’s like, the front half is waterfall. We’re doing strat, we’re doing all this big strategy, we’re writing these functional requirement documents for the entire product, we know exactly where it’s gonna go, we start designing, and maybe after we start designing engineers start jumping in and building, right? 

Gina: Right.

Natalie: And that’s, again, kind of that blended approach. But in my mind the best things are like, I don’t exactly know where this is going to go. I don’t know what all my features are going to be up front. I don’t know what that MVP truly looks like until we start building it, until we start ideating, ‘cause it’s like… well, I’m gonna use a quote from a former colleague, that this was his signature quote, was “The devil’s in the details and the details are in the doing.” 

Gina: Mm.

Natalie: Right? You don’t know what you need until you’re in there doing it. Until you’re in there talking to users. And you’re not going to get all that up front. Or even if you do get all that up front, it’s gonna change. That’s the other thing. Things change. Right?

Gina: Yes.

Natalie: So all of a sudden, six months into a project, we just found out we can’t get a license for this technology. We can’t do it this way, now we have to change. Right?

Gina: Yeah.

Natalie: It’s always going to happen, whether it’s a technical thing, a user thing, or even just “Now we have a new stakeholder and their vision is completely different, and now we have to adjust our process.” So, to me it’s almost wasted effort. When you talk about rework, it’s wasted effort to try and define things so finitely up front, because you know they’re going to have to change. So just admit that up front, things are gonna change.

Gina: Right. Things are gonna change. Information’s going to emerge as we go. Yeah.

Natalie: Exactly. And that’s a good thing. If I know everything up front and I don’t learn a single thing from, you know, after my two weeks of discovery’s done or whatever, that’s a failure. ‘Cause there’s so much to learn there.

Gina: Yeah. 

Natalie: If I’m not open to learning those things, or the team isn’t open to responding to those new learnings…

Gina: Yup.

Natalie: …right? With new ideas. Because that’s the other thing. I might have a great idea about how to solve for this thing day one, right? And that’s what we start building to, and then day 51 I start learning something, I was like “Oh. Oh. That actually changes – now I’ve got a better way of solving that thing I already thought I solved because of this new information.” Blocking yourself from going back and being able to change that and make it better, I think, is a… does a real disservice to your users and to the end product itself.

Gina: When you designed and then your engineers built the system that was documents that could have a message attached to them… (Laughs)

Natalie: Right. Right. Yeah.

Gina: A lot of work went into that. I’m imagining that system, and there’s a lot there. And then, when you learned “We missed a fundamental thing,” which is that it should have been a message with a document attached…

Natalie: Mhm.

Gina: So… (Laughs) I’m gonna… here’s how I would feel.

Natalie: Yeah.

Gina: I would be, like, so angry…

Natalie: (Laughs)

Gina: …that someone or something about our learning process, our discovery process, somebody who didn’t tell us this very important piece of information. A question that we didn’t pose. Like, I would get mad, I would get angry…

Natalie: Yeah.

Gina: …because, like, when you say no one likes to waste time on rework. I would feel like, “What a waste of time and effort! We went down the whole wrong road. If we had just asked the question, if we had just talked to the right person, if we just observed…” Like, I would start to… and I think this is my, you know, the sad case of engineer’s brain, I would start to want to re-engineer the process of discovery to get it to the perfect state where we would have had all that information up front. Which is actually not… this is why I said you were so Zen and chill. You were like, “This is, now we’ve learned something.” (Laughs)

Natalie: Yeah. No. And that…

Gina: Like, you’re so calm about it. You’re just like “Okay, that’s not wasted time. We have now learned!” (Laughs)

Natalie: Right. And in that specific case, we had done tons of research. We were constantly doing research.

Gina: Yeah.

Natalie: You know, again, this was a perfect scenario in terms of this type of thing, and not all projects are going to work this way, I fully recognize that. But like, we had daily access to our users, we were doing constant useability testing. We were getting constant feedback, we were doing daily design standups with our client…

Gina: Right.

Natalie: …to show them the changes. And like, it was just, it was a wonderful collaboration from day one. And… but with this particular thing, to answer your question, no, I wasn’t angry, because we had done everything that we could have to get to this point, and we 

Gina: You had done everything that you could.

Natalie: And it wasn’t like if I had just asked that question…

Gina: Right.

Natalie: Because we were getting, the answer we kept getting was…

Gina: Documents!

Natalie: “We need to send documents with messages attached.” ‘Cause that’s how their current system worked. 

Gina: Right.

Natalie: That was the big thing. And that’s another thing in rework is, especially when you’re redesigning a system that already works. That already exists…

Gina: The bias toward that…

Natalie: There’s so much bias. And they had so many… their system was awful, it was this legacy mainframe of, like, different types of applications that didn’t actually talk to each other or connect, and they were entering information in lots of places, and they had a thousand different workarounds. And so they wanted us to build those workarounds in to the system, and I’m like “No, no, no, what are you actually trying to do?”

Gina: Right. (Laughs)

Natalie: And I had to explain to them, like, “Don’t get frustrated with me that I keep asking you why. This is why I keep asking you why. Because I’m trying to get to the root…”

Gina: “So that you don’t have to do all this!” (Laughs)

Natalie: Exactly. I can make your jobs easier. And it was one of those things where, when we tested the documents with messages, they were like “Yup, this is exactly what I need,” ‘cause it’s basically just a better version of what they had. And it wasn’t until we really dove in and started looking at some of these edge cases when we were like, “This isn’t working.” And then once we redesigned it and put it in front of them, they were like “Oh. Oh! This is what we’ve been missing!” And it was this huge realization moment for them, of like, “This actually is now what we need.” And that, to me, was such a great feeling.

Gina: Oh. Huge win!

Natalie: To finally have them be like “Oh my gosh, this is now what I need.” That yeah, there was trepidation about “How much rework is this gonna be?” certainly, at the beginning.

Gina: Right.

Natalie: But I wasn’t angry about it. It wasn’t… I didn’t feel like there was missed opportunity to have learned this. I think if we hadn’t built it, if we had just shown designs, they would have said, like, “Yeah, that’s great!” ‘Cause we were showing designs. And like, “Yup, that’s what we need.”

Gina: Right.

Natalie: So it wasn’t until we actually went through this, like, end-to-end handoff of the system in testing that we realized… like, that was the only time that we were going to find out this information, I guess, is where I’m getting.

Gina: Yeah.

Natalie: But one interesting thing that I did walk away with was, as we were designing that, we kept running into a lot of really tricky design detail problems. Right? There were a lot of things that just didn’t feel like they worked. They didn’t feel right. And once we switched it around, everything fell into place. So I think from a design perspective, that’s a really good thing to lean on, is like – listen to your gut. If something, if you’re really, really struggling to get that round peg into the square hole…

Gina: Is this… is it supposed to be a peg at all? (Laughs) Right?

Natalie: Right. Exactly. Peel it back. Peel it back for a second. 

Gina: Right.

Natalie: Because something fundamentally is probably wrong with an assumption you’re making, or a requirement you were told. What the users think they need versus what they actually need. ‘Cause most things in design will kind of sort themselves out, right? Like, you know when all of a sudden everything’s coming together and working. So if you’re feeling that friction, is it time just to go “Wait a minute…”

Gina: Ask a fundamental… right.

Natalie: Yeah. “Is this a chance to rework right now? Because I really feel like I’m pushing, you know, towards something that’s not really gonna be useful.”

Gina: Right. “I’m going down the wrong path, I see something, like, I’m seeing a bunch of signs that are telling me this is the wrong way, and I keep pushing…”

Natalie: Turn around, turn around.

Gina: Yeah, turn around. Right, right, right.

Natalie: Yeah. Exactly. So that was another lesson, of just like, listen to your gut and maybe change the types of questions you’re asking, or, you know, whatever it is that you can do to kind of work your way back before it gets too late. That’s the other thing is, obviously you wanna catch that rework as soon as possible. So coming up with things in chunks, and coming up with things kind of as you go, as opposed to saying “We’re going to design this whole thing up front.” Well, if I’ve made mistakes – if I’ve made a mistake with decision number one, that is a waste. I’ve wasted now a ton of time building on top of an incorrect assumption from that first…

Gina: Right. Or, you want to fail early. (Laughs)

Natalie: Exactly.

Gina: Or, not fail. Or, like, hit the dead end, or the place where you realize this isn’t working, as soon as possible, right?

Natalie: Yeah. No. I feel like a core piece of Agile is fail early and often. In the article I used, the lightbulb scenario, right?

Gina: Yes.

Natalie: He learned 99 ways not to make a lightbulb. It wasn’t wasted effort. You had to learn those things along the way to get to the end result.

Gina: Right. Good old Thomas Edison. It’s true. 

Natalie: Exactly.

Gina: And I should say, you know, at Postlight we say we’re lower-case agile. You know, we’re not rigid and to the book about every…

Natalie: We’re not dogmatic.

Gina: We’re not dogmatic, we’re not like every ceremony, every point. We don’t follow Agile actually to the letter. But it is, it is a mindset, and it’s a way of working, that being open to the idea that we don’t exactly know where we’re going. But we also do work for clients.

Natalie: Mhm.

Gina: And we have one particular agreement structure where, instead of the client paying for time… you know, a team over time, they’re paying for a deliverable. So we have to ship a thing for a certain amount of money by a certain date. Right? And that’s a really good setup for the client ‘cause they know, like, “My budget isn’t going to blow up and I know I’m going to get a thing in the end.” We bear the risk of managing the scope and making sure that we are delivering by a date. And so, it’s funny because I’ll have people say to me, “I don’t understand. How can you be agile…”

Natalie: Right. Yup.

Gina: “…and have a deadline that you’re definitely going to ship a thing? You don’t know what the thing is, and you don’t know how long it’s gonna take. How does that work?” And so, this is something that I think, we really built this muscle over time. Not gonna say that we’ve gotten it right every time, ‘cause we definitely have not. We’ve had some… we’ve had things gone off the rails in a totally… you know, and we bore the financial repercussions of that. That’s part of it. But most of the time we do get it right. And, you know, big fundamental change like that. Going from documents with messages to messages with documents. And I saw you go, like, “Is this feasible, is this possible?”

Natalie: Right, right.

Gina: ‘Cause we’re always working against… there’s always a deadline looming, right? There’s a stakeholder expecting. How do you know when it’s worth saying “Hey, we really need to do this,” or when you say “You know what? This could be better, but that’s gotta be the next phase.”

Natalie: Yeah, absolutely. It’s a great question. It is… and again, this comes from day-one mindsets and conversations with the client, and how do you sell the project? You know, so the case management system, it was fixed-budget fixed-time, that we were working within. There were certain things that this thing had to do. And, you know, and this was also a complete cut-up. We were cutting up one system on one day and starting the system… there was no integration, there was a huge NDA. You couldn’t see any code, you couldn’t see a single screen. 

Gina: Wow.

Natalie: You couldn’t see anything about the system that existed. We were making a movie adaptation of a book we couldn’t read.

Gina: Oh my gosh, yeah.

Natalie: Right? So it was, we were very much relying on other people to describe what it was that they needed and what they were doing. So it wasn’t… but the first thing was, you know, there were certain things this thing had to do. You had to be able to submit a document. You had to be able to digitally assign a document. There were core functions that we knew had to happen, so we mapped those out. Right? That was a pretty straightforward thing. And then there was the nice-to-haves, the things that like… these would make my job easier to have, but there’s a manual workaround if I don’t have that day one.

Gina: Right.

Natalie: That was kind of another bucket of things. And then there was, like, the extra-fancy shiny “These would be lovely to have, we don’t even have them in our current system…”

Gina: Right. But if I could have a pony, this would be the pony.

Natalie: Exactly. And we went through this very specific MVP exercise of “good, better, best,” because the thing is, saying “I can assign a document online,” there’s a good, better, best version of that.

Gina: Yes.

Natalie: In terms of what I do, right? Is this a huge, like, Docusign integration? Or is this a simple, “I can sign a piece of paper and then take a picture and upload it”? That’s still a way of getting a digital signature. It’s not a good way…

Gina: Right. Right. (Laughs)

Natalie: Right? But it does get the job done. And so, we went through each of these features and kind of looked at, what’s a good/better/best implementation of each of these? And then worked with the product owner to go “Okay, which of these is the most important?” Right? In that case, because we’re dealing with a lot… I mean, this is a system that every person in America could be touching, and… so a huge user base, with huge varying degrees of technical acumen, that good version was not a reasonable version. Right?

Gina: Right.

Natalie: That was one where we had to go to best. But there were other things where, okay, you can’t do that day one, we’re just going to do the good version. So we really went through and ranked all of these things. That’s where the scope comes in. That’s how you rein it in and go, “Okay, what do we think is feasible in this one-year delivery that we’ve promised?” And you constantly re-evaluate that. That’s the other piece, is… it was teaching our product owner, what does an MVP really mean? And it’s literally, “Can I do my job?” Not “Can I do my job well?” Not “Can I enjoy doing my job?” Not “Can I do my job easily?”

Gina: (Laughs)

Natalie: Right? It’s like, I relate it back to a car. A lot of people, when they talk about MVP, they’re like, you know, we’re not talking about leather seats, we’re talking about cloth seats. And to me, an MVP is like… there are no seats of a car. 

Gina: (Laughs) Right.

Natalie: What do you need in order for it to be a car? You need a way to steer, you need a way to go, you need a way to stop. And, you know, you need tires, like a thing to go on.

Gina: Right.

Natalie: That’s it! If I’m standing there, there’s no seat. There’s no windshield! Right? Like, I’m not…

Gina: Right. (Laughs)

Natalie: Like, that is a true MVP, is, what is the very, very basic thing we can define a car as?

Gina: Yup.

Natalie: And then once that’s built, then you start adding on those other layers. So once we got that done, we went back and started adding in those other layers. But that’s how that scope is. You’re constantly re-evaluating that and going “Hey, listen. We hit this feature and it took us twice as long as we thought, so now we have to look at the rest of our runway here and go, what are we going to give up? What are we gonna take from a best back down to a better, because we can’t accomplish it?”

Gina: Right.

Natalie: Right? So it’s that constant re-evaluation. So, it’s the same thing. Whereas if I say up front, “This is exactly what you’re gonna get up front,” and I’m gonna list out all of these details and all of these implementation things, you’re actually hurting yourself in that type of engagement. Because you don’t know how long any of that’s going to take. So you have to stay flexible.

Gina: And you don’t know if those are the most important things to make an MVP, right?

Natalie: Right. And that’s the thing, is there were times when we thought something was really important and it had to be the best version, then we talked to users and I’m like “No, the good one’s fine.”

Gina: Right, then…

Natalie: “I don’t really even need that, I don’t really need that.”

Gina: Oh, “I don’t even really need that.” Oh, my God! (Laughs) I mean, that…

Natalie: That is the best.

Gina: That is a gift… you’re just like, “Oh, okay! So then we can do the stuff that you really do need.” Right. But in a waterfall scenario, that’s on the specifications list, you’re designing and building it. 

Natalie: And then I design it. Right. And then it gets implemented, and that’s the wasted time. Right? Building things you don’t need.

Gina: Right.

Natalie: Or that don’t work. Or that don’t meet the user needs? That’s the wasted time.

Gina: Right. That’s the real waste.

Natalie: Exactly.

Gina: Do you have any advice to folks who, you know, designers or even engineers and product folks who are still in that, sort of, that waterfall context? Like, changing a mindset… (Laughs) From the get-go of a project… it’s huge. And this is something… a lot of our clients are very savvy and quite modern, and I mean, let’s say the truth. Agile’s been around, it’s been, like, 20 years, right? 

Natalie: Yeah.

Gina: It’s not, this is nothing new. But I think there’s still that sort of house-builder mindset. Right? Do you have any advice for a team or a product owner, to help to change the way that folks think about…? ‘Cause I think it can be really scary, especially for someone who’s, like, writing a giant check and has never made software before…

Natalie: Yeah.

Gina: …to be like “What do you mean, you don’t know what we’re gonna get? Like, what’s gonna happen at the end?” (Laughs)

Natalie: I think that all comes into the, we’re going to figure out the what, but we’re not going to figure out the how. It’s focusing on solving a problem. So instead of saying “We’re going to deliver this feature,” or “We’re going to deliver this implementation,” it’s “We’re going to solve this problem. We are going to allow users to be able to digitally upload documents.” Right?

Gina: Yes.

Natalie: I’m not going to say how we’re going to do that upfront. That’s the part we discover. So it’s that, what problem are we solving? And I think even when you’re talking about deliverables-based projects, even from a very small perspective, I try to shy away from anything that’s saying, like, “We’re going to deliver you a journey map and a service blueprint and five personas, and…” I’m not just gonna deliver that because I said I’m gonna deliver that. And oftentimes you box yourself into, I get in there and that’s not really what I needed to do.

Gina: Right.

Natalie: And so, what I would prefer to say is – this starts again from that very first conversation, contract – is, “What I’m going to deliver to you is an understanding of your users and their needs. How we do that, we’re going to figure out together.”

Gina: Right. In the format that best suits you, right? Is most appropriate.

Natalie: Exactly. Or your users. Or the timeline. Right?

Gina: Right.

Natalie: Because it might be like, you know what? In our timeline I only have three days to do that. I’m not gonna build you an entire blueprint in three days. 

Gina: Right. Why spend our time on that? What can I do? That’s right.

Natalie: Exactly. And so, it’s really focusing on, what’s the outcome, not the output? Focus on the “what” up front, and the “how” develops as you go. Right? And I think that’s the key mindset change, even as a designer. Even thinking about, you know, “I know what I need to do. Okay. I need to create a checkout experience from start to finish, right?” That’s the what. How I’m gonna do that… I’m not gonna say how many screens it’s gonna take, I’m not gonna say “Are we gonna accept Bitcoin up front?” 

Gina: Right. (Laughs) Oh, boy. Yeah, that’s a low-level detail. Yeah, exactly.

Natalie: Right, exactly. But all of those things emerge. And it requires the entire team to be on board, right? Because it requires a really strong PM to be communicating with your PO and with the client every step of the way, to go “Listen, we didn’t promise you we could do Bitcoin, we promised you a shopping cart experience. And we’re going to figure that out together.”

Gina: Right. That’ll serve your users. Right. (Laughs)

Natalie: Right. But it’s also a really good way of building in collaboration with your client.

Gina: Mm. Mhm.

Natalie: Right? Like, you have to collaborate with your client if you’re now figuring out the “how” together. There’s no choice.

Gina: Right. That’s right. ‘Cause you have to understand and learn, like, does this checkout experience… are all your customers using Bitcoin? Okay, then let’s have that conversation. Like, we need to learn about that.

Natalie: Yeah, exactly.

Gina: The defining the what versus the how… it’s such an excellent point, and you know, when we write our Statements of Work, our SOWs for our clients, we really try to just say the what. And it’s usually, our agreements, our SOWs are typically short and pretty simple, and are not these long lists of requirements. And you know, there are times when we’re dealing with large sums of money and abstract ideas of software.

Natalie: Mhm.

Gina: So there are times… and we have a, “Deliverables during the discovery phase may include…” (Laughs) You know?

Natalie: Yeah, exactly.

Gina: You know, like, “These are some common deliverables. A clickable prototype, a working MVP.”

Natalie: Yeah.

Gina: We will include, you know, so, “Activities and things you might see along the way.” Because I think on some level, you know, you want to reassure the client that this is…

Natalie: “You’re going to get something.”

Gina: “You’re going to get something,” right, exactly. And this is the way we work, and these are the deliverables you will see. But I’ve definitely had folks say to me, like, “How do you… when you sign an agreement, a legal agreement to deliver a ‘what’…” (Laughs) When it can be interpreted in lots of different ways. You know what I mean? You don’t want to get yourself in a situation where the idea of what we think we’re promising is different than what the client thinks we’re promising. And this is why that continual kind of scope management and discussion, “What are we trying to achieve? What is that outcome? What is the problem that we’re solving?” Okay. Now everything that we actually build and put our effort into has to be squarely behind that. You know? And the minimum version of that. I think a lot of people use that term, MVP, but the key, “minimum.”

Natalie: Minimum. 

Gina: Like, is a key word there.

Natalie: Yeah, no. And again, all of this comes back to that very original, like, how do you frame a project? How do you talk to clients about the project? A lot of it’s educating them at the beginning about how this all works. I’ve responded, I’ve been part of teams that have responded to RFPs where it’s like, “Here’s a thousand-point requirements document and this is what we’re asking for.” And it’s like, I just… that’s what makes me shudder. Unless that’s a time and materials project where I’ve got, you know, five years to execute?

Gina: Right.

Natalie: I’m gonna be really, really wary about, you know… that’s a lot of expectation to cram into something that you have no idea how long it’s going to take. Exactly.

Gina: And you don’t know, you don’t know how this is going to go. That’s right.

Natalie: Exactly. Again, this comes back to the very beginning, too, of how companies even solicit vendors. Right? How are they writing their RFPs? How are they going after vendors to work with, and how are they positioning their products? So again, all of that influences all of these downstream… how are you gonna execute? 

Gina: Yeah, and it’s funny. When you see an RFP, which is a request for proposal, from a manufacturing company or a transit company or the kind of company that builds physical things that follow very much the waterfall, you know, I think that often, they “Well, software must be the same thing, right?” Gotta write out all the requirements up front.

Natalie: Yeah.

Gina: So, you know, no one wants to waste time in rework, but what I’m hearing is, I mean, rework is part of the work. It is the work. 

Natalie: It is. It is the work. It’s a part of doing the work well.

Gina: Alright. I’m gonna try to absorb that, and really… (Laughs) take that in.

Natalie: (Laughs) Take that in.

Gina: When I find myself doubling back and having to redo something and it happens to me…

Natalie: Yup.

Gina: I’m not an engineer anymore day-to-day, but it happens to me certainly in lots of different things.

Natalie: Right. But you learned something from that.

Gina: I learned something. I learned… I got a clarity of thinking, “Oh, this doesn’t work, so let’s go with something that does.”

Natalie: Right. Right. But finding a way to make that as fast as possible, right?

Gina: That’s right.

Natalie: That’s where… not doing it all up front and then finding out you did it wrong, and having to redo the whole thing.

Gina: Well, thank you so much Natalie! I love having you on the show. We’re gonna have you on more often.

Natalie: Thank you! Please do.

Gina: This was a great conversation. If you are listening to this and you’re thinking, “We need a little bit more of this. We need a little bit more of this mindset, this kind of agile mindset, in the way that we get our projects done.” Oh, we love this stuff. Please get in touch. Send us a note, hello@postlight.com. We all read every note that comes in. We love to hear from you. Send us a note! Thanks again, Natalie. Great to see you.

Natalie: Thank you! You as well.

Gina: Alright. Bye.

Natalie: Bye.

[POSTLIGHT OUTRO MUSIC]