How Do We Effectively Work with Product People?

About this Episode

How do we work effectively with product people?

Transcript:

DAVID: Hello and welcome to the Acima Developers Podcast. I'm David Brady, and today we've got a huge panel. It's going to be awesome. We've got Mike Challis and Ramses Bateman. We've got David Solano. We've got Afton Call. We've got Kyle Archer, and we've got JP Porter with us today.

And today, we're going to talk about working effectively with product people. And we actually went and got ourselves some product people. We have Jeff Madsen and Tyson Novakovich on the call with us. So, you guys know that I like to start with just the topic of the call is the opening question. How do we work effectively with product people?

MIKE: I've seen it work well, and I've seen it work not so well. I'm going to point out that Jeff Madsen, who's here he's visiting us, and he's from outside of Acima. And so he's our guest product person today. And I've had great experience working with him on the product. So he's an example of how things work well, as is Tyson, actually.

And I've had other times where it's worked badly. For example, I worked at a place where there were product people who would spend weeks writing up lengthy technical documents were essentially unreadable and would hand them off to us and say, "Okay, can you go build this?" And then we wouldn't hear from them again [laughs] because they [crosstalk 01:21]

DAVID: And if you have any questions, read the document harder.

MIKE: Yes, that's exactly how it was. And I would argue that that's an example of how things should not go. And I think that illustrates how things should go, and the difference that I've seen with some of the great product folks like we have on the call with us.

JEFF: I can promise you, as can most people on this phone call, you do not want me writing technical documentation. That is not going to go well. When Mike says unreadable, he means it's in a completely foreign language that is not English or technical. It's in a garbled mess. And so that is not what product should be doing. And I totally agree.

So, I was thinking about how do I want to prepare for this and how do we want to move with this? And it got me thinking about one of the things that made our team the fact that we worked so well together is we kind of divided up what are the things that it takes to build good software? And we had a really strong technical team that's represented by everybody on this phone call, besides Tyson and I.

And then we needed a team that could go and say, you know, what do people actually want? What would be useful? And when I first started, Mike, Afton, I think you two are the only ones that would probably remember this. But there was a pretty rigorous every week we meet, and every week; we write stuff down in a backlog. And every week, we add more to that backlog so that next week, we can ignore what we wrote in the backlog and then do something else that was more important. Does that sound familiar?

MIKE: [laughs] Changing priorities?

JEFF: [laughs] Yeah. And I think what we all kind of accepted is that I don't know what two weeks from now is going to look like. I don't know what tomorrow is going to look like for now. So let's focus on what's the most important for today. And what's most important is, what problem can we solve together that's going to drive business value as soon as we can? Tyson, what do you think about that statement? Like, if that's product's job is to work with development and say, "What problem can we solve together today to drive value as soon as we can?" What do you think?

TYSON: I think it goes back to the...how I think about it is deciphering what the business actually wants. Because they're going to say they want this idea, like, hey, we want to improve this application throughput, figure it out. Or we want this fancy new button that does all this stuff. Can we build it? You're like, oh, actually, no, you want to do X, Y, and Z. It's much smaller pieces. In this big sweeping change, we can, you know, improve it by we as product decipher that, so that when we go to engineering and work with the developers, it's not, hey, can we build this exciting thing? It's hey, here is this idea of what they want to improve.

But then it's very much so a conversation between product and development, like, what ways can we do this? You know, we'll probably come up with some ideas of things we can change. But, I mean, developers are interacting with the code and how features work 24/7. And so it's...they'll have their ideas. And I think it's very much so a conversation between the two groups. That's kind of how I see it.

MIKE: Both of you pointed out something that stood out to me, and it kind of goes back to startup culture, to a degree, that, yeah, there might be different priorities each week, and that's not necessarily wrong. Now, maybe every week, that is wrong. [laughs] If you don't have the flexibility to change, then, you know, if you'd say, "Hey, we know exactly what we're building, and we're going to work on it for the next three years as a startup without any ability to be flexible," you're probably going to be out of business in six months.

