Stop Building Useless Software: The Two But Rule

Intro

Kevin Hi guys, this is going to be a crazy episode. I'm going to talk with John Wolpert, and in case you're not as excited as I am: John Wolpert is an esteemed speaker, writer, thinker in technology and business innovation. As a CEO and product executive and advisor, he has been at the vanguard of technology breakthroughs from the early days of the web to the rise of artificial intelligence. John is known for founding Flywheel, a pioneer in the ride-hailing industry, and his work at IBM made him a key figure in the evolution of open-source software, blockchain, and AI. He has co-founded global R&D consortia and industry standard bodies, and his thought leadership in open innovation has been showcased in the Harvard Business Review. John has led countless new venture workshops and spoken before the European Union and the Australian Parliament in his mission to help organizations work together to solve hard problems. I'm so excited to have this conversation with John, and I really can tell you, every time, his wisdom and vision through all that nonsense is just incredible. So without further ado, let's dive in.

The Two But Rule

Kevin Hey John, thanks for having me. Well, first of all, you have written a really cool book, The Two But Rule, and as we have worked together before, I really started using it from the time you explained it to me, and it really made an impact in our business. So first of all, since most of our viewers might not be familiar with it, would you mind sharing what The Two But Rule is about and what kind of brought you to this?

John Sure, Kevin, it's great to see you, and thanks for having me on. The Two But Rule is a pretty simple idea at the start. It gets deep, though. The Two But Rule starts with simply saying: but it won't work. Being negative. Somebody presents you with their intentions to do something, overcome a problem, capture an opportunity, they have an idea, and what do we say? Oh, but that won't work. But I don't like that. But we can't afford it. Right? You've experienced this. I experienced this in talking with my wife sometimes. But we can't afford it. But we can't do this. But, but, but, but, right? So we've lived in a culture. Certainly as a Gen Xer, I lived in a very strong one-but culture. The boomers would come in and drop a one-but bomb on us: but we don't want to do that. But stay quiet and do your job. That sort of thing. So we didn't like that very much. So what did we do? It's a no-buts culture for you all. Sorry about that. Because if there's one thing that is a bigger momentum killer than a one-but culture, it's a no-buts culture. So you have a no-buts culture where people are afraid or feel unsafe or just don't even know to challenge an idea. We have all these phrases out there, like the no-killer phrases in brainstorming. No ideas are bad ideas. That's a really bad idea. There are definitely bad ideas. We should love our bad ideas.

John The mythology that there are entrepreneurs that are just stubborn and dogged and pursue their original idea in spite of opposition: maybe it happens from time to time, but in my experience, there's always a deeper story behind that mythology where, yeah, no, their idea was terrible, and they evolved it when they came face to face with opposition. Imagine the Apollo 13 mission, when the crew was in danger and the command module exploded. Their first idea was to turn the ship around, burn the main engine, get back to Earth right away. And imagine what would have happened if, when an engineer said, but that won't work, the engine is probably damaged, somebody had said, oh, don't be so negative. Yeah, that would have killed the crew. Turns out later they found out that, yeah, that would have been a very, very bad idea. So instead they said, but we can slingshot around the moon, use a lot of gravity, get them back that way. And then there was a whole series of buts after that. Their CO2 scrubbers aren't working in the LM, but we could fashion a Rube Goldberg machine to fix that. There are so many buts, right? Life is a chain of buts.

John But that won't work. But it would if. But that also won't work. But it would if. And in my experience running innovation labs and research organizations and product teams, five rounds of the Two But Rule is a good recipe for coming up with something innovative, maybe a patent or two. And I've had experience with that. So that's the Two But Rule in a nutshell. Underneath it, there's a lot about intentions and listening for the needs behind why somebody wants to do something and why you don't want to do it, or what are the needs driving your need to oppose it. And then finding a creative way of squaring those things. You say, but I don't want to do that, but I can see why you want to do it and I can see why I don't want to do it. And where can we meet in the middle and square up those two things?

Kevin That was a beautiful explanation. And one thing that I really like about this is it's not just great for discussions, right? But it's also great if you just talk with yourself, like evaluating something, because it forces you to be more open-minded about a certain problem statement, let's put it that way. So you really have to think, well, I really don't think it's good. But. Under what circumstances could it be better, or whatever? So that's kind of really cool as a shift that helped me as well.

John Yeah. I think most of us live life afraid of our buts. I've sat in that chair right there, in my little thinking chair, and I've run from my own buts so often. Where I'm like, oh, I want to do this. I want to build this. I want to try this. But. And then I'll run away from them. And I waste tons of time. And if I'm mindful, I realize that I'm just frozen in place, afraid to face those buts. And I wrote the book about it, right? But in a two-buts culture, when you're habituated to two buts, you say, oh yeah, hey buddy, thanks for that. That's a great but, show me all your buts. And so we call this momentum thinking, which is the clinical term for this. But I also wanted this to get into the culture of more teams, more companies, because if people expect your second but and you're habituated to providing the second but, they'll give you a chance with your first but. As opposed to, it's a very vulnerable thing to present, hey, I want to do this, and somebody says, but that won't work.

