S2 E7 | | Identifying and Making Trade-Offs as a Product Developer

Trade offs are basically constraints that you're pushed between where you can't have both sides. I can't have like it's, I think Francis Fry says it best. It's like, you know, price, quality and speed. It's like you can't have all three. You gotta pick two. And then one's gonna have to actually not be what you want because it's just not possible.

Welcome to the Circuit Breaker podcast where we challenge the status quo of innovation and new product development. We'll talk about tools and skills and methodologies used to build better products and make you a better consumer. I'm Bob Mesta and I'm the co founder of the Rewired Group and I'm one of your co hosts and we're joined by Greg Engel, who is my co founder and chief, Bob Interpreter. Join us now as we trip the circuit and give you time to reset, reorganize and recharge your brain to build better products.

Hey, Bob.

Hey, Greg. What's up man?

So today we're going to do another continuation of deep diving through your book.

Okay.

So today we're going to land on trade offs.

Ooh, that's a good one. All right.

Well, you say that about everyone, so I don't know, I don't know if it's especially good or what's going on there. But anyway, first let's, let's just level set, you know, what is a trade off?

Trade offs are basically constraints that you're pushed between where you can't have both sides. I can't have. I think Francis Fry says it best. It's like price, quality and speed. It's like you can't have all three. You got to pick two and then one's going to have to actually not be what you want because it's just not possible.

And who should be making trade offs?

Who should be making trade offs? Well, the thing is, it's about trade offs. It's a great question in terms of, it's whose trade offs are we making?

Right.

As opposed to what trade offs do we need to make? Because I can make it from my perspective about the product. Right. But in the end it's what's the, what's the trade offs the consumer is going to make about the product or the service? And ultimately how do we actually understand and mimic their trade offs into how we design the product?

This is where, you know, and I asked the question because it's kind of a trick question, right? Because it's whoever's problem it is you have to start making trade offs.

Right.

Or you have to start doing things. But this is where the two skills kind of intertwine, right?

Yeah.

Empathetic perspective and trade offs kind of work hand in hand because you have to understand from a bunch of different perspectives what it is. And two of the big perspectives are for developers or business leaders, are between supply and demand.

Supply side, demand side, Exactly.

So how do you make sure when you're faced with this trade off and let's just make one up from a supply side and demand side between price.

And that could be margin and all those different things for that and then adding a feature or benefit that adds cost. How do you go through and make sure you're thinking of both sides and what's the practice you should be giving yourself to say, am I looking at it from both sides before I make the trade off?

And so ultimately we have to be able to see it, like you said, empathetically through the different perspectives of am I willing to pay more for that feature or is that feature going to be something that helps me ingrain the habit? Right. And so part of it is to actually understand it from the demand side, the supply side is how much does it cost? How technically possible is it, is it something that, you know is going to be something we're going to build on Pon. So it's actually kind of like a new platform. Like there's a whole bunch of different objectives from everybody's different side. And so part of it is then being able to see that whole picture. So trade offs can only be taken from almost like an omniscient or a, you know, a big picture perspective. We can't do it from only one, at least successfully.

And then the other thing that I think we run into a lot is the cascading effect of trade offs.

Yeah, the way I was told of this tolerance stack, it's the aspect of that there are multiple, it's multiple dimensions. And so you start to realize like for sometimes you're willing to give up one thing to get the other and it's. And they add up and ultimately it looks like they're making one trade off, but they're actually making five or six.

And then, so if I have to look through time and think of these trade offs of how it's going to affect the next thing, what skill is that?

So that's still empathetic perspective around, around being able to play things out through time. But you have to realize like part of the reason why I like managing or identifying and managing trade offs is the fact that it's literally the culmination of all the four other skills. Like, I can't actually make a trade off if I don't have contrast. I don't know where the thresholds are. I was talking to somebody this morning about the fact of like, well, you know, I just want to know that it works. And I'm like, that's not good enough for me. I want to know where, where does it break? Because where it breaks gives me a notion of where I like, how far I'm willing to go. It helps me with the trade off. And so without that information, it's, it's pretty hard.

How soon in the process of developing something should I start thinking about the trade offs I need to make?

I think there's like two steps. The first step is just identifying the trade off, identifying the contradiction, if you will. Like we can do this or we can do that, but it's like this is going to be hard to do both. And technologically those are places where we want to start, where maybe we can decouple it and make it lighter and stronger, for example. And that's all the TRIZ methodology. But the fact is when we can't or we don't have, we ultimately then have to be able to kind of frame it and say, what are the things that are like diametrically opposed from each other? And then ultimately which one is more important to actually satisfy.