That flexibility is vitally important when you're small but sometimes companies forget that when they're larger and that agility, I think, retains its value. Maybe you have longer time horizons that you can work with. But that doesn't change the fact that we're not very good, to your point Tyson, about building a big thing. Nobody is in any context.

I don't think anybody says, "I'm going to build a skyscraper. Step one, build a skyscraper." There's an art, and much of the art of what we do is figuring out that sequence. And I love that both Jeff and Tyson talked about that sequencing, like, well, yeah, you want a skyscraper? Great. We might need some materials. We might need a foundation. We might need some contractors to work on this. We might need some bulldozers.

JEFF: The other piece that Tyson [inaudible 05:35] great bit by bit, right? Is a lot of times, people will come and they say, "I want a button that does these 17 things." And when you start adding in here's the first thing, here's the second thing, usually by the time you get to the third or fourth action, it's good enough. We jokingly use a phrase where I work now, is it less worse, right? Like, the goal is to get things to be just a little bit better than they are. And usually, by the time you're not completely finished with a product or completely finished with development of a feature, it's good enough to move on to the next most important thing.

And when we started this call, we were all kind of joking about Mike, your time horizons, right? That you brought that up of being able to be agile and not be locked down. We were all kind of joking about how we've all worked at a company that's moved at an incredibly slow pace, and it's because we try to plan. We try to figure it out. We do one deploy a year, or we do one deploy a month. Everything is so time-driven, as opposed to user impact-driven.

And I think one thing that I appreciated most working with this team was Tyson, or I could come and tell a story, and we would say, "Here's what's happening. Let me give you some context so that we're all working from the same shared understanding." We would tell a story. We would then say, "Here's the problem with that story. And what we're actually trying to get at the ending instead of Little Red Riding Hood's grandma getting eaten by the wolf, we actually want Little Red Riding Hood to show up a little bit early and be able to save the day."

So we tell a story about a new future that we all want to live in together. And we go, okay, well, if you just want Little Red Riding Hood's grandma to live, there's a ton of ways we can get there. Let's talk about some of them. Here's an idea. Here's an idea. Here's an idea. And so then it becomes a mixed bag of here's what I can do. I can build Little Red Riding Hood's Grandma a skyscraper. And I can put her on the top floor with a bunch of security guards in between. Is that really what we want to do? Because that would take a really long time.

Or why don't we just tell Little Red Riding Hood's grandma not to answer the door? That might be the easiest thing, and that requires no building. That requires no development. But it gets us to the right outcome. But talking about all of these things collectively and saying, you know, there's a spectrum of right answers that require X amount of dev effort and time, which equates to money and a delayed satisfaction for the end user. And then there's some that are different options that are out of the box where it's just, hey, send grandma a text message to say, "Hey, I just saw a wolf. Don't open the door."

So talking about a lot of those things makes it so that the team can come up with a solution and then work together. And now you're all pulling a cart in the same direction. I think, like you mentioned, somebody goes off into a corner, you know, previous jobs. They write a bunch of technical documents, drop it off on your desk, and disappear. And that's probably the least helpful thing because you don't know anything that went on behind the scenes. Why are we even asking for this? Is this the actual problem we want to be solving? And I have 7,000 ideas that I could just tell you that if we cut out a ton of this, we'd still get to the same spot.

DAVID: Now I've got this idea stuck in my head that there's a meeting. They're going around the board to solve the Little Red Riding Hood problem. And these suggestions are thrown out. And then finally, like, the VP of engineering says, "All right, look, we've got budget for one more headcount, so start talking to me about woodcutters."

MIKE: [laughs] The nice thing about this is if you're being conscious about costs and thinking about that and what is actually driving value, maybe you could use that budget to hire somebody different because you don't need the woodcutter anymore. And, you know, you can avoid some of the trouble and hire more effectively.