John I remember a team I was running at IBM where that happened. A new hire stepped up with a, hey, what if we did this, and an engineer on the team went, but that won't work. Mic drop. And then I said, but it would work if. Now, ideally the engineer would say this already. I wouldn't have to prompt. And so I asked him, but it would work if. And he looked at the ceiling and went, but it would work if gravity was different. And not a minute later, another engineer popped out of their seat and they had a terrific, they were like, what if we did this? We didn't change gravity, but it gave the second engineer a new context, a new way of thinking about the problem. And that led to a couple of patents and a project that got the attention of the CEO of IBM. So yeah, that's momentum thinking. I called it the Two But Rule because I figured that would just be catchier and more likely to get people to think more about it. Because once you've seen your but, you just can't unsee it.

Kevin The cool thing is, I'm just remembering Jeff Bezos saying, you have a great company culture if, let's say, the newest hire, the youngest, most inexperienced engineer or person on the team can trump the most senior person on the team with facts. And I think that's also some kind of a great approach to induce that in some kind of way, right? Because everybody can come up with a somewhat silly but as well, right? Which is part of your strategy. So that kind of opens the gates for anyone to contribute, right?

John The rule is you have to bring a second but. It doesn't have to be a particularly good one. And then the team has to remember that they can also two-but that: well, but that's not a very good idea, but it would be if. And then, but that also is not. If you can sustain it for long enough, you'll come up with something. I had a family discussion just the other day with my wife, and we were talking about this, and I had a reminder. I came up with a terrible second idea, and she's like, that's bad. I know. I'm like, of course it is. That's the point. It is definitely a bad idea. That's why I said it. And she's like, oh, right. Yeah. And then we found a really good solution to a problem with birthday parties. This particular problem, but it doesn't matter what it is. It could be life sciences or climate change or a family birthday party. So just habituating yourself to that, and having a culture that expects it, makes it safer.

Creating Safe Spaces for Employees

John But you said something about how this empowers newer, younger employees. There's a lot to be said about making safe spaces for employees, less experienced ones. But I found that the opposite is an interesting thing to look at today. It's unsafe. It's safe for most managers in any company of size to tell any employee that their idea is not good. And there's a book by Amy Edmondson, who's a Harvard professor, a great book, actually several great books by her, and she's really into this idea of psychological safety, which makes a lot of sense, but it can be misread as, hey, you have to make everybody feel safe and validated and stuff like that. And I'm like, no, your idea is a bad idea. I'm not doing you any favors by telling you it's not a good idea.

John The example that's often brought up is, there are a couple of cases where a senior, say, pilot didn't listen to the junior pilot, and disaster occurred. But what we often don't talk about is, what about the case where the senior pilot disregards their own judgment from years of experience and goes with the less good idea of the junior pilot, and that causes a disaster? So you can't just apply that in a blanket way. How do we make it safe for a senior person to say, hey, great idea, but not such a great idea, but this won't work? And one way to do that is to say, but this didn't work in the nineties, but here's what happened, so you can try it again and maybe miss that mistake. It's hard to present your but to anybody, whether you're a senior person or a junior person, I think.

Where the Two But Rule Has the Biggest Impact

Kevin That's interesting. Well, when we talk about where to apply this Two But Rule basically, I'm pretty sure there are certain areas of your life or career where the Two But Rule has a bigger, let's say, is more impactful than in others. What is your experience with it?

John I think it works best in team environments where you're trying to wrestle with a gnarly problem, where there isn't a clear answer. You've got to go left or right, and there's no way to know for sure which way to go. And again, the great silly but for that is: hey, you want to go left, but I don't want to go left, but we could go right. Or you might say, but we could both grow giant long legs and go left and right together. And that's silly, but it tells the person that, hey, you listened to them, and that whatever you're going to do, you're going to do it together. So there's utility in even that silly but. The other very useful thing is, and I think this is maybe the mission, is to help the but-heads. How many folks are there watching this right now that feel like they might be voted off the island, or becoming a pariah or a Cassandra, somebody that nobody listens to? Either because they are seen as too negative because they chime in with a lot of buts, or because they are not feeling comfortable about presenting their buts, and they let a lot of bad ideas slip by them and they become ineffectual. There's a lot of people on both sides of that that are in a terrible place. I mean, the halls of mental health must be filled with but-heads.