I think one of the things that we see a lot is people that are really good at this skill or the skills in general are people that are able to bubble these things up very early.

Yes.

And maybe not have to make the decision, but at least understand the trade offs they might have to make down the road so they can learn more. Because it's about learning and understanding and seeing things sooner and sooner through your development process so that you're ahead of the curve of making rash decisions at launch. Because that's the worst time to make trade offs.

That's the worst time to make the trade offs is that you're least clear. At least. I'll say from my experience, I'm least clear because it's like, it's not panic, but it's the point of like, oh my gosh, we just got to get this out here.

Let's start making irrational decisions. Yeah.

Yeah. Well, they're rather, I'll say from a micro level they're very rational, but from a big picture perspective, usually they're wrong. Right. That's, that's really the Point I want to fix that, make that better.

Well, because you're giving somebody the out and we don't actually want to give people the out. They are irrational decisions. Because you are, you are up against that time wall that you think you have to launch and then you say, well, we're going to fix it later. And when I try to fix things later, what we know is it costs.

Us a lot of time, a lot.

More and a lot of money.

Yep.

And a lot of efficiencies on other things we're trying to do.

That's right.

So, so why not try to frame those things up earlier? And that's our challenge to people, is you don't have to make like you can identify trade offs and you don't have to make the decision right now until you get more information, but just know they're coming.

That's right.

And then know what other things happen. Because that cascade effect, that thing of, well, I'm gonna make the trade offs and say my margin is more important than anything. Well, that affects a gazillion things down the road.

Exactly right.

So if you are beholden to a line pricing strategy or something like that, it's good to know that upfront. It's going to affect all the other trade offs. You just, you make your decisions because that's going to have to be a decision that's anchored.

That's right. That's right. And so as a developer, what you and I are always trying to do is very early on is identify where are we going to have to make trade offs. We're not trying to make them, we're just trying to say, where are they? Right. Then what we do is along the way we're prototyping to learn and we're literally framing kind of like, why does the contradiction exist? We're literally using kind of causal structures to understand it. And then ultimately when we get to the point where we're ready to kind of prototype and integrate, integrate the prototype or make decisions about what to go do next, ultimately, we've been thinking about it for a while. These are one of those things where if we spend any time, we spend time on these contradictions or on these trade offs to say, all right, where should it be? And then we'll prototype like, well, if we go this way, what would happen? If we go that way, what would happen? And so ultimately it's teaching yourself to kind of make sure that I've got enough perspective on the trade offs I.

Have to make and that's what's important. There is. We have to understand and make sure we're unpacking our supply side really good. What is our business model? How do we make money? What channels are open to us, who is our customer? Then we have to know the demand side. What does that customer really want? How do those people buy? What are they important to those people? And then also we have to understand our technical capabilities. What can we really do? Because sometimes I have to make a trade off between my technical capabilities. If I have to go buy something because I can't do it, that might screw up the other two things. So I might have to make a trade off to do something that's, that's less optimal but within our capabilities and know that it will satisfy the two other buckets, but not completely. So I have to work on something for phase two or wave two, or whatever you want to call the next improvement. So it's one of these things of make sure you have all the information in front of you before you make a decision.

As well as much as information as you can have.

And you have to get it from those three buckets. Don't make it from one silo. Because a trade off made by one decision by one silo is a trade off that is wrong.

It will be revisited a thousand times. The whole point is you want to make the trade off and you want people to understand that's what it is. And like when we make this trade off, we're going to get these complaints and we're okay with it because we made this decision as opposed to like, oh my gosh, everybody's complaining about this. Like, yeah, but we chose that. So this is where like a whole back end of the process of where people react to a whole bunch of things is part of it because they don't actually make those trade offs explicit and accept the fact that there might be some things that people. Again, I'm a big proponent of the, you know, the kick ass half versus the half asshole and the kick ass half. There's still going to be complaints, but it doesn't matter.

So Catherine wins the bet. She said you were going to bring that one up and then when you bring that one up, I have to ask. That quote confuses the hell out of me every time you say it because how do I know what a kick ass half is and how do I know what a half asshole is?

Well, the thing is, what I would say is it rings true to me from my experiences of working in big corporate where they want to keep adding more and more and more Features. And it's like I can't get every feature one in. And two is I'm better off in their mind, I'm better off having eight things, eight features that are okay than four features that really are awesome that they're willing to look past the four I don't have. And so that's, and what I'm saying is time and time again, when you're actually launching new things, it's not about getting everything right, it's about getting the essence right, the right things. And that's where the demand side comes in to say what's the essence of the job?