I love how Jeff and Tyson talked about reframing the problem, that they both talked about telling stories and then jointly coming up with a solution. Now, the developers are going to understand the technical details and be able to come up with technical solutions. The product side is coming with a vision of what the problem is. A lot of times, the developers are kind of divorced or isolated from what users are actually experiencing. They don't necessarily know what needs to be worked on.

Product is, you know, their job is to know very much what that is. So they're bringing this tremendous value of knowing what is needed, but they don't necessarily know how to build it. And developers, on the other side, they know how to make stuff, but we're not quite sure what to make that's going to be valuable for the company. And when those two meet, then you can come up with a shared vision that is significantly better than either could come up with alone.

JEFF: To piggyback on that, Mike, I think one of the things that I've noticed, you know, we're talking about the difference between great product managers and product managers that are getting started and trying to figure out what's next for them is I think a great product manager can tell you why they're asking for something. They can say, "The user wanted a button that sent unicorns, and laser beams, and a pot of gold with a leprechaun at the end of it." But why did they want that?

They've gone in. They've spent time with the user, and they've spent time with the person who's asking for this new thing. And they can then come back and say, "Hey, development team, like, there's this pain that's being felt by a user, and they want to solve it. This is what they asked for. I have some thoughts. Here's what I think it is." But let's pause for a second and say I can tell you why.

The second thing that I think a great product manager can tell you is where does this fit in terms of the urgency, right? Like, hey, actually, this pain is bad, and it's getting worse. Something's happened where we have changed a piece of code, and now things aren't going the way we thought, or a new business requirement has come up. We have a new client. And so they can tell you why and where it fits in the priority. And then it's that joint effort to get to the how.

Mike, you and I used to always talk about there's the right way. And if we were to do this the right way where we went, like, full technical build out, build the full framework and the structure, it would probably be about this long. I think it would take this many people, you know, highest level, I don't know, ballpark. Let's think about this. And then we would talk about, okay, well, what's the fastest route?

And I think it goes back to, I mean, one of the things that always comes up, and I feel like it's a point of friction between product and development, is, well, what you're asking me to do on the timeframe I'm doing it on it is unfeasible. And I'm going to build an unstable structure. And I'm going to create a bunch of technical debt. And understanding that as a product manager is significant because things that are fragile break, and things that aren't meant to be scaled will inevitably be scaled.

I don't know how many times I have said, "It's going to be just this one customer. It's going to be just this one thing," and then all of a sudden, you turn around two weeks later, and sales is asking for ten more people to be put on the same thing. And so, Mike, we always used to talk about this technical debt is it, am I putting this on a high-interest credit card? Am I putting this on a low-interest subset? How am I going to have to pay for this debt if I'm not doing the ideal because it doesn't drive the value on the timeframe that the business needs? How am I going to have to pay for that later?

MIKE: And sometimes when you have those discussions...you mentioned the text message [laughs]...that sometimes when you're in a pinch, the right answer is maybe neither of the above options. But maybe when you understand what the needs are, there's another way to meet those needs that maybe doesn't build the right solution but doesn't build the wrong solution either but builds a minimal solution.

You know, particularly when you're in a startup-type situation, you've got a limited budget and limited time, right? If you don't move quickly and efficiently, you can go under. And coming up with a creative or an innovative way to approach the problem that maybe is unexpected can actually solve the problem without leaving much technical debt, or maybe no technical debt without building the big, grand solution that you originally envisioned.

I watched a documentary once about the famous Skunk Works Program that built a lot of the well-known military aircraft. And I'm not, like, an enthusiast, so I know not big. I mean, it's interesting, [chuckles] but I'm not going to know all of the technical details. But one thing that really stood out to me is some of the things that they did when they were building these airplanes. For example, they wanted to build a spy plane that could fly really high. And, to do that, they had to have wings that were outrageously long, and they drag on the ground.

So what they basically did was stuck a bicycle wheel onto the end of each wing and said, "Well, maybe someday we'll come up with a solution," and they never did. They put it into production, and they just put a bicycle wheel under each [laughs] of them, you know, with, like, a unicycle under the end of each the wings, which kept the end of the wings off the ground. And when it took off, the wheels just kind of rolled and tipped over and the plane took off. That's all you needed.

They had a plane that needed to go so fast that the materials used to build it would deform. And, on the ground, it was leaking fuel, just dumping fuel. At heat, it would expand, and it would close up, and the fuel lines would close, and everything would be fine. But when it was stopped, fuel was just pouring out of the plane. And they thought, what are we going to do about this? And, eventually, they just did nothing. They just filled it with fuel, let the fuel dump, and took off the plane, and when it got into the air, the fuel stopped dumping. Sometimes the things you think you're going to need you don't necessarily need.

JEFF: I really want to meet those test pilots, you know, the guy who gets into the airplane as it's dumping fuel on the ground and says, "Yeah, let's hit it." [laughs]

DAVID: I want to say I read somewhere that that particular plane takes off with about 10% fuel reserve. Once they take off, they punch the throttle and do a couple of laps and wait for the plane to heat up. And then they go refuel in the air. That was the one workaround for how do we keep this from dumping, you know, all 20,000 pounds of fuel? Just put 2,000 pounds of fuel in it until we can get it hot. That was the SR-71, right?

MIKE: I think that's right. Yeah.

JEFF: That example just goes back to, like, how do you work together to build a product that functions? You're going to go in with a bunch of assumptions. Everybody will, right? Well, I think I can do this, and I think it's going to work. And, Dave, your example is just, like, when you're talking about product development iterations through this and, like, okay, well, we know that the properties of this metal will expand. We know that this will actually close up when we're at speed. But, well, great, but now how do we get it in the air?

And I think it just is another testament to product and development we need to work together to solve the most high-value problem that's in front of you today. Whether you're at a startup and that high-value problem is we need to figure out how to make more money so the business exists, or you at a giant enterprise and you're trying to say, okay, what I'm doing is actually going to be a little bit different. It's not maybe life or death for the company, but there are things that matter there.

And there's different levels of priority, and being able to sift through those together and make things less worse, right? How do we progress together on solving the most important problem? And there's creative solutions of how do I get fuel from leaking out of the plane? Well, just don't put it in.

MIKE: And you talked a lot about priority, Jeff. Are you saying that we should always be working on the most important thing? [laughs]

JEFF: Oh, if only that were true, Mike. [laughs] If only we could live in a world where that was the ability, right?

MIKE: But, somehow, it's really easy to work on things that maybe aren't the most important thing because they're in front of us. We get myopic. We work on the thing that we're seeing rather than the thing that we should be doing. That process of prioritization you're talking about means that we actually do work on the important thing, and that is such a huge deal. And it's hard. It's hard, and it's hard to get right.

JEFF: And it's continuous as well, right? Like, we've talked a lot about airplanes. Every few months, there's this story about the Air Force was looking at all the planes that were coming back and trying to figure out, okay, where do we need to add more reinforcement for their armor? Okay, well, this one came back, and all the wings were shot up, and this one came back, and the tail was shot up, and this one came back...And we need to add more reinforcement for the cockpit so the pilots all feel safe.

And then somebody said, "Let's look and see where are we not seeing any damage because those were the planes that aren't coming back. Like, where are planes getting shot, and they're going down, and we're never getting people back?" And I think that that process of trying to ask the opposite question, trying to figure out, I see that all these planes are coming back, and they're just filled with holes. Okay, well, that's great. If you're trying to protect pilots, let's not patch all those holes. Let's go and say, "Where did they get hit, and they didn't make it?" You have to think about that. It's a deliberate action that you're trying to go through.

And listening to the users on the product side is incredibly important. But you have to listen to what they're not saying. You have to listen to what you're not seeing. You have to listen to...and try to find the rest of the story, and that is where you can pull more of the priority. And we talked about technical debt and things like that. And that's...from a product perspective, the development team that you're working with, the people that are helping you build, you need to listen to them as well. When they say something's about to fall apart, you should listen.

Like, I think that's...part of the challenge is there's lots of different theories and thoughts on how products should work. And if you're the CEO of the product, or you're the final decision maker, or you're the voice, you know, there's a lot of these things. And the answer is a little bit of all of them, right? You work with your user in the business but also work with the tech side to make sure that you're not neglecting your monthly investment in paying down your tech debt.

Making sure you've built stable code, making sure that the thing that you said as a product manager or the thing that you lied about as a product manager and said, "Only one person is ever going to use," and now there's 1,500 people using it. Is it still going to work? Like listening and pulling and trying to put all of that together and asking people, right? Like, we talk a lot about...I call it the trade-off game. Because every time you choose to do something new, you're choosing to not do something else.

And making those decisions clear for everybody of saying, okay, if we're going to take developers and put them all on these projects...Mike, you and I would talk about this quite a bit of saying, okay, this means we're not investing in our tech debt for a while. Mike, what does your gut tell you? Is that okay? You know, like, are we going to be all right? Are we going to get sunk? And then you go to the business and say, "Hey, we've ignored paying our tech debt for so long. We can't do that anymore. So I can work on this new feature for you, but that means that everything we just pushed out is at risk because it's not scaling well. It's not growing well."

MIKE: I have some thoughts about how that tech debt ought to be handled. But I'm going to pass on those for now. [laughs] I'm going to throw out there that it's good to make that credit card payment every month.

JEFF: And, ideally, more than the minimum, right? Like -- [laughs]

MIKE: Yes, exactly.

JEFF: [laughs] Yes, yeah.

DAVID: I actually have a question for you, Jeff. And some of the devs on this team will go, oh yeah, I've been there. I've worked on teams before where the product owner has come to us and said, "Here's what I want built. Here's how I want it built. Here's the problem I want to solve. Here's how I want to solve it," which should be a red flag, by the way, because it's the engineers' job to figure out how we're going to solve the problem. But the thing that we get presented from product they basically say, "Here. We need all of this," or "It's not worth shipping any of it."

And so when you come back and say, "Okay, well, can we break this down by priority?" And they say, "No, everything is the top priority." I wish that was a joke. But I really have worked on multiple teams where that was the thing. And so I'm like, well, from agile, we're going to break it down by priority. I guess what we're going to do is we're going to start at the top of the stack and just move...the priority is arbitrary.

And I've noticed that those two things go hand in hand. The backlog is on unprioritized or unprioritizable. And product is just saying, "We have to have every single card in the backlog done because, at 99%, we do not have a viable product." Help. [laughs] That's my question for you, Jeff. Help. How do we get around that?

JEFF: There's a concept...and when you said the backlog every single card has to be done, there's a concept that is brought up in a book called INSPIRED. It's written by Marty Cagan. It's, I mean, anyone who is looking at getting into product or how, you know, figuring out how to do this or how to build...The title of the book is INSPIRED: How to Build Tech Products People Love. And I'm going to take a wild swing at this, Dave, and say it all starts at the very, very beginning. When you put something in a backlog...the concept that is introduced in this book is called a validated backlog.

One of the things that we've actually done at the company I work now is we've separated out where did the ideas go, and then where did the good ideas go? Where did the actionable things go? And we spend a lot of time sifting through the ideas. We have a separate place. We have a separate container. We use a totally separate tool than what is the development backlog.

And the reason why we do that is because, from a product perspective, anything that we throw into a backlog for development that sits for more than maybe a month, I'm now questioning the validity of it. If it could sit for a month without doing it, why did we prioritize it in the beginning? So you got to go back and look at that. So going back to this other holding ground, you got to sit and think about these things.

And it's only once you've figured out, once you've worked with users, and once you've talked to them, and once you've asked them...We're actually going through this process right now. We're trying to develop...we're going from zero to one, no mobile app to a mobile app for an end user to use, a consumer-grade mobile app. Well, if you look at any mobile app, it's got your user settings, your notification settings, your preferences, your dark mode, your display, you know, there's, like, 75 things that are just kind of given, you know, my air quotes, "given" for a mobile app that arguably drive no business value.

And so what we have started to do is we're trying to get into this validated idea portion. And so we have some assumptions about what we think people would want to do most often with that mobile app that we're trying to build. And so we're building out, and we're spending time. We're saying, okay, let me put myself in a day in the life of the end user of this and say...so I work for a travel company, right?

So three days prior to me taking a trip, what would I be doing? The day of the trip, what would I be doing? While I'm at the airport, what would I be doing? Once I'm getting ready to go to my hotel, you know, so we're trying to go through and identify these core events or these key milestones in this journey and saying, what would I be doing? What would I be doing?

And we're saying, okay, I want to be able to manage...get alerts about my flight delays. I want to be able to pull up my hotel reservation really quickly. I want to be able to make sure that I'm getting my SkyMiles points so that I can get my next flight for free. There's all of these things that are happening. But when do they happen, and how do they happen? And then we actually are just creating a big list of them.

And this is where I think product rolls up their sleeves and figures this out. This is how you get to why does the problem need to be solved and in relation to what? Because we're actually going out, and we created a bunch of surveys and said, "You know, here's the seven things that this mobile app could do. How would you rank them, user?" Let's go ask 200 people. "You're a traveler. How would you rank these?"

And then the next question is, okay, if you couldn't do the thing that you put at the top of that list, like, if you have a travel app, and this sounds kind of weird, but what if you can't book a ticket? What if you can't book a flight? What other collection of pieces would provide enough value for you to download this? And so now we're getting this user feedback, and we're pulling in these stories, and we're saying, okay, I'm going to change the game a little bit for you, user. I'm not going to give you your number one thing. Would you still use it? If so, why?

And now we're starting to be able to get some layers and some nuance and some differentiation between it's not these seven things are nothing. This one thing carries a ton of weight, but it just so happens it's the most complicated. It's the hardest thing for us to do. But if we can give them these two or three things, there's still value. And we can start trickling this into the market and getting users slowly and iteratively, and adding more and getting their feedback.

And maybe that idea that we had to solve or build feature number two, number three, and number four were totally wrong. And isn't it great to know that now instead of after the 18 months we spent building feature one and then released it? So it's that validated backlog where you can go back in.

And I honestly think that, as a developer, I 100% think that it is your right, and you need to push back on product guys. I think a lot of times we come in like the Top Gun pilots, and we're like, oh, we're totally cool, and we know everything. And we're going to tell you exactly what you said, Dave, like, here's the problem. Here's how I want it solved. Here's this, and here's how you should do it, and ta-ta-ta-ta, right? Like, pushback. Call us out. Like, we're wrong. We're human. And hold us accountable.

DAVID: I love that answer for a couple of reasons. One is the idea of validation at a granular level is beautiful. Like you're saying, if you spend nine months or 18 months before releasing the product, before validating that idea, there's an extra wrinkle there, I think, which is that you're not going to validate idea number one. You're just going to assume that the entire product flopped, and you're not going to know why. Because there's 78 ideas in there, and they're all Jeff's grand vision of the 2.0. And it flopped because things weren't...you know what I mean?

JEFF: My grand vision of the 2.0 was perfect, Dave, okay? [laughs] Because I'm infallible, right? No. I totally agree. And I think that it goes back to, I mean, maybe it doesn't flop, but maybe it doesn't work. And if I've got 78 things in there, how am I supposed to know where the issue is? We spend a ton of time talking about single-piece processing, you know, isolating the change, monitoring the change, and then knowing how to react if something goes wrong, right? Like, I want to do this big giant thing, but it's a series of steps. Okay, well, let's take step one.

Going back to the skyscraper analogy that Mike brought up, like, let's dig a big hole so we can make sure it's going to be big enough, like, do we have enough land? Okay, yeah, we have enough land. Okay, let's dig a big hole and make sure we have enough room to pour this. Now let's pour this. There's these checking spots along the way to ensure that you're still delivering the right value. And then there's always the check-in of, like, have I delivered enough value? I don't need to finish everything.

Maybe we get to the point where we say, you know, feature number one was and is the aspirational goal for this mobile app or whatever. But it turns out that the sum of the value provided by features 2, 4, 6, and 9 actually are greater than 1. And we were able to do those in two months as opposed to two years. So let's figure that out. Small pieces, small changes.

MIKE: You've said a couple of things there, Jeff, that if you push out more than one thing, you don't know which one made a difference. And you also talked about 2.0. So I was thinking so 1.7.3.9 is actually important? [laughs] It sounds like yes. And you're saying a big part of the reason for that is that if you don't push out those features in isolation, then you can't evaluate them very well in isolation. Do I hear you right?

JEFF: Yeah. And I appreciate the 1.7.3.9, like, yeah, 100%. And I think that there's this big challenge. And, Mike, you've talked about the startup life. I am super fortunate. And I really love where I work because I work at a company that's a 30-year-old company. It's been under the same ownership group for 30 years. It's a business that's doing well. I mean, it survived the travel pandemic, you know, and all of that scare. So it's a stable company. It's got a long history. We're no longer trying to say, do I have product-market fit? Am I going to make it to next month? Am I going to make it to the next quarter?

They've survived this big recent scare that was an industry-wide scare for travel in general. But what they did is they took a hard look at what they've done, and they've said, oh man, we've missed the boat. We haven't created value for our users. And so, let's pause and hit the reset button. And so I'm fortunate that I get to work at the best-funded startup, right? Like, it's a really awesome opportunity for me. I'm excited.

And what it's proven is we have a lot of stuff that's actually on version 7.0. And what we realized is that everything from 5 to 6.9 didn't drive value. And so now we're going back and saying, do I really want to go to 8.0? Or do I just want to start over and say, here's MVP, here's 0.1? And I'm going to take another attempt at trying to solve your problem. And the reason why I'm bringing that up is because I think that there's this product maturity that happens over time. And there's a lot of conversation about a minimum viable product.

And, Dave, I think that's exactly what you're hitting on of, like, how do I truly define the minimum amount of work that I can do to create something that's viable? And that is really difficult. And I'm going to kind of challenge a little bit about what you said, Mike, of like, once a product's reached maturity, it is super important to isolate these changes. But, at some point, you have to find enough things. And maybe that's a couple of different features to go from 0 to 1 or 0 to 0.5.

I think it's a totally different mindset of I've got a mature product where I'm iterating through and optimizing, or I'm creating something that's brand new. How do I minimize the amount of work I need to do to make something brand new? And so I honestly don't know. We're in the middle of trying to figure this out as well.

Because I showed up and we were talking, you know, I started a year ago, actually, this month. And one of the first things they talked about is, like, hey, we've got this mobile app, and it's going to do these 17 things, and it's going to be awesome. The dev team's been working on it, and they're still working on it. And you know what? Sadly, we're still working on it because we weren't diligent enough about minimum. It's hard to go from zero to one.

And so, I would love to hear your feedback on how do you launch something that's brand new where you do need to have a collection of features? But it's got to be the right collection that's the least amount of effort that creates the most value. So, Mike, I agree. But I think there's this wrinkle in there that's new product creation; there are a few things that you do kind of need to bundle up, or you need to find out how to balance those.

MIKE: I'll bite on that a little bit. If you're doing a minimum viable product...I've heard a quote attributed to Steve Jobs. I haven't verified it, but I believe that it's correct. It says that if you're not embarrassed by your first release, you're doing it wrong. [laughs]

JEFF: Yeah, I think that's Reid Hoffman in LinkedIn, actually.

MIKE: It's an excellent idea that you need to tamp down your vision a little bit and be just vicious in determining what that minimum actually is. And think about anything you can possibly cut. Anything beyond that is risk. I'll say that it's risk because anything you add to the bundle is extra work that you put in that you haven't validated. So I think we need to be exceptionally willing to cut anything that could possibly not be truly minimum. That's one trick.

And there's also another trick that sometimes people use, and that's the word beta. [laughs] Sometimes you can release something that's not fully viable but provides some value in a niche to say, hey, you know what? We're launching this. And you find a subset of your users that are kind of the power users. And you say, you know what? We don't have everything that we need, but we're going to try this new thing. Would you like to have this extra feature? And there are a subset of your users that probably do. They would like to try out that new feature without having all of the things. They might like just one of the things.

And you work with that group, and you're actually giving them something, right? As long as you build it with quality, you're developing loyalty with your customers by giving a subset of your customers a more valuable experience. And in return for giving them that experience, you get feedback. You get some validation as to whether that product was valuable. There's my couple of thoughts and an answer to your question.

JEFF: I love the concept of, I'm going to call this what it is, and it's not done. [laughter] So you can be as mad as you want. I totally agree with you. But we've talked to 10 or 15 of you, and you think that there's value in it. And that idea of being embarrassed, I love that paired with the beta. Because you're saying I have done the bare minimum possible, but I told you that upfront. And you told me that you'd be willing to try, so please don't be mad at me. Please be nice to me. [laughs] Like, I don't need to be embarrassed because I already told you. I lead transparency in that engagement with your users and your customers.

I think that is truly where, you know, you get the user, a designer, a product person, and a developer. And I think that combination is where you create incredible value for people. I think about Airbnb when they launched and how they were like, okay, we don't know what to do, like, you're just going to go sleep on somebody's couch? Like, that's such a crazy idea.

That entire business concept was probably kind of embarrassing for people to just say, like, oh yeah, I'm just going to sleep on this person's couch over here, but then it caught on. And now it's this massive industry that's also spun out a whole new real estate empire of, like, I now own properties that I do Airbnb rent. Like, it's generated all this stuff.

So it may have been a little bit weird, a little bit different, but they owned it. And they said, yes, this is kind of interesting. It might not be for everybody, but there's somebody who would pay for this, and let me go talk to that person. And I'm just going to tell them, "It's not done, but we'd love to know how you would change this." [crosstalk 35:43] It's always easier, to be honest [laughs] and transparent than to try to hide stuff.

DAVID: There's an interesting idea that somebody pressed me on on Twitter or Mastodon or one of those social media things. We were talking about MVP. And there's this interesting notion that going from zero to one, you don't go from a 0.9.9 version, which is in-house, and you only show it to your team. You don't go directly from there to a nationwide release, to the open market, and loyal customers, and angry customers, and hostile competitors all using your product.

There's this idea that maybe the MVP goes to a much more sympathetic audience where, you know, we say, "Hey, this is beta. It should work no matter how you use it, but it's not going to, so let us know." Or you even say, "Hey, this is an alpha sketch of an idea. It probably won't work. But I think if you coax the software, [laughs] you can manipulate it and trick it into doing the thing that you want. Just be gentle with it. You can baby it. But it will let you book your travel, or it will let you order your Airbnb, or it will let you sign up for, you know, a lease in a completely new way."

And because you're showing that to somebody who's very sympathetic to you, who's very friendly to your company, they're like, "Oh yeah, I would love to see this." And then they know, oh yeah, I can't type that in there. It breaks the app. But if I do this and I do...wait, I can go from here to here? Holy crap, that's amazing. And you just validated your idea.

But you had to do it with somebody who was very sympathetic, and it was a very small release audience. And that's somebody that you can hand a 0.1 to, and you can tell them with a straight face, "I want you to try this and tell me your thoughts. It's probably not going to go into the final product. I just need to know if this one idea works or not."

JEFF: Yeah. Find your friends, your friendly customers.

DAVID: [laughs] I like it.

JEFF: Yeah.

DAVID: It's like Airbnb but for beta testers.

JEFF: [laughs]

DAVID: There's a business idea. This has been a fantastic discussion, Jeff. Thank you for coming. We lost Tyson partway through. Unfortunately, he's busy.

JEFF: Thank you. I appreciate it. It's been a blast being here. So it's been nice to come back and talk to everybody, hang out again.