John People that are one-butters, right, because it's not a fun job. People don't like it when they hear but, but, but. So can we turn that around and save the but-head, and say, oh yeah, look, he's our official designated but-head, because he always comes up with two buts. In fact, if you're doing lean startup, there's a story in the book about how we missed a trick with an experiment we were running in the market. And we missed it because we validated our assumptions rather than using that experiment to look for the additional buts that were out there lurking for us. And we missed a big one, and it was a costly mistake, because we were so happy that one part of the experiment validated what we thought, rather than going, oh, but what else is going to go wrong? What else is this experiment telling us about the problems with this approach? And we missed a really big one. If we just had a designated but-head on the team, the chief negativity officer, if we could celebrate that person, we'd say, yeah, we love that you are good at finding problems. Let's get all those buts on a wall. And at the end of the sprint, let's pair them with a second but, and then find the ones that we can do something about or explore, and go to the next sprint. I think that would just be a lot more fun and a lot more productive.

Kevin Yeah, you're doing a good job. And it gives you a metric, right? But those that are not as disagreeable, they have to come up with something. And those, as you said, that are too disagreeable, maybe they also know, I have to come up with the contrary. So it's kind of, as you said, momentum thinking, and that's the beauty.

Chiming In Too Quickly

John In fact, this is not in the book, but in working since then in consulting, somebody pointed this out, and I think it's brilliant. If you are a person that chimes in too quickly, right, I don't know about you, but when I feel like I've jumped into a conversation too quickly, it's usually because I'm worried that I'm going to forget what I wanted to say. That something you've said triggers something in my head, whether it's negative or not. And then that leads to, ah, you know, then you become that jump-in person. There's a lot of people like that. I was talking to somebody about this and they're like, yeah, I'm from New York, that's normal. So there are cultural differences in timing. But on a team, usually you need to give people space and time, and you have to get the rhythm right. And for some people, that's really hard. There's a lot of ADHDers out there that find it very difficult to get the rhythm right, to get the rhythm of a meeting with more than one or two people right.

John The observation was that if you wait to have your second but formed before you provide your first but, you will not forget your first but, because you're formulating the second one and it generates all this neuron activity. You're not forgetting that first but. You can wait. You can get to the end of the meeting. It'll still be there. And if you get habituated to that, it gives you time. It makes you more thoughtful. It opens you up to listening to, okay, well, the second but's gotta come from this other person's needs. What do they really need? Okay, well, actually, what they're not saying is, what they really need is that they need to be heard on this something. Okay, but we could do that, right? But now you have something, and that'll last. That'll last till the end of the meeting, or even after the meeting, you'll bring it back up.

Kevin Quick intermission. If I could ask you for one single favor, it would be that you hit subscribe on this channel, because it helps our channel more than you can imagine. And you know, the bigger the channel gets, the bigger the guests get. So thank you very much for watching, and let's continue with the episode.

Does the Two But Rule Change Product Development?

Kevin Well, obviously you can apply this method in a lot of ways. I'm wondering, when it comes to product management, product development itself, building or launching a product is a long, long process. After the launch, it continues, right? How does the application of this approach maybe change throughout the process? Or is it mostly really just for discussion, and when there is something like a dispute, then it's great for settlement or something like that?

John Well, it's certainly great for alignment. As you know, and I certainly know for many years, there isn't a team that doesn't go through an alignment crisis every sprint. It's just a thing that happens. Humans get offside, or you start to get this mental genetic drift from whatever somebody's original thought was. And this happens for as many people as are on the team. So alignment, certainly, it's good for that. Say, okay, but I'm starting to think these new thoughts, but we want to stay on track. But we can stay on track and embrace the new thoughts if we, right, there you go. So you're applying the needs. We need to stay on track. It gives me anxiety to think about zigzagging all over the place. We don't want to be that company. But at the same time, we need to be responsive. That's a gnarly problem, or a wicked problem, as they call it. There is no right answer. It's balance. Balance point problems are all good two-but problems to deal with. So that's one side of it. The other side, and I mentioned the lean startup, there's a chapter called Leaning Into Your But, where, instead of the five whys, it's kind of like the five buts. You want to lean into your but on lean projects. That's sort of experimentation.

John And then the other part that's really important for product management, I think, has to do with the product itself. So for example, I'm really fascinated right now with a powerful two-but problem, which is: we need to share, but can't share. I've been fascinated with this problem for almost 30 years, I think. It's certainly 25. The need-to-share-but-can't-share problem pops up everywhere. You're a startup. You're pretty sure you need a partner. You cannot tell the prospective partner. First of all, you may not know what the ideal partner is, but you can't put it out on LinkedIn that this is something you need, because you're exposing your intentions. You can invent something and tell everybody about it, patent it, whatever. It's very scary to tell people about your intentions. Hey, we intend to do this, and we have a gap between what we want to do and what we can do. Companies find this to be extraordinarily terrifying, and rightly so. You can't protect intentions. And intentions are the action verbs of innovation. I mean, inventions are the nouns. What I intend to do with something is the action verb. Here's my invention, this pen. I can stick it in your eye, and now it's a disruptive innovation. And I cannot tell you about that, or anyone else, before I do it, or you're not going to sit still while I do it.