And that's what I would say is. And that's why that quote confuses me. Because if you actually know demand, you don't have to half ass anything. You have to make trade offs of what to give them in the first phase. But it's still an awesome thing to them because you actually understand them.

So the real point you're making is that when I say it that way, I'm actually saying it from the supply side. Because the way I was taught on the supply side is you got to get it all done. You got to get it all done by this time. Well, if I'm going to get it all done, the fact is it might all not be great, but it's going to all be there. And that's what we end up kind of running at the end, to kind of get just the things we promised in as opposed to what are the essential things we really need to do. And that's again, the power of jobs helps you with trade offs because it starts with what's the customer really want? What are they willing to trade off? And then ultimately how do I, how do I mirror those trade offs back into my product based on what they're trying to do, not based on what I want to do.

Yes. And I think, I think demand, because we talk so much about non consumption and understanding and, and jobs is about finding the people that got through the wilderness and made a decision change. We're trying to help people that haven't made that leap. Right. And that's really where you get your growth is from the people that are trying to follow people that hack their way through this wilderness.

Right.

They don't know what's possible.

No. Most people have no idea.

So doing something that has four or five really good features that solves the struggle for them is immense progress for them. And then knowing that I can then add other things that I've made trade offs on today to make sure I'm balancing supply and demand. And kind of, I almost tell people, err on the side of demand, but not so much that you don't have a business. Right. So you have to have a business.

Exactly. It has to be. You have to be able to profitably service the job. If you can't profitably service the job. Like Clay would always say, you know, you got to seek profit first because if you can't actually do the job, it's really hard to cost reduced afterwards because you don't know the true value code. And Taguchi would always say, you know, what you want to do is figure out what's the absolute minimum cost you could do and then only add things that add value. And that's how he described prototyping. To learn is I want to figure out the absolute base I can do it. And then what are the things I have to actually have to add cost to add performance. Otherwise I like to go back and rework the product afterwards. Is I would. The way I was taught was that's, that's just not the approach.

Oh, and that cost you millions of, you know, hundreds of thousands of millions of dollars.

It's like it's your. The thing is, is what I'm realizing is for a long time in my life, I raced to a deadline that somebody else chose that was actually not really rational and it forced me to make trade offs. But at the same time, the fact is, is like I didn't realize that time was something I could also use as a trade off.

And I want to talk about that a little bit because we often tell people, and I know it's one of your favorite things to tell people is, is create a time wall.

Yeah.

Right. And I think a time wall is important and I think. And you have, and you have to have it. But you can't be totally driven by that time wall either because if you find things that you need to rework or you need to do things, you have to be a little flexible. So it's, it's a, it's a. What's that called? A curse and a blessing all at the same time.

Exactly. Right.

But know that you, that's also a trade off.

Right. It's for. Yeah. Using that tool is, is forcing you to make a trade off and it's forcing you like to, to, to think about it in a different way. And so I like the notion of a time wall where again you get, you set it, you said an expiration date and then like. And it forces me to eventually Go like, okay, I got to take a step back. So instead of trying to pack everything in, if I can't do it, then it's like, maybe I shouldn't launch it right now.

Yeah. And I think one of the things we've, in our coaching that we've talked to people about is go ahead and create that time wall, but make sure it's grounded in realistic expectations, realistic time, and you have some measures or metrics attached to that time wall. Because just because you hit the time wall doesn't mean you have to launch. You have to have, oh, I have to, you know, I have to make sure I'm hitting this part of my business strategy or I have to be hitting this kind of mark. You know, you have to have some kind of metrics in there to say, yes, it's time to do something.

Right. But the interesting part to me is the metrics themselves. Right. Is actually a big key because it gets back to empathetic perspective where most people have metrics based on what they planned, what we think people want, for example. And what I would say is, I always have a very different reference point. Instead of trying to look forward, I look back and say, how much progress did we make? How much progress is this for the customer? So the metric to me is about the distance they've traveled, not the gap between what I said I was going to do and what I'm going to do. Right.

Is a ma. When we're developing. And it's different between developing and launching.

Right.

When you talk about metrics.

Right.

When we're developing, I often think of the metric being in erasable ink. It shouldn't be gospel. It should be a guide, not gospel. Right. It's things we're trying to get to and the management gets to decide how hard or how soft that target is. But we shouldn't be like, I see people put this metric out there and it's some ridiculous thing that's just made up and they make it permanent ink, and there's no way to ever get there.

Well, and the other thing is, we never explore beyond where that limit is. And so it's like, well, what if we were to do this? It's like, yeah, but we could never do that. I'm like, okay, we could never do that. But what happens? And it's part of that understanding where those limits are. And so prototyping to learn is really a lot about finding the limits and what happens and where. Where. Where they are and how to pick the best target.

Well, I think. And the Reason why I bring that up is because I think about the milkshake story and I know you hate the milkshake story, but I think the milkshake story is very important because hungry. Because we tell them. The milkshake story has been told in such a way that it seems really easy. But one of the metrics or one of the things that were really important to the, to the restaurant was productivity or labor.

Well, it was actually the utilization of the.

I'm talking different.

Okay.

Labor.

Okay.

They didn't want to increase labor.

Oh yeah, yeah. As, as a reason why.

And that was a, that was a hard line and it was a trade off they made.

Well, we didn't even see it. That was. The whole thing is. We didn't actually see that until the end. Then. That's, that's the, that's your point?

That's the point is, is there. There was this thing out there that we. That was in Hard Inc. That if we would have actually thought about it a little bit more and was able to quantify. And that's the hard part. Quantify what this, what this new innovation would lead to. Nobody knew it was going to be however many billions of dollar industry it is today. Nobody knew that. Nobody, nobody could see that far in the future.

Nope.

But that hard metric.

Yeah.

Is what that one thing that nobody would speed bump was willing. Well, it was actually a brick wall.

But that one thing destroyed a, an opportunity.

Huge opportunity for at least seven.

For the first, for the first entrant.

Yeah, for sure. Into that.

That thing. So that's my point is I think sometimes we just, we have to realize that as we're developing, we're crawling along and we're trying to figure out things and it's important to have time as a constraint. It's important to have metrics as a constraint. But having open dialogue between management and the developers of what those things mean and how it impacts and being able to help developers frame trade offs for the executives is a very important thing. We had an example of a product that was launched and they had to go through certain pricing strategy and the pricing strategy was broken and the product did really well and it was gone on a year. And the reason it was gone in a year is because it actually didn't create any profit because of the strategy of I couldn't be more than this.

Well. And they wanted to get so much volume and they thought the price point could only be a fixed price point and they were trying to please the investors in terms of like they wanted Growth. And so they had all these different things but in the end it was like, yeah, there was no money. And so these are the kinds of things where you have to be able to step back. Like part of, like I said, I think of.

Making trade offs is like the, it's the, it's the integration of all the other four tools, right? The skills for other skills. And so part of this is realizing like at some point it's, it's hard to start with making trade offs, but once you have these other four building blocks, it's actually really easy to see how to make trade offs.

Well, I think that, I think the, all the tools blend together and work together and that's why it's important to try to hone them and know that you're going to be stronger in one than the other. It's not something that you know you're going to get, you're going to get some equilibrium between all of them. Right. It's going to be, some are going to, you're going to be better at. But that's the important part of having a team that maybe somebody's really good at. Empathetic perspective, the other person's good at framing the trade offs or whatever. Those are important things to, as you grow your team, especially as a entrepreneur or somebody at a startup, to understand where people might fit in the tools and how to help them get up. But also also just know that if you're not good in one, you should get a partner that's good in one.

That's right. That's why, that's why we've been partnered for 20 years.

Because that's the important thing of balancing those out. Because you don't want to be overextended in one and weak in the other, where you can't actually do something because that actually causes stagnation.

So what's the assignment?

So I think today really all it is is looking back and I want you to kind of do. And we talked about a post mortem before and if you haven't heard the post mortem one, it's the last, I think it was the last one of the first season. Go back and listen to it because I want you to now take a trade off you made in the past and I want you to do a postmortem on it. Did I have all the information that I should have had to make that trade off? What other information would I have asked for now that I saw what that trade off actually did? So kind of do a postmortem on a trade off you made in the past and it could be personal, it could be professional. It doesn't really matter because we make personal trade offs all the time. Especially if you're in a family, you're making trade offs between everybody doing a bunch of different things. So take one of those and I just want you to unpack it to or I want you to post mortem it to. What information did I have at the time, what information do I know now that I wish I had then? Could I have used somebody else as a sounding board? What are those other things I could have done to make that decision better?

Yeah, if I could do it over, what would I do differently? That's it. Perfect. Cool.

All right, cool.

Thanks man.

See you later.

Thanks for listening to the Circuit Breaker podcast. If you haven't already, please subscribe so you won't miss an episode. If you know somebody who's stuck on the innovation treadmill, please share it. If you'd like to learn more information, visit us@the RewiredGroup.com to find out how we work, how we can help Some resources, some books, some software. Join us next time as we trip the circuit breaker to help you recharge, re energize and refocus your new product development.