Bobby Moesta - Co-Creator of Jobs to Be Done
In this episode, Bobby and I explore how systems thinking changes the way we experiment, and why understanding trade offs is essential to making better decisions.
Have a Listen
Summary
In this episode I’m joined by Bobby Moesta, founder of The Re-Wired Group and the co-creator of Jobs to Be Done.
I’ve been a fan of Bobby’s work for years and instead of deep diving on yet another jobs to be done conversation with him, we explore a topic he doesn’t get to chat about very often, which is how systems thinking changes the way we experiment, and why understanding trade offs is essential to making better decisions. We chat about prototyping to learn and prototyping to verify, and it draws on lessons from his mentors, including luminaries such as Deming, Taguchi, and Christensen.
We discuss what happened to the R in R&D, and we wrap up with a fascinating potato chip experiment that reveals the gap between what customers say and what customers do.
If you are a fan of system thinking and experimentation, then you’ll love this episode.
Takeaways
Prototype to learn, not just to verify. Prototyping should help uncover what you don't know, rather than simply confirm what you already believe.
Measure outcomes, not just outputs. Start with the progress customers are trying to make, then work backward to design the systems and measurements that matter.
Great decisions come from understanding trade-offs. There is rarely one optimal solution. Testing helps reveal what you're willing to give up to achieve what matters most across desirability, viability, and feasibility.
Tackle the biggest unknowns before building. Teams often rush into execution because it's easier to work on what they know. Addressing critical unknowns early prevents costly rework later.
Observe what people do, not just what they say. Surveys and stated preferences can be misleading. Bobby's potato chip experiment showed how actual consumption and choices can provide stronger evidence than asking people what they like.
Guest Links
The Re-Wired Group: https://therewiredgroup.com/
LinkedIn: https://www.linkedin.com/in/bobmoesta/
Transcript
David J Bland (00:01.032)
Welcome to the podcast, Bobby.
Bobby Moesta (00:02.542)
Hey, thanks, David. Very excited to be here. Talk about testing. One of my, to be honest, one of my most favorite topics besides measurement.
David J Bland (00:11.036)
it'll be a great time. I I know we've it's like we've crossed paths online and I've been aware of your work for so long, but we've never really just sat down and chatted.
Bobby Moesta (00:16.684)
Yeah, yeah. I I I feel like we I feel like we pass each other like on a on a street where we can see each other but we don't like I know that guy, but I like I I don't think we've actually technically met face to face yet. So it's very nice to meet you virtually for sure.
David J Bland (00:32.1)
for sure. And same likewise. I think where I'd like to just start, and and this is gonna and listeners, this is gonna kind of ramble around because we're just gonna chat and geek out about what we what we see day to day. I would love to start maybe with prototyping and your approach on prototyping because there's so many different takes on it. And I would love to start with, you know, what do you see prototyping as today? Like what are you seeing day to day with folks that are trying to prototype? Like what are they what are they struggling with?
Bobby Moesta (00:46.402)
Yeah. Yeah.
Bobby Moesta (01:00.736)
Yeah, so so I I have to start with a little history of myself because like I I'm I've I've been assembled in a way that's a little bit different, which is one is I'm dyslexic, I've had three close-head brain injuries, I have a very limited memory, I'm ADHD, and so I I had a very hard time in school, which turns out to be probably my greatest
asset and I as I like I always say dyslexia is the gift that I've got that I wish upon nobody else in the world. And the reason why it's a gift is because it helps me actually understand how to ask questions. So I don't learn from books and I don't learn from reading. And so testing and measurement and questions are all in the same space for me.
Right. And so the the other part is that having some great mentors like Dr. Deming and Dr. Tegucci and Clayton Christensen and Thomas Kuhn and some like some really cool people who've influenced my thinking along the way, they all all of them emphasize the fact that I don't know shit. And so the and to be honest, they they they as a student of theirs, they would make sure they like pulled me aside and make sure they told me this like
Tsuguchi is there's there's way more unknown in the world than known and never forget it. Like he like he'd tell me this every single time. Like, and so so the notion of testing is so ingrained into my being that it is like like and prototyping because I don't know. And so I learn through prototyping. So I call it as prototyping to learn, where the way I was taught as an engineer.
Is they talk about prototyping to verify. And and and ultimately, I was just never smart enough to be right. And so I my whole thing was is to say, like, I'm just gonna try. And and I'm not gonna try in one way. So one of the things that Toguchi taught me was designed experiments. He goes, frame it as a system, take figure out the variables, change the variables, put them through a designed experiment, and see what happens.
David J Bland (02:58.344)
Yeah.
Bobby Moesta (03:17.44)
And to be honest, it literally elevated my so I started at Ford Motor Company. That whole approach of admitting I don't know, putting into a design experiment, and literally being able to measure things. I solved problems that nobody could solve for like years. And they and they kept looking at me like, who is this kid and what magic does he have? And it and like, to be honest, I worked on systems I didn't even have technical background on, right?
David J Bland (03:34.9)
Amazing.
Bobby Moesta (03:46.349)
And I'd come in at like it was a paint system and I came in and said like like what are the like what's going on? And we had runs. basically when you paint a car, there's it's about the thickness of the paint. And if it gets too thick, it starts to run. And if it gets too thin, you get orange peel. And so they're trying to minimize the the problems. And so they're measuring the the the orange peel and then they'd figure out how to make orange peel go away, but then they get more drips. And one of the things Teguchi said is like they're measuring the wrong thing. When you measure the problem.
You actually don't understand the function of what it's supposed to do. And so the first thing about any kind of testing to me is are we measuring the right thing? Because nine times out of ten, the right thing to measure is actually hard to measure, not easy to measure. Right? And so so ultimately it's like I went in and then I said, like, I could change the speed of which the the bells that that spray the paint. I can change the voltage drop between the
David J Bland (04:31.966)
Yeah.
Bobby Moesta (04:42.914)
the the the the robot and the and the so the paint's charge so I can change the charge of the paint. I can change the polarity of the paint. I had no idea how any of it worked. And what happened is we ended running an experiment that allowed us to actually find a way to actually not only do it faster, but to do it at at lower cost. And and to be honest, it was one of those things where the the entire group of PhDs said
This can't work because of one of the main things I did is I changed the polarity from the pair from the the car being ground and the paint being positive to the the car being positive and the paint being negative. And we had no idea why it worked, but it worked. And then Toguchi turned to me and says, like, and this is how new theories start. And he goes, the fact is is like at some point we we think we know things because we have theory, but the reality is it's the anomalies of the theory that actually help us improve the theory.
David J Bland (05:30.046)
Yeah.
Bobby Moesta (05:40.343)
So to me, prototyping to learn is like I like I I I I've taught this to my children. I've taught this to virtually everybody. I s I do and what the way I talk about is like what like so right now, we had a family farm and we sold the family farm. And so I'm looking for a a like a small place to go for a cat, like a place to just get away, right? And ultimately I'm prototyping.
I'm I'm I'm we're going one weekend a month for the next 12 months to very different places. And then what we do is we start to talk about what we liked about that place and what we didn't like about that place, and ultimately we frame the trade-offs we have to make. It's like, we want this, but it's a little farther away. And ultimately the decisions come from the trade-offs we have to make, because there's no perfect su there's never a perfect solution. And so instead of trying to test to find the best one.
It's about testing to find the trade-offs that you have to actually pick because there's actually fifty different solutions, not one. And so it's there's never an optimization scheme in my mind where you optimize a design. It's more about the trade-offs you're willing to make.
David J Bland (06:53.981)
I like that. It's a lot of a lot to unpack there. Maybe maybe starting with kind of your ending point of trade-offs and there's not a perfect kind of way forward. I'm wondering, you know, I kind of got on my suitbox a bit when I was writing my book about the education system and how it impacts us in later in life. And I'm wondering, are we still seeing some of that where it's like we have to find the one right solution? Do you still see that?
Bobby Moesta (07:01.518)
Yeah.
Bobby Moesta (07:12.008)
don't get me started.
Bobby Moesta (07:18.504)
So so when I go into rooms and I work with teams, I I the first thing I ask is I say, like, okay, who here got A's? And usually like, you know, 50, 60% raise A's. I'm like, okay, I'm I I apologize because I'm just gonna ruin you. Because you think there's some answer that we're gonna find, and we're gonna find 10 answers, and we're gonna have to figure out what the best answer is because it depends on context.
And and ultimately you're gonna wanna find the best, cheapest answer, but the cheapest answer might not be the best answer. The best answer might be too expensive. And so all of a sudden we have to realize we have to make these trade offs. And they just look at me like, Why are you doing this to me? 'Cause like the world is so simple when you actually have the notion that there is an optimum.
Right. And so I I I firmly believe that it is a problem of how we teach engineers, because engineers are usually given problems and not given context. And when you get to the real world, it's so loaded with context you strip away the important variables because you just want to say, here's the essence of the problem, and if I solve that. And then when it doesn't work in context, you blame the context. it's manufacturing's fault. it's it's the s server's fault. it's and you start to realize like
We have to build things that are are have to work in the real world which is not the same as as just the the the isolated world that you we usually work in.
David J Bland (08:47.911)
Yeah, it's like getting out of the lab, you know, like some things work in the lab. We've done this some of my manufacturing clients will prototype stuff in a lab and it looks great. And then you take it out to a build site and people struggle with it and you're like, Whoa, what's going on here? And it's like, Well, it's out of the lab.
Bobby Moesta (08:49.837)
Yeah.
Bobby Moesta (08:58.338)
Yeah, but but but do you but do you know why? So this is what, by the way, this is what Toguchi taught me. He said, you take those variables that are happening in the in the plant and you bring them to the lab. So it's like, you know what? The humidity changes in the plant. Okay, well, we're gonna induce humidity in the in the lab to say when it's high humidity, what happens and when low humidity, what happens? And how do I actually set it get a bunch of settings that are robust despite the humidity changing?
And so you start to realize that this is such a different point of view. And and I again I was blessed because this that like I I I was curious, I love to build things, I was always taking things apart. I you know, math is my first language, and so one of these things is this guy to teach me this. And so when I went back to school, we had to build a catapult, and I did a designed experiment around the catapult, and what the the real
I don't know, the I got a D on the project because I optimized it and they said I did too many trials, but I understood how everything worked and they were just like, How do you hit the cup? Make it go in the cup. I'm Yeah, but what if the cup moves? Like, what do you mean? I'm like, Well, consumers' choices change and we say it should be twelve feet, but now it might be ten feet because we want to do it for little kids. And so all of a sudden, like, I gotta redo the whole thing, but now I know the two things I gotta adjust to make it go ten feet. And so part of that that that training I had
His name's Genichi Tegucci and his whole premise was about how do we build robust products that are resistant to the noise factors that we can't control. And we need to do that by testing with noise factors in the lab or in the prototype so we understand the contextual implications for all of our designs.
David J Bland (10:46.035)
Amazing. Amazing. I it
Bobby Moesta (10:46.996)
And and like for the I'll say this, for the first 10 years, I was like the the I felt like I was the village idiot. Like, no, no, we can't test it that way. Like, well, this is how we've always tested. I'm like, yeah. And I would have to go rogue and do my own version of testing and show them and then and they go like, well, here's the answer. I'm like, do you want to know how to do it? No, I just like the answer. And you're like, and so finally people are like the thing that I was taught by Taguchi is the worst type of testing you can do ever.
Is what he calls one factor at a time testing, which is A-B testing. The worst thing you can do because it builds a house of cards. You don't really know what causes one thing to be better or not, because you don't isolate the variables in the right way. And so what happens is we we build this house of cards up and it is, and then we say, we got to change this one thing. And then the whole thing falls apart and you start over. Because we don't understand systems. So systems, measurement, testing are all prototyping, are all part of the same.
I don't know what to call it. Domain to me. Right? Same
David J Bland (11:52.904)
Yeah. I was thinking like when you were telling you sharing your story, I don't think I've shared this with my listeners, but I I went to design school and in one of my engineering classes, we were given a paper clip, a balloon, some tape, and we had a fishing line kind of strung across, you know, the the the the the classroom and we were supposed to, you know, kind of create something that would travel that distance the fastest. And everyone was like blowing up their balloons in different ways, and they were all kind of like
many iterations on the same overall design. And my partner and I were like, what if we just don't blow up the d the balloon at all and we just lose it as a slingshot and just flick it across and our and our professor like kind of lost his mind when we did that. And he's like, no, no, no, that's not what I meant. And he had to like give this big speech.
Bobby Moesta (12:23.778)
Yeah, that's right.
Bobby Moesta (12:31.906)
Yeah. Yeah, yeah, yeah.
Bobby Moesta (12:39.064)
But but the but th this is where I go back to him like well then be more specific, man. Like like like at some point this is this is part of what design is about. Like my favorite is when I I was at the D school at Stanford and one of the things we did is like we had this project and they said you can use any resources in the room and everybody sits sit sits down is the first thing and they do is they like all right let's talk about what we're trying to do. I'm like, I'll be right back. And I literally went and grabbed every resource I could and put it on the table because
Most people try to think about the problem and then they the and then they try to go find the resources. I'm like, no, no, no, no. I gotta know what I got because like we we can say we want duct tape, but we don't got duct tape. Right? And so I I I I grew up in what what Teguchi would call as the empirical world. You know shit. The only way you're gonna learn it is by testing, and you gotta build a set of prototypes because just learning the difference between two different things doesn't tell you how anything works.
David J Bland (13:19.677)
Yeah, the constraints.
Bobby Moesta (13:37.455)
So that's that so when you called me and said, Hey, would you like to be on this podcast? I'm like, my God, this is amazing. Right? Like I have let's see if I can switch for one second here. I've got I can't switch my cameras. I have a I like so I in my office over here I have my my mentors and they're their paintings I did of them and they're up up across the top and
David J Bland (13:58.377)
wow.
Bobby Moesta (14:01.154)
They look down at me every day and and for the longest time I thought they were judging me and now I realize they're just with me. So I'm just channeling Togucci right now, just going like he's like, Yes, tell them more.
David J Bland (14:12.178)
I love it. I love it. I think with that, the systems part, I'd love to dig into that a little bit because I'm worried a little bit when it comes to well mind like A B testing, which I feel like sometimes experimentation people say, Yeah, we we do experimentation, I ask and it's all A B
Bobby Moesta (14:20.408)
Yeah.
Bobby Moesta (14:28.832)
It it's better than nothing. Let l let's be clear. A B testing is better than nothing, but the fact is is we're like Teguchi would always say, we're better than this. Right? Which we are. But systems is system, by the way, I have like this is one of the things I wrestle with just hard with. And and I have a very specific way I was taught systems. It's it's a very conceptual frame.
David J Bland (14:39.846)
So with the Yeah.
Bobby Moesta (14:56.16)
It comes from Dr. Deming and then enhanced by Dr. Tagucci. It's it's more of a way to see something or to see how things work and to see how things interact than it is about a mathematical structure or about modeling. And most people are taught systems as a modeling tool to basically.
try to figure out how how things work math mathematically and and my thing is is I actually have to have the empirical data first to then build the model. I find it very hard. Again, I'm not that smart. I I can put it together in hindsight, but I can't I can't figure it out in in foresight. And maybe I would say is if I did, I was always wrong. So I like I just stopped trying. Like like okay here's here like here's the variables I can play with. Let's see what happens. but but
David J Bland (15:45.629)
So yeah, with systems, I think okay, so A B testing aside, I think we could probably do a whole podcast on just that. But the I do worry sometimes in businesses where we we've isolated our testing down to like this these little parts. And I don't think people are often taking a step back and saying, How does this impact each other or what's the overall big picture? I feel like we narrow in on the little parts and we just test little parts.
Bobby Moesta (16:00.607)
That's right.
Bobby Moesta (16:06.328)
That's right. That's right.
Bobby Moesta (16:11.864)
So so this is where we have to actually under system understand systems, subsystems, super systems, and then outcomes. And what happens is is w like the the the thing that most people know is like what I call Scipox, suppliers, input, process, output, customer, right? But the way that Tegucchi t Tegucchi really talked about it to me is that there's a system
And that system is defined by your responsibility. It's not defined by the f the the function of it. So, like if I'm a if I'm a if I'm a suspension engineer, I have a system that I'm responsible, that's the sp suspension. And the steering is actually a noise factor to my system. I can't control steering. And I can't control the weight of the engine. So I have to take all of that account into my system.
But there are things I cannot control. And so the things I can control are the s the type of spring, the material, the displacement, like all of these other pieces. But the fact is, is I have to take those other things into account. So like the suspension works great when I'm driving straight, but when I turn, it like it it lurches. And so you start to realize that the fact is, is you is is the first thing is where is my sphere of control and where is my sphere of noise?
And what are the things that affect my system that I'm responsible for? Because I want this I want the suspension to work no matter what the speed, no matter what angle I'm turning at, no matter what horsepower I have, what no matter what engines in it. Right? And then I then when you really start to frame it that way, I only have a finite number of control factors. There's only a finite number of things I can define. And ultimately I have to define what's the output that I'm supposed to actually achieve, but ultimately.
It's not the output, it's the outcome that I'm trying to achieve. And most people confuse outputs with outcomes. And this is to your point of we work on the little minuscule point of like, ooh, I fixed this one little step in this one little thing, and I ooh, it's gonna work, but it doesn't affect the outcome at all. And so the outcome is your point of the bigger picture, and so and the outcome is only achieved through the customer. So like I can get the customer.
David J Bland (18:08.166)
Yes.
Bobby Moesta (18:30.41)
the meal, but they have to cook it to get the outcome to make it feel like they actually made dinner. Right? I it's not me getting them all the ingredients and having it, giving them the recipe and all those things, that they still have to achieve the outcome, which is boy, that was a great dinner. And so part of this is I feel like so Ryan Singer and I, who's he's a good friend of mine and we talk about this all the time, is that when you build, there's something called, I call it the supply side of the world.
And that's really about building systems to actually help customers make progress. But there's this demand side, which is what is the progress they're actually seeking? And we need to start with the understanding of the demand side first because if we actually listen to customers, they'll say, yeah, let me think of an example.
So there's this aspect of like, I don't want to be I don't wanna be or I need to be right. Right? And the fact is is what what the reality is is is that that standard's up here. And it's like I don't want to be wrong, is like down here. And though they might seem like the same answer, they're very different thresholds. And so when people say like, well, I don't want it to like like and most people can't tell you what they want, they can tell you what they don't want.
And so part of this is this translation of how do I actually understand that outcome and translate it into some metric that I know how to then go test for. So to me, one of the big distinctions, and this is kind of a an insight that I've I've gathered in the last couple of years, is that if I go left to right, I call that process thinking.
Inputs, system, outputs, outcomes, right? And so I already have something if I have a process. But if I'm actually building something, I have what I call systems thinking, which is left to right. I have the outcomes, and then I determine the outputs that I need to achieve to actually achieve that outcome. And then I have to define the system that actually will do that, get to those outputs, and then I have to define the inputs to it. And so
Bobby Moesta (20:44.41)
Left left to right is process, but right to left is systems. And that's how I think about systems thinking.
David J Bland (20:52.752)
Interesting. Yeah. I th
Bobby Moesta (20:53.922)
Right. And and to be honest, I've never had a real forum to talk about this this deeply. And so I truly appreciate the opportunity just to even be here because like most people want to talk about jobs to be done, but like jobs to be done is that desire to actually understand people's outcomes and what they're re what's gonna cause them to change behavior. And then ultimately it's gathering the requirements so I can build measurements so then I can build systems. But like the the lie I feel like we were told in in engineering and design school is
Build it and they will come. If they love it, they'll buy more. It's all bullshit. It's just a lie. They made a movie about it for God's sakes. It's just it's just not true. And so you gotta start from the demand side and move to the the supply side. And you start to realize that half the time so right now in AI, just to bring up I I said we'd kind of steer away from it, but one of the things in AI is it's made building so much easier.
David J Bland (21:33.84)
They did.
David J Bland (21:51.174)
Yes.
Bobby Moesta (21:51.853)
And people are just building shit. They're just doubling and tripling the the feature set that nobody uses because they don't understand the struggling moment that people have wrapped around it. And so they say, I got this feature to work and everybody says they'd love it. But when you what people say and what people do are not the same.
David J Bland (22:12.389)
Yes, we call it the sedu gap.
Bobby Moesta (22:12.738)
Right. This why I I don't I personally don't believe in surveys at all. At all. Because it's words that I'm putting on paper with answers that I believe that aren't necessarily related to what they they really want. And so when they give an answer, it's not necessarily the answer that they they they have because they don't have you don't have the answer in the list. It's why everything starts with qualitative data because we have this realm.
David J Bland (22:18.323)
okay.
Bobby Moesta (22:43.618)
Especially in and when you have new technologies is there's no language to talk about what what it's doing. Like I just did some work where I talked about perplexity, right? And it's like people say, I just use it like Google.
You use it just like Google. Okay, let's go through that. And it's like I use this and then I do that. I'm like, so is this how you No, this is not how but I don't have any other words to use because of like it's the the aspect of like the word doom scrolling was not part of the the the design criteria of Instagram. It came out of the the thing of like, my god, what is happening? It was like the what's and everybody knows what doom scrolling is, but there was no language for it for the first seven years.
This is why th this to me is why h understanding the demand side, understanding the job to be done, understanding the trade-offs the customer's willing to make, and understanding those things relate to how we test. And too many times we're just so stuck on the system and what we think the system should do and what the ideal system is and what's the right way to do it that we forget that there's actually a second connection to the customer. And and what happens is it's also
David J Bland (23:31.249)
Yeah, like emerged.
Bobby Moesta (23:59.631)
Kind of an authority problem, which is like, I want to make sure my system isn't wrong. So it I need to prove that it does what it's supposed to do. So when it goes to the customer, I can say, like, I did my part. And the reality is, this is my biggest problem, is that I don't think we have many integrators left. Because the systems have to integrate to cause behavior change. And no one's responsible. We use Jira to basically
break everything down into tasks and literally feed it to people and understand what the parts are. And as long as the parts work, then the whole should work and it doesn't work that way. I mean you know that. I can tell by the grin on your face.
David J Bland (24:39.523)
I mean, as much as I love the industrial era, and I I do work in automotive a bit. I've a lot of work with Toyota and I do a lot of work with Mazda. Not not not for GM, but I I've done a lot of work with other manufacturers. And what bugs me at the moment is like we've kind of taken all these industrial era, you know, ideas and kind of applied them to knowledge work and applied to like s like let's take a function, let's break things down into tasks, you know, have projects and and and have silos and then kinda
Bobby Moesta (24:45.132)
Yeah, yeah, yeah.
Bobby Moesta (24:59.32)
Does work.
David J Bland (25:07.397)
hope it all kind of mm ends up being a car at the end, right? But it's knowledge work, which is, you know, I'm not saying it's harder. I think a car is one of the hardest things you could build. But the I I'm I'm almost thinking at this point, and I've talked to this in the last couple episodes, that AI might help us break that finally, even though I'm kind of torn by making that statement of well, is AI gonna get us out of the industrial era thinking?
Bobby Moesta (25:30.542)
So s so I I I wrote a book. It's called Job Moves. So I I pick topics and I research them for a long time. And then I've I've realized like what am I gonna do with this image? So I basically interviewed people for the almost the last fifteen years of what caused them to say, Today's the day I'm leaving this company and going to a new company.
Just like because it's not random. Nobody's randomly quitting and nobody's randomly going to anybody's thing. And and what you get on a exit interview is just bullshit. Sorry, is it okay to swear a little bit? I mean, okay, I'll keep it to a minimum. you can bleep it if you need to. But like you start to realize people would say, my God, I got so lucky. And then you'd realize it's like, no, my boss was horrible to me. The fact is I had mastered everything was there. I didn't feel like I was growing, and somebody recognized who I was.
David J Bland (26:08.015)
Yeah, we are weakened a little bit.
Bobby Moesta (26:25.718)
And literally gave me an opportunity to move and and they thought that was luck. And so part of this is the industrial age has done what it what it did for manufacturing, it actually has injected into HR and and how we manage humans. And it's just wrong. Because like they'll do a job description. Think of a job description as a system description. I want a system that will be creative.
And an out-of-the-box thinking, but can manage budgets and manage people. And you're like, that system doesn't exist. And though you want it and you wish it, the fact is you end up making trade-offs to hire one person who's really good at the creative part and sucks at the other part, or really good at the other part and sucks at the creative part, as opposed to saying, no, they're two different things.
And so I'm spending my time like one of the outcomes of this is me helping people do rethink job design around people and their abilities as opposed to like what we need and what we think we need to put in the thing. And then the the here's the craziest part to me is when you look at your strengths and what your superpowers are, the the reality is that there's also us as many superpowers as you have, you actually suck at the same amount of things.
So like I suck at harmony. Like I like every place I've ever worked is like you just need to be a little less aggressive. You need to be, you need to get along with everybody. You know, and my thing is is like I think that innovation is a contact sport. And the more we argue and the more we actually get it, the better the ideas that come out. And so the moment you tell me to go work on the thing I suck at, you strip me of all my superpowers.
David J Bland (27:57.681)
Mm-hmm.
Bobby Moesta (28:16.13)
Right. And so this gets back to what do we measure in an employee? And what we should be measuring is progress. What progress are they making for the company and what progress are they making for themselves? Because otherwise, if they're not making progress, they're gonna leave. And if they're not making progress for you, that you're gonna fire them. And so part of it is progress is the only thing that you have in common. And so we talk about the skills that people have, but we don't talk about the progress we're expecting them to bring to the table when we actually hire them.
David J Bland (28:46.617)
Interesting. I yeah.
Bobby Moesta (28:47.374)
So measure so this is so my obsession with measurement and testing has taken me to these all these crazy like in HR. Like you you you look at like, morale's down. Well, of course morale's down, right? But the fact is, is like how what causes it to get better? And you start to realize that fear and trust are are actually asymmetrical. The thing that actually you think is gonna cause.
that to to help them trust you actually causes more fear. Because you don't know how fear and trust work.
It's a system.
David J Bland (29:25.305)
It reminds me of a conversation I had with a r let's say really well known company. when they were talking about their incentive structure and they wanted to work in this more agile way, more like kind of lean startup design thinking, blend all this stuff together, be iterative, all this stuff, be more product kind of focused. And they in they incentivized everybody individually and they had no team incentives. And what happened was nobody wanted to work together because they're like, I have to own this part or I have to own this and it it became this weird
Bobby Moesta (29:36.354)
Yeah, yeah.
Bobby Moesta (29:40.456)
Be more product.
David J Bland (29:55.161)
like moment where they had to step back and they go, wow, are we is it bad to like stack rank everybody and fire the bottom performers? Yeah, it probably is. If you're trying to incentivize incentivize teamwork to make progress, that's probably working against you.
Bobby Moesta (30:00.719)
Yeah. Yeah.
Bobby Moesta (30:08.504)
But that but that's the whole thing is we we we design the the incentive system by what's the easiest way for us to keep track of the incentive. That's what HR is doing. Like they don't want a complicated system. But the fact is it doesn't work. We can build many systems that are easy to manage but are impossible to work. And this is the problem is we start we start with the system. We don't start with the the customer or the the outcome we're trying to achieve. The c the other the
David J Bland (30:35.268)
Yeah, I can see that. I think go ahead.
Bobby Moesta (30:38.35)
The other crazy part to me is when I start with the system, I over engineer the shit out of it.
And then they go, it's just too much. And my thing is is when I actually understand what people want, sometimes half as good is twice as better.
Right.
David J Bland (30:57.018)
I think with systems well you so you mentioned trade-offs and I do wanna I do wanna unpack that a bit because you were talking about trade-offs and prototyping. Can you maybe explain to our listeners who don't have that framing of how you would approach somebody to say, here's how you think about trade-offs or here's how you begin to to manage trade-offs?
Bobby Moesta (31:19.766)
Yeah, so so first of all it is a trade off is kind of like a contradiction. I can't have both. And this is where it hurts because marketers will say, I want it to be the the best tasting and the lowest cost. And I can make something that's the lowest cost but it tastes like crap. And I can make something that's the highest cost but it and it were it tastes great, but it's literally too high a cost. And it's like, all right, what do we do?
And so you start to realize that that you if you don't actually understand the trade-offs, you can't actually get to a place that actually will work from a business model. So this gets back to, I think you're having what viability, feasibility, desirability, right? Who's that guy? Larry? Yeah, Larry Keely's coming on, right? And and ultimately, I need to be able to like so the trade-off
David J Bland (32:01.678)
Yes. Larry Keeley, yes.
Bobby Moesta (32:09.848)
Happen throughout the entire process. And I have to actually find the sweet spot between viability, right? Is it can we make money with it? Feasibility, can we do it? And desirability is do people really want it? And ultimately, it's all trade-offs. This the intersection of them is trade-offs. It's not, it's not an optimized version of it. It's literally like, what am I willing to give up to get? And so to me.
being able to see the trade-offs is part of the outcomes. Is like I like so for example, I like like my my my cottage, right? It's like, do I want it big enough for my whole family? Right. And I'm like, okay, I would love that. But the reality is like the f the likelihood that they'll all come at once is very low. So what I really need is I need Airbnbs around it so I can make the trade-off of saying I don't need to spend two million dollars.
I can spend $500,000 and have something as well. So for the twice time in my life when they all come at once, I can I can do that. It's a trade-off I'm willing to make. But but ultimately, people are trying to always maximize all of those things. And when you do that, you never feel good about the decision. You always feel compromised. And if you really think about what a trade-off is, is saying, like, I'm willing to accept this one over that one, and that I'm okay with that.
I feel so what like when I didn't have trade-offs in my in my repertoire, I never felt satisfied. Because it was never good enough. The other part is when when you're trying to look for the optimum, you actually hurt progress because people can't make a decision because they're looking for the optimal, as opposed to the half step to help them figure it out so they can actually get to the next one. And so like.
Most of the products that I built are what I call there's the high end and the low end. And I literally just built something that was better than nothing and it turned into like a billion dollars. Right. Like, like if look at look at Basecamp. Basecamp's a perfect example. It's like it's like they want like if you go to the high end, it's like it's Microsoft Project. And the way they looked at it is like, I want project collaboration in some way that actually is just it's better than email.
Bobby Moesta (34:34.648)
And it turns out like, you know, how many people want that? A lot of people. Do they want all these other features? No, they don't.
David J Bland (34:37.786)
Yeah.
David J Bland (34:41.84)
Yeah, I remember in manufacturing, like some of the automakers we we would come up with, we want to run this test inside a vehicle and we would need this kind of L C D display screen in in the dash. And then the trade off became, well, that cost i is like for that functionality, I don't think we could have both. We can't have, you know i and and so these conversations are happening like across the entire supply chain inside making a car. And it it also
Bobby Moesta (34:42.231)
And
Bobby Moesta (35:03.896)
That's right.
Bobby Moesta (35:09.838)
Here's
David J Bland (35:11.002)
happens or should happen inside software where, you know, you're you're trying to develop a software product.
Bobby Moesta (35:17.346)
That's right. But the thing that's really hard is there's nobody in charge of the trade-offs. Because the trade-offs are between the systems. And so the only people who can make the tra what happens is what I'm I'm seeing and what I'm afraid of is most of the trade-offs are not made till the very end. And it screws everything up. We can't have both. Okay, we'll tell at the last minute, we gotta take this out, take this out, take that out. Okay, we're gonna do that. And it's like now it's shit.
as opposed to proactively going like we know that this is where it's gotta be, how are we gonna manage the trade-off? And the person who built one system saying it should be me and the other person building the system, no, it should be me. And and there's nobody above them going like what it should do, because the people above them are just coordinators. They're not actually like cheat you know, if you in the automotive business, we got chief engineer. The chief engineer is the one who makes the trade-offs.
He's the bad guy, or she's the bad guy.
David J Bland (36:11.471)
Yeah.
The integrators comment you mentioned earlier.
Bobby Moesta (36:17.524)
I I feel like that's like the the this is the role that the PM needs to become is the integrator. And they're still they still feel like the coordinator. And they they don't have the authority to make the decisions, but nobody does.
David J Bland (36:37.645)
This plays out in such interesting ways. I was having this conversation with a client this morning about the cost of change and how we get later on in the process and we're about to scale the thing, but we haven't de-risked enough early on like we should have. And now we have these things come up at a late stage and it becomes really expensive. And no one's happy, but we also didn't take the time to work through.
Bobby Moesta (36:58.594)
Yeah. Yes.
David J Bland (37:04.781)
some of that risk sooner. But I just see it's play time and time again inside companies where it's like it's almost like our early stage systems. either we we skip them or they're not well designed, but we end up far too late in the process uncovering things that are almost like fatal flaws in the product.
Bobby Moesta (37:22.338)
Yep. So so what's so interesting to me is the thing that that liberated me from that is Ryan Singer's work in ShapeUp, where he talks about fixed time variable scope.
Because right now we have fixed scope and variable time. How long do you need to get this done? Tell me what else you have to do. And to be honest, we're the stupidest we could possibly be when we're planning it. And then management holds us accountable to our stupid guess. As opposed to saying, like, go work for four weeks on this thing with this objective in mind. And literally, like, tell me, like, what are the big unknowns you need? So, like, to me, the biggest.
Shift in my brain is I went from basically building what I know to realizing that I'm actually just uncovering unknowns. And so I manage the entire process by what are the big unknowns that we have and how what are the prototypes I need to go build to make the unknowns known. And it drives people crazy because they want to go execute on all the stuff they know.
And the stuff that we don't know is so interdependent on the stuff we know that like we go do all the stuff we know and then we get back to say, like we gotta worry about this, like, shit, we gotta rework that and we gotta rework this. And so part of it is like I try to say the first part of most projects is discovery and discovering what we don't know and make basic basically making sure that I understand how the system's gonna work.
And then once I have and so the prototyping and the measurement is all in the unknown discovery part versus once I have the unknowns kind of managed, you're never gonna know all of them, but like I've got 80%, 90% of them. It's like, okay, now I can actually execute and now I'm gonna test to verify and test to make sure I'm but like we don't do that upfront work. We just run and start building. Like I I just wrote a paper around this. Like, what happened to research? It used to be research and development, RD.
David J Bland (39:21.017)
Yeah.
Bobby Moesta (39:27.96)
There's no R. So, to be honest, by the way, this is why I think AI is just so powerful, because it's literally a history professor who can tell me about every system that's existed in the past, and I can use it to prototype like crazy to learn and make the unknowns known. Because it's it's not unknown to the world, it's just unknown to me. And then there's unknowns that nobody knows, and that's where the money is. Right?
David J Bland (39:29.273)
A lot of D.
David J Bland (39:52.912)
It's also accountability. I feel as if when you were describing that process and that system, you were talking about well, you are almost like in a way you were saying like you're kind of like held accountable to following this this plan or the you know the marching forward. Instead of going in and running discovery and learning and then giving an account of how you're do risking something, it's almost like you're just held accountable to deliver
Bobby Moesta (40:08.738)
Yeah, that's right.
Bobby Moesta (40:17.198)
That's right. That's right.
David J Bland (40:20.483)
But you're not giving an account of how you're really de-risking.
Bobby Moesta (40:23.414)
And and the the and part of it is is is I'm accountable to what I'm gonna learn. Development is really about learning. And and the way I was taught about is no development is about verifying. That's what manufacturing has basically put in my mind. And you start to realize like, but before I know, and again, I come from the fact that I'm the stupidest person in the room. I really don't understand, and even if I do, I probably don't know. Like, how do I get the unknowns to be known?
And that's the work. That's the prototypes. Like so when people are building a prototype, like, I I wanna verify this, I'm like, Why do you need to verify this? So I gotta by the way, most verification is for the church of finance.
My belief is that that there's a lot of verification that we don't really need to know because we have enough of the the small data that will tell us what's there. And somehow we think that if we get big data to to tell us what the statistics are, that it's gonna turn out to be a big thing. And it's almost rarely true now. Cause they just distort the the data to fit the paradigm that they have.
David J Bland (41:09.711)
Finance drives a lot of it, yeah.
David J Bland (41:34.703)
So where do you think this is all headed? You know, are are we are we gonna be like no more integrators? We're handing things off to AI. I where do you where do you see this going?
Bobby Moesta (41:45.401)
no I I I I think we're gonna s so how do I say? I feel like AI has been promoted like like we promote other people in the Peter principle. It's literally being promoted to something it shouldn't be.
Right? It's a really good helper. It helps me think through things. It gives me different perspectives. So, like one of the things I love to do is that we take a problem and I want to look at it from all these different angles. I can go into AI and get like, well, how do they look at it then? How do they look at it? And what and I get a much better understanding of the problem. Such a great thing. But the fact is, is AI can't really generate what's next, especially when it's asynchronous to to the domains. Because we the creative part is, you know, it comes from
actually like cross domain knowledge and and AIs are built for very specific domains. And so it's it's really a good it's a good thought partner, but it's not gonna do the t it it by the way, it can't make the trade offs.
David J Bland (42:48.985)
Hmm, interesting. Yeah, it's interesting take.
Bobby Moesta (42:49.324)
Right? It can't because the the the the trade-offs are emotional. It has no concept of emotion. It has a definition of emotion. But like when I say fear, there's nine kinds of fear. Which fear are we talking about?
And so it's it's a w so again, the beauty of being dyslexic is it's a word system on a probability of what the next word is based on everybody else in the world writing. That's the most insane system I've ever heard in my life. And let's be clear, it's very useful. I'm not saying it's not, but like it doesn't like we barely so the one of the phrases I say is we rarely listen.
Or though we rarely speak at the same resolution that people listen.
So you're making really clear comments about it and people are kind of listening to it. It's like, and so we think words are very precise, and we've tr made a machine that actually understands the precision of that language, and the language is all contextual.
And it's not small contextual, it's big contextual. So so my belief is it's gonna get fired and it's gonna get demoted and it's gonna be able to say, like, okay, this is the role it plays. And so this is why this is what I I consider like the the the AI bubble, is like we've all wanted to be these big things. Like everybody I every big corporation I work with is like, we got an AI initiative. I'm like, what is that? We just gotta use more AI. I'm like, but why? Well, it's gonna save us money. How?
David J Bland (44:02.733)
Yeah.
Bobby Moesta (44:30.114)
And there's no answers. And you're like, and it's like, well, we're gonna get everybody to try it so they can do it. And what they're doing is they're adding to their costs because they haven't thought through the system that it changes the whole way we work.
David J Bland (44:41.741)
It does.
Bobby Moesta (44:43.224)
So sorry, I'm I'm a little mopped up
David J Bland (44:44.571)
no, that's good. I I wanted I wanted to hear your perspective on it. I I think as we wrap up though, I do want to talk about something that we were chatting with before we jumped on the call, which was potato chips. So you had a chip story and I I had not heard this one and I was wondering if you could educate our listeners on some testing in that space.
Bobby Moesta (44:59.32)
Yes.
Bobby Moesta (45:05.528)
So very early, this is this is literally 35 years ago, doing work with I'll say a snack company. And one of the ways that we really thought about, like, like I I I'm so all five of my mentors thought measurement is is probably one of the most difficult and hardest things to figure out. And that you need to spend a lot of time at it. So I was actually at this this snack company talking about.
ways at which we could measure how people like this because they'll say, we'll we'll have taste it and then we'll do a survey. I'm like like I like it a lot. I like what's a nine, what's an eight, what you would rate it a seven and I rate it a five and we mean the same thing. Like it's just the most and we just get large numbers and we get statistics and say, it's a six point five. Like and I said, I I I like my thing is this is we actually take three flavors, we put them on the table.
And then we show people a TV show, a 30-minute TV show, and we introduce the the chips as something they can snack on while they're watching this. And then we're going to ask them a bunch of questions about the TV show. And what we do is we and we watch what goes away. And if they they get empty, we put some more in and we basically look at it and say, like, how much, how many chips did they eat? And it's the way we figured out which flavors to go for.
And which flavors not to go for. And then ultimately the the the final check was like when they went home is like, would you like any of these snacks? And we'd measure the bags that they would take. It's real behavior. It's like they're gonna eat it and they wanna take it home. Like that's really good. And so instead of having 20 flavors, we were able to figure out how to get it down to four flavors. And it's like, my God, like like shelf space simplicity, like it had just all these other cost implications, but everyone's like,
They they constantly would do surveys and this is why I don't like surveys so much, is because like it's the it's the it's the answers we wanna hear as opposed to the answers they wanna give.
David J Bland (47:07.375)
That's amazing story. I love that. It's and also the context is important in that in that story t as well.
Bobby Moesta (47:07.928)
Right. So
Yeah, yeah. Yeah. Well, and again, it's taking them off the chips because if we actually focus on the chips, they're over like they're oversensitive to the flavors and like, this one's a little spicy. It's like you you still need a two bagfuls of that stuff. Like I don't know what to tell ya.
David J Bland (47:29.327)
thank you. I just wanted to wrap up on that story because I thought it was amazing. So I appreciate you sharing that with our listeners. I d I just wanna thank you so much for hanging out with me. I know it's been too long before we'd we've been able to sit down and chat. I feel like we should have done this fifteen years ago.
Bobby Moesta (47:33.432)
No pro no problem.
Bobby Moesta (47:43.906)
Yeah, yeah. Yeah, I feel I feel like we we would have been best friends if we would have met fifteen years ago for sure. 'Cause it's like it we' we we come from the same same cloth.
David J Bland (47:50.019)
For sure.
if folks listen to this and they wanna reach out to you, they're they want to learn more about you, what's the best way for them to find you?
Bobby Moesta (48:03.318)
The to be honest, the best way is LinkedIn. Like I I, you know, I I I have some people kinda help me manage it. So like if you if you if you DM me on that, there's somebody else gonna help set up the thing. They'll they'll kind of vet the conversation. But if you want to talk far further about this stuff, I'm so I run a consulting firm called the Rewired Group where we help people do both jobs to be done and then help them with c corporate innovation and startup innovation. And so
and we we're very small. There's five of us. We we do twenty projects a year. and that's where we help. But I'm I'm to the point where like I'm I'm now sixty two, I got three grandkids, I'm I'm I'm moving more towards a coaching and and kind of advising role where I've got a staff of people below you know, or are partners with me who basically can go execute those projects 'cause I just don't need to n do another interview on a frozen burrito, man. Like that's just is like too much for me.
David J Bland (49:01.463)
I I feel you. I understand. All right.
Bobby Moesta (49:03.522)
So so but but LinkedIn and it's Bobby Moesta, M O E S T A. I'm at the Rewired Group. I also teach at Kellogg at the in the entrepreneurial school and just I I love to help people. That's what I do for a living.
David J Bland (49:17.955)
Yeah, shout to Kellogg, it's an amazing school. All right. Well thanks Bobby for hanging out with me and I really appreciate your taking time and just being open and honest and energetic about all the topics we chatted about today. Thanks.
Bobby Moesta (49:20.098)
Yeah. Thanks, Ben.
Bobby Moesta (49:27.257)
Thanks for thanks for having me. Thanks for letting me talk what I like nobody asked me these questions. So I hope I wasn't too forward. So it was great. Thanks.
David J Bland (49:33.796)
That was great. Thanks.