John In the frame, that's like zero-knowledge cryptography on one hand, and we use headless vectors on another, to be able to find coordination opportunities without exposing data to each other directly. I think that's a really interesting space, where not even the SaaS provider actually has your data, but they can still find connections for you and also allow you to coordinate, in a supply chain, in executive recruiting. All these are: we need to share. I'm a CEO. I want to leave my company. You're the board. You want to fire your CEO. Neither of us can tell anybody except our recruiter. That puts the recruiter in a very delicate position.

Kevin Yeah. Now, let me apply your Two But Rule: but is that really such a huge pain? Because when looking at LinkedIn, you can already hide, for example, your intentions from your current employer. Of course, they can find out if they want to, right? So it's not bulletproof, but isn't that enough, basically, to solve that pain?

John Yeah, it is. In that particular case, of course, you're always sweating a little bit that somebody's going to out that data. So we're worried about that. So yeah, in these sharing situations, you need to trust a provider, right? A recruiter, an executive headhunter, a SaaS, a LinkedIn. And yeah, it becomes a trivial problem if you can trust the intermediary. Like, remember when you were in high school, and you were in love with so-and-so, and their friend was dating your friend, but you know that your friend is a big mouth, and it would be very handy if you could just say, hey, can you put me next to them on this date when you're out at this movie? And you're like, no, they're definitely going to blow it for me. So, I mean, it's a very delicate situation.

John But there are deeper ones, like supply chain, for example, where we need to figure out supply chain risk, single source risk, things like that. And the suppliers will not, no matter how much power you have. And I've been in a thousand kinds of projects like this where a very powerful company thought they had enough power to get everybody to give them their data. And it turns out, no, they don't want to give them the data. So how do we coordinate? But we need to know where all the bad radishes are, or where all the contamination is, or maybe there was a poisoning event or salmonella or something like that. Or we don't know where our production line is going to come crashing to a halt, because one vendor of a vendor of a vendor of a vendor is a single source contract coming out of, say, China. And there's a disruption in that particular thing, and now our jet is three months behind and hundreds of millions of dollars over budget, just because of one tiny little part four or five layers deep in a supply chain. To be able to visualize that, find it, predict it and deal with it: if you could have all the data, it's a trivial problem. The problem is companies don't want to give it to you. So I find that to be a really interesting two-but problem.

John Right. But the companies, you know, accept the fact that the companies have needs to not. If you're a chicken farm company, you don't want the supermarket chain that has power over you to know where all your chicken farms are. But they need to know if there's a contamination. And we also don't want to have a big honeypot of data in the supply chain. When I was at IBM, we tried that many times over the years, and it turns out nobody wants to give us the data either. So how do you not provide the data, but still coordinate? It's an interesting problem.

Kevin Yeah, well, definitely something that has been worked on for a long, long time. And we see it in a lot of things already, right? With ZK, as you mentioned, and all these commercialized data projects, data sharing projects out there. There's a lot going on in that space, for sure.

John Yeah, I mean, we thought that blockchain, that's why I got involved with blockchain years ago, is that we thought that that might have been an approach. It turns out it's an anti-pattern. Putting your data on a big digital nudist colony is kind of the opposite of what you want to do with that kind of problem. I mean, even with obfuscation, in the world of AI, AI will make you if you put your transactions on a blockchain. Do not do crimes on blockchains, kids. They will find you. Use mixers, we'll still find you. And there's scaling problems with that particular approach. But the problem space, like a lot of things in Web3, the problem is legit. The solution, it turns out, to that problem set: yeah, we do want, we don't want to be locked into a vendor. We don't want Facebook to own us, or what have you.

John We want to be able to move our data without losing our connections, our SEO. We don't want search engines to lose us. Well, one way: Substack. I have my own domain. Substack has a custom domain. I paid them 50 bucks. And now, if I were to move all of my Substack articles somewhere else, it's just a 301 redirect. So I didn't need blockchain for that. It's just a policy that the company had that you're not going to be locked in. We did that in the nineties with phone numbers in the US, and I think Europe did it as well, where we have done number portability. We just decided that by regulation. We said, yeah, all phone companies have to be able to allow you to take your number with you if you move to another carrier. Before 1997, you couldn't do that. We didn't use a blockchain to fix that. We just decided that that was an important thing. So lock-in, I think, is important. Decentralization for decentralization's sake, that's where I think we went wrong. I think that what we need to do is focus on the problems, why we have those problems, what are the needs that we're trying to address where we think that Web3 or blockchain would solve it. And then say, yeah, but it doesn't scale, but it's actually kind of an anti-pattern, but we could still achieve what we need, even if we don't use a blockchain.

Kevin The easiest technology for your problem set, absolutely makes sense. Well, as you said, when it comes to data sharing, these kinds of things specifically, absolutely. I mostly agree with a lot of things. Of course, I'm selling blockchain, as you know, but as you can see, I'm highly critical when it comes to what use cases you apply it for. For a lot of things, it just doesn't make sense.

Does Blockchain Make Sense?

John I still think that blockchain, public, large public linked lists, are a good thing to store hashes and proofs on. Scott Stornetta has been doing that since 1995 with the New York Times classified section. It's a perfectly good use case. I need some way of getting to the bottom of this. I need to know that this hash of some data I took at some point in the past, that the data hasn't been tampered with. And I need to know that the hash itself hasn't been tampered with. So I need something that's really tamper resistant. And if it's a hash, well, you don't really get much data out of a hash. So I don't mind the idea of plopping hashes, or a Merkle tree full of hashes, or the head end of a Merkle tree, like Mina, there. I still kind of like Mina. I'd love to fork Mina and find a way to do Mina without having a gambling token powering it. Because, you know me, I'm not into that. A friend of mine came up with an interesting way of using stocks, like legit stocks, as a form of staking. I think we called it StockChain or something, where you don't use a cryptocurrency token and try to convince people that the coin will go up, to secure the network. You could actually stake stocks into a mutual fund type of system. And that would work. That would actually work.

John So if you could run a Mina without crypto, because I don't like crypto, and you could run that in such a way that you could say to anybody, here's my Merkle proof of the state of the shared data that we have. I've got some data in my comp system. You've got some data in your system. And we're going to run a proof that this data that we have is the same, that my credit is your debit, and that the rules that we used to get there are correct and followed a set of rules. And I can attest to that, and I can send you the Merkle proof of that. And all you have to do is check the head end of a Mina blockchain, and you'd be able to say, yep, you definitely have that debit and that credit, and you didn't loan the guy over the usury law in Texas, so yes, I will insure your loan. And I didn't have to give them the data to do it. I think that's a perfectly good, usable blockchain. It's just kind of boring. It definitely doesn't make the crypto degens get rich, but it's a pretty good use of blockchain, because blockchains can scale to handle that use case.

John Being the world's currency system? Never going to do it. When we can make a blockchain do that, we will also have warp drive. And that's not hyperbole. Well, I don't know, let's be honest here. But we could get Leslie Lamport, the father of distributed systems, on the phone. I'm pretty sure he'd say that, yeah, causality is causality, and the speed of light is a limit. So if you can break causality and actually make a replicated singleton scale, then that's great. But then we would also be able to break the speed of light.

Kevin What you mentioned with using stocks basically, that reminded me of a lot of these projects that try to use at least a different asset on a different chain as, let's say, proof of stake. You can take a look at how the debate is going, but, like a big consensus mechanism, I think the technology is already there for these kinds of use cases, right?

John Yeah, but you're back in the labyrinth, right? I mean, in fact, you think about correspondent banking. It's a decentralized system. There's all those banks, and they all have their own ledgers. And Swift and other things try to keep them in sync. And instead of a central bank, now you have a central blockchain. They're handling bridges, where all the problems with crypto happen at the bridges, or a lot of them. And of course, what we've learned is that, whereas you can say that, say, Bitcoin has not been hacked and the tamper resistance has been proven, there certainly has been an awful lot of crime and hacking on the edges. So it didn't solve that. Lots of fraud anyway, because at the end of the day, the blockchain has to meet the real world somewhere. And so, yeah, you're back to what I always found in eight years of blockchain, which was that every time you thought you were on your way out of the labyrinth and you'd solved the problem, figured out something, it would walk you right back into the labyrinth.

John So we were trying to get away from centralization. We are delivering a terrifying level of centralization in the name of decentralization. The crypto hegemony is real. As we've seen, the prices are inflated, being maintained by people that can afford to wash trade and do some things to keep it up there. Lots of manipulation. All the things that we wanted to get away from, we are delivering in spades in the name of getting away from them. I don't like that. So that's the problem that I've found with the blockchain: every time you try to maintain the principles of blockchain, you wind up succumbing to the very things that you say. Oh yeah, it'll be faster if we have less decentralization. Yes, Solana is faster than Bitcoin and faster than Ethereum, but it's also less secure. These trade-offs are fundamental. Is a linked list fine? Sure. Yeah. I like linked lists. But do I think that you decentralize all the things simply to decentralize them? No. Right tool for the right job, as you say.

Kevin Well, as I said, decentralization is a tool by itself, right? So if you need it for some kind of reason. I definitely think there are certain cases, you know, just think about, that's my but basically: not so stable governments, not sustainable countries, just those edge cases, right? Where you actually can't rely on those.

John And, I don't know, I don't know what you're saying, but here's my gun, right? Gun trumps, right? So does that really solve it? Again, this is where zero-knowledge cryptography and digital identity definitely, you just don't need a blockchain for it. Or maybe you can anchor attestations and DIDs and stuff. Maybe it's fine. But at the end of the day, what we're doing right now in the States is implementing digital driver's licenses and that sort of thing, and it's all just coming off the secure enclave on your phone, and no blockchain involved. You don't need any crypto to do it. So yeah, digital identity, secure digital identity against somebody making you, right. You definitely don't want the bad guy to know that it's you. Journalism. But it's not a panacea for that. I mean, what we have to stay focused on is the problem. Getting journalists, less journalists killed, is the problem. It's the problem to solve. It's not, hey, blockchain, let's see if we can save journalists with blockchain.

John There's a very nice person in the blockchain space who I quite like in many ways, but they would drive me crazy with this one line. They would say, we are going to save the world with blockchain. And I'm like, can we stop with this? Can we just start with: save the world? And let's focus on that. Just focus on this. Let's save the world. I mean, I'm all in on that. We put a lot of constraints if we say, with blockchain.

John's Time at IBM

Kevin That was funny. I mean, you see that with a lot of things, right? It's not just blockchain. It's also AI, content computing, all these things, right? We see that when people come to us with projects: I want to use Web3, I want to use AI, I want to use that. But instead, oftentimes you have to scratch all these things and ask them, what do you want to do? Do you want to raise money with this? Do you want to get your first paying client? Do you want that? Then let's try to figure out a way how to spend the least amount of time and money to get there.

John You know, when I was at IBM and we started Hyperledger and Hyperledger Fabric, I would be my own worst enemy. It was weird. I could get a sale out of a big bank just by nagging on it. I'd be like, why are you using this? And it's my product, right? And then I'd be like, why are you using my product? You shouldn't be. And they're like, oh, now we really want to use it. And the funny thing is, if I had a nickel for every time some company, usually a big company, the team, and I would challenge them with this, a nickel for every time that they said: well, we don't really need it, but we've been trying to solve this problem for 10, 20 years, and if we call it blockchain, the boss will fund it. I mean, that doesn't happen anymore. Nobody cares. In fact, calling something blockchain will kill the project. But yeah, I think that may be the thing that will kill crypto faster than anything else: crypto requires hype.

John Crypto cannot survive. If a blockchain could support a cash use case, global cash, I'd say I would have a different point of view. But we know it can't. And don't talk to me about Lightning. It's not going to, no. Because again, the problem is that the marginal transaction cost of a transaction on any kind of blockchain is non-zero, whereas in even the worst of banking systems, the marginal cost of a transaction limits to zero. The banks charge you a fee because they can, not because they have to. And so these are basic problems with the cash use case. If it could be cash, I would say okay. Or if we said every token was an actual security, I'd be okay with that. I don't like fleecing grandma. I don't like opening up all the same loopholes that we had in the 1800s that fleeced grandma, that made us go into creating the kinds of regulations that the SEC did in '33 and '34, which still are valid today, by the way. But if we said, yeah, every token is actually an investment contract, and we're going to keep track of that investment contract on a blockchain, I've got no problem with that. Just call it what it is. It's an investment contract.

Making Financial Infrastructure More Efficient

Kevin Something really interesting now that brought me to a point that I never actually thought about. What if, I think that's a thesis you might like. Banks are able to charge those fees, right, which are really high oftentimes. Banks, for a million dollars, as high as buying a pack of gum with Bitcoin and costing 200 dollars for the transaction. If you transfer huge sums from the US to, I don't know, China or wherever, or just in Europe, you already pay a nice fraction of that. And I'm just thinking, what if, just for the sake of the goal of making the financial infrastructure more efficient, just by blockchain existing, it forces banks to lower their fees?

John Yeah, that could be. If the ultimate thing is that crypto kind of becomes a dark web money, and it's not a thing that most people deal with, but it scared the crap out of the banking system and it made the banking system get their act in gear, yeah, there's nothing wrong with that. And there's a really good book to read if anybody's into this stuff, called Moneyland. Moneyland is a really good book. It's not about blockchain, but if you look at the dates for when a thing called FATCA started making it very difficult to use Swiss bearer bonds, untraceable bearer bonds, to move money across borders with impunity: that was around 2008 to 2014. What was coming up in 2008 to 2014? Yeah.

John I don't think Bitcoin is digital cash. I think it's digital variable-price bearer bonds for people who have, either legitimately or otherwise, a really strong need to move large fistfuls of money across borders with pseudo-impunity and avoidance of tax. That's a real good use case for it, because it's a relatively small number of transactions, large amounts. And the thing is, the kind of folks that need that often aren't the kind of folks you want to know very well.

Kevin Well, what shall I say? Nobody knows for sure. At least, I always try to keep just open. But, as mentioned before a couple of times: choose technology where it makes sense. Blockchain, absolutely agree with you 99, 98 percent of the time. And we tell that our clients as well: it doesn't make sense, right? Or it's just a solution by itself, for its own problems. But, as you also mentioned, maybe decentralized identity could be. Or at least, I consider ZK part of blockchain, for example, right?

Is ZK Part of Blockchain?

John I really wish we would get away from that. ZK needs a life of its own. ZK works. Computationally expensive, but there's nothing in the laws of physics that prevents it from delivering on its claim, which is that you can prove anything under NP, or IP, under zero knowledge. Some things are harder than others, but none of that is fundamentally impossible. Even conditionals can be done. And what's really good is to run them on regular compute, right? I got a computer. You got a computer. Not blockchain. If you have an SAP system and I have a Microsoft Dynamics system, and this guy's got a spreadsheet, we can do things on regular computers with zero knowledge. Putting zero knowledge on blockchain is like putting an extraordinarily computationally expensive thing on top of another extraordinarily computationally expensive thing, which makes not a lot of sense to me. Although, thank you, gambling money, for paying for so much zero-knowledge research. Thank you very much.

Kevin So here's my but: what about the verifiers? Basically, it's a hash that you put on chain, say, well, don't tamper with that hash, like with the verifier, so that the proof is actually correctly validated. If you have it on a computer, you definitely can change that.

John You probably can do that. You absolutely can generate your zero-knowledge proof and do your circuit on one computer. And digital signatures, we know how to do that. It's fairly trivial. But then, yeah, where do you put the proof? And you don't need to verify the proof. You can just store it on a tamper-resistant system. And if you want to run a verifier on a blockchain too, cool, that's great, but you don't have to. And it's expensive too. So why do it if you can do it more efficiently on regular compute?

Kevin That's maybe now really a great but, right? So basically just trying to understand: do I really need to make sure the verifier is not being tampered with, right? We both know that for 99 percent of all cases, it's totally fine to just have the verifier in a single regular JavaScript file or whatever, on your own computer, on a server. But maybe.

John Well, you can also, with like SBOM, a software bill of materials, or a bill of lading. So there are ways of achieving the goal of what we want with that, simply by saying, okay, the verifier is a high-performance system, and here it's centralized, but it's also observable, right? And we can state-hash it continuously, and we can have people observing that. And certainly for a bunch of companies trying to make sure that they're not playing shenanigans on each other, it's perfectly fine. And, you know, there's just a lot of it. I've found myself having a very difficult time finding use cases where I need supreme decentralization on every single thing. I just don't see that.

Kevin But yeah, just you mentioning the verifier things, that somewhat goes into that direction, right? So it's always about how much resources do we need to put in as well. That's also kind of a framing I really like. Blockchain is an asset. It's an existing infrastructure, right? When you have to build these semi-decentralized systems yourself, like coming up with a logic concept for that, it maybe requires more work than just deploying that simple verifier on chain. So maybe that could be useful.

What About Smart Contracts?

John Certainly. The problem is we've been sucking in a lot of the journeyman new developers, right, who get excited about the new thing. And the POC works fine, and it's exciting. It's easy. Well, it wasn't always that easy, but you're like, oh, I'm going to use a smart contract. Anybody who's been around knows that a smart contract is basically a stored procedure on a ledger. Stored procedures we've been doing on Oracle systems for a thousand years, since the nineties. We didn't like them then. Stored procedures are really not efficient, not a good way of doing business logic on a data set. It's not a great way, usually.

John But, you know, Vitalik said, hey, let's do smart contracts on a blockchain, and it opened up this whole thing. And sure, yeah, if it could scale, or if we didn't then suddenly go out and create a bunch of securities and not call them securities and fleece a bunch of grandmas, then that would have been super duper, right? But it turns out that stored procedures as a design pattern isn't awesome if you can achieve the goal some other way. But now, yeah, there's a lot of people that are excited about smart contracts, because we've been telling them to be excited about smart contracts. And I'm here to say, hey, think for yourself, and don't let the blockchain hype masters fool you into supporting something simply because they want their coin to go up.

Kevin It's always, if you go right at the beginning: what intentions, right? That's in fact really a sad thing to see, that many people preach what they aren't, right? So they don't stick to the vision they put online, and just do something else basically, right? They have all these receipts, and then they let them dump on retail and people. All of these things ultimately are mapped to, you know, bad intentions.

Why It's Hard to Go Against Your Wallet

John It's hard to argue with you. It's hard to go against your wallet, right? And I spent eight years earnestly trying to find some not-crypto way of using a blockchain. And at the end of the day, when I couldn't, when I was out of buts, I said, hey, I'm out of buts. And I said it openly. And not everybody loved that. It's funny, the degens loved it, because I spelled blockchain correctly, and that's all I wanted. But the guys trying to sell enterprises on this stuff, I don't think they had a big sense of humor about it. I got a little bit of blowback from them. But the interesting thing is, one day I was on a call with a professor, and I won't say who it is, for their career. But I was like, look, I think I know distributed systems, but I know you do. And this is a very famous professor, a professor with big courses on blockchain, hundreds of thousands of people, books on blockchain, all that. And I said, I don't think that we can scale it, and I don't think that layers or ZK or any of these things actually solves this for any use case that we're claiming. Why am I wrong? If you could show me why I'm wrong, I'll flip right around, because I believe you know what you're talking about. And they went, no, of course you're right. But I can't say that. Because the dean thinks that we can keep selling more blockchain courses.

John That was the moment for me. It's not just about having coin go up. It's, you know, I need to have some more courses, that we can get people to believe this stuff. Crypto was always crypto. But a technological grift I cannot abide. I'm not going to lie to you about my findings in the technological experience. I might be naive. I might not know something yet. I might be excited about something. I was excited, I am excited about blockchain for lots of reasons. Most of those reasons are valid. It's just that we got, I did, all of us, we got solutiony. We said, hey, here's my hammer, where's your nail? And it turned out that the claims we were making about the technology itself were wrong, and easily seeable as wrong. Except, boy, there was a lot of money. There was just a lot of money.

Kevin Okay. So what do you think about those alternative DLT approaches? Do you think it's the exact same thing, basically, like hashgraphs and these kinds of things? Just to get your sentiment on that as well.

John Well, going back to the Two But Rule, the question is: what are your needs driving your intent? If your intention is to do a hashgraph or something, you really should focus on what needs you are trying to address, and then forget about the hashgraph or any other thing, including AI, anything, and say: what tools are out there to get me across the line on my intentions? And there's just a lot of big buts that come up that are hard to overcome if you say, I have to do it with thing X. You know, hey, I'm glazing glass, I'm hanging glass, right? Here's a hammer. Maybe not the right tool.

Kevin That's really, you know, John, to say that publicly as well. That's really what I love about our discussions, because as I said on our Instagram story as well, you're really straightforward. You say what you think. And you have this, if I can say this, no bullshit attitude. You really think through all that, let's say, nonsense, and focus on what matters, right?

John I'll give you bullshit. But hopefully, once I realize it's bullshit, I'll tell you that it was bullshit. I'm not immune to bullshit. None of us are. But once I see it plainly, I stupidly tend to let people know that I was full of shit. And all we can do is keep our minds open.

Kevin I should be as open as I can be, you know. And I really try to get deep into all these different perspectives. And, you know, love that. Thank you for sharing all this.

John Well, thank you. You're so thoughtful on your show and in your work, and you're a great leader, in my view. So keep it up. I love some of the stuff you've been posting about the work you've been doing with young people. That's fantastic. Try not to get them too into crypto, please. But, you know, the crypto hegemony really needs the next generation to trade goods and services for their bearer bond tokens. Maybe, maybe not. But yeah. Thanks.

Kevin Either way, thanks, John, for your time. It was really a pleasure.

John Thanks, man. It's good to see you.

Kevin This was really a crazy episode. I think Ernesto agrees with me on that. Well, I really love John, and I've worked with him in the past. And if you see me posting about this no bullshit approach, building products that make sense: a lot of that I actually learned from John. So I'm really deeply grateful for my work experience with him, and even more so that he took the time to talk with me on our podcast today. And yeah, while of course I don't agree with all the things he's saying about blockchain, as you heard, with a lot of things though, especially when it comes to where blockchain actually makes sense and where it doesn't, I really, really, really enjoyed this conversation. And I'll maybe even check it out myself again, because I think there are certain hidden nuggets that I, during the discussion, maybe haven't even heard myself. So please let us know what you think about the podcast. Leave a comment below, hit subscribe, like, whatever. Thank you very much. It really helps our channel. And yeah, definitely check out John's book. I had the pleasure of checking the free version before it actually came out, so I really can recommend that. I recommend the book. And yeah, thank you for watching.