Most people and companies aren't tool-builders

Hi, I'm Tony Karen Brown. And I'm Benedict Evans. You wrote a piece about new tools. And that doesn't mean that automatically people will become tool builders. And you have a lot of reasons for that. It is. So there's this sort of weird narrative that says, you've got Cloud Cloud co-work. And you won't need your software and it won't need software anymore. And it will change how you work and it will transform how you do what you do. And everyone's going to have this. And I kind of looked at this a little bit and scratched my head. And I thought, so is this, you mean the way Microsoft Access destroyed databases? Which is sort of a facetious but kind of relevant comment. And I thought there's sort of three building blocks to think about here. Which is that first of all, like most people don't see the problem that you're going to automate. Most people could not build that tool, even if they did see the problem. Do not think in the right ways that you need to think to build that tool. And that's got nothing to do with writing software. Nothing to do with writing code. And most people are not in a position that they could get that deployed and used even if they did see the problem. And even if they were able to think about the right way of building this thing. And so if one sort of unpix each of those things, if you actually go and kind of remember how most software works. Like, how many of the tools that you use today were something where when you first saw it, you didn't get it. And you thought it doesn't make any sense. I would never do that. And that applies. I don't need that. I don't have that problem. I don't even have that problem. Never mind. Yeah. And so most people are not sitting thinking, how could I automate this task? How could software change it? How could this be improved? And of course, if your software developer, that's all you think about. And so this is like an alien mentality. But most people are busy doing their actual job and not thinking about how they would automate it. I think the second and kind of perhaps more useful point is that there's a huge difference even between seeing the problem and being the right person to work out like what should the processes and the workflows and the networks and the functions be that would make this great. And particularly a whole bunch of categories where like 10 people have tried to do that and failed already. So very often it's not obvious how this thing should work. Or it looks obvious. But the mark of great software is you see something and you see, oh, wow, that's a great idea. And you can't. And so then if you're a great accountant or a great video editor or a great graphic designer or great salesperson or great lawyer, there's a different skills to being the person who's going to work out the right way to make a really great piece of legal discovery software or really great piece of sales enablement, a really great sales enablement tool. Like you'll have that problem every day but you won't see it. You won't realize that you could fix it by turning it into this problem and then building a thing that did that. There's different skills and there's a different people. And then the third building block is most of these tasks are not things being done by one person by themselves. Yeah. Some of them are. But most of them you're in a team of 50 or 500 people and the data is regulated and the data touches through your four different systems of record that need to be tightly controlled and have security and compliance and audit. And so you can't just get your whole company to go and use this thing or anyway you need to get some approval from somewhere to get people to use this thing. So the example I open and it's across different teams who have different processes and different teams may be different processes, different stakeholders, different budgets, different companies. And so the example I sort of thought about here was something we looked at when I was at Andres and Horowitz called Frame.io which is like a professional video collaboration platform. So there's a piece of video being made. There's like half a dozen people and maybe three different companies who are actually working on it. But then there's 20 or 30 or 50 people across another three different company, client side companies who have to have a see it, have an opinion on it, sign off on it, check it. And so before Frame.io that would have been a bunch of private Vimeos or Dropbox links or maybe some FedEx hard disks and then it would have been an email thread. And if you were lucky it would be a Gmail. A shared a shared Google sheet with time codes in one column and then comments in rows. And Frame.io says, no, we're going to do version tracking and you can go to that frame and draw a circle over that frame and you have permissioning and tracking and all the stuff you can imagine you would want there. Now if you are the colorist or you are the person doing review at the ad agency but not the client or the marketing, the CMO at the client, you're not the right person to see all of those problems. You're also not the right person to get it. We wanted to use this. And so there's just this kind of huge gap between we give everyone a tool that can make stuff and therefore everyone is going to make new tools. So do you think this idea of like getting the other 49 people to use it and adopt it? Is that still a bottleneck where potentially in this day and age there is no it to adopt? Just every person can sort of create their own assistant to do the connecting work and the building blocks. Everyone can create their own agents to help. Do you know what I mean? A cast that has, have we shifted in that everyone can build their own agent? So there's no sort of central it to adopt because we've now got agents talking to each other. So I think the, well, I think the answer to that and this kind of comes back to the counter argument talk to all this is how many like 50 person company departments run on a 10 mega Excel file? And the answer is quite a lot. I wildly go as the quota I've made into a slide. Somebody told me on Excel that someone told me on Twitter that half of their jobs were telling people to use Excel to use a database and the other half were telling people to use a database to use Excel. And so there is, yes, clearly there is shadow YT. There's a whole bunch of software. You know, every big company has five different mail-to-appearance. But that's slightly different. That's not somebody in marketing said, hey, I'm going to build my own marketing emailing software. They went out and bought the software and then their team is using it. That doesn't change how that doesn't replace the big iron software that the company's already using. So and the typical big company today has four to five hundred sass apps and many of those are bought bottom up. But they're not built bottom up and the reason they're not built bottom up isn't that it's hard to write the code necessarily. It's that there were all these other strictures in how you would think about what it should be doing and how it should work. Now go back to that 10 meg Excel file that a department is running on. No one actually knows who built it. No one really knows what that sheet is doing. Now there's a whole bit of it that's blocked off in red as like don't touch us. We don't know why it's here. But he could break the whole thing. Yeah. And there's always a point where the company says now it's time to move to software. I mean this is kind of my point about institutionalized software versus improvised software. There's a point where you do it in Excel and it's a point where you buy a thing. Because you want to know that somebody's thought about how it should work and somebody is responsible for it and will fix it and there will be bug fixes and security. Can you argue that people who were built and who are using the Excel sheet though are kind of tall tall builders themselves? Or do you think that's pushing the narrative a bit? Well the question is how many people do that? How many people are actually building the big Excel? We're building the Excel sheets to do all of that. And you know there's clearly a kind of big kind of fuzzy area. Is this spreadsheet database? Sometimes. Yes. What exactly is the dividing line between a 500K Excel file and SAP? Well there are a couple of kind of breakpoints along that transition. But there isn't kind of one point where you say this is no longer a spreadsheet. This is nowadays base. I'm sure there's somebody screaming at this saying no, no, it's about joins tables and things. But there's a sort of fuzzy continuum between a word document and SAP. There's a word document that contains your holiday policies. At a certain point there's a system in workday that says it tells you what your holiday allowances are. And yes, AI kind of moves those back and forth. But the thing I kind of wanted to get to is starting at the beginning. Most people don't see that you could do that in software. Don't see how we could change how you do this. And because they're busy doing something else, they're busy being really good at sales. They're busy being really. I mean this is also the kind of the conversation about notion, which is how many people think in terms of, oh, I'm going to build a notion to run my life. And of course, if you're in tech, they want to be everybody. If you want to do that. And you don't have any other ideas. What do you mean you don't have any other options on your life? Well, a can-band board. What do you mean you're not running in this? And the reality is there's a certain kind of person that thinks like that that meshes with a certain kind of job. You bring up Slack and notion a lot and sort of these outliers. And curious, what do you think the two have in common that let them be the agglatious? So most people aren't tool builders. Well, so obviously one person can build the notion that other people use. And it's a lightweight collaborative database system that doesn't otherwise have kind of good parallels. Slack had a network effect in that one team would use it and then someone was working with that team. So they would use Slack and then their team would use it and then they say we're kind of spread organically. There were very, very few pieces of enterprise software where that's actually happened and where that's worked. It's like the Slack and that's about there's like one other I forget. And what this is, you know, it's kind of the point I made at the beginning of the essay was there was this whole story kind of 10, 15 years ago in the valley that like enterprise software will become grassroots. It'll be bottom up bottom up enterprise bottom up cells. You won't have to go through the sales process. You won't go to CIO. You won't have to wait a go through a 18 month cycle. The users will see the thing in bite. And it turned out that that gets you 5% of the market. And for everyone else know actually you need to get an evangelized you need to explain to people why this is a thing and why they need it and why they need to budget for it and why they need to buy it. And you need to explaining to people why the problem exists, and then you need to show them why your things solves it. And generally, five other people have tried to solve it before and failed, which is another problem with the while people will just build their own tool. They'll build a tool that they'll use it, so it doesn't work. That doesn't solve the problem in the right way. And so this is a space, I suppose, as a sort of a high level point in here somewhere, which is, you know, it's the thing I kind of keep coming back to, is what are all the ways that AI is, this AI thing is kind of completely new and different from anything that's happened before, and what all the way is, and it's kind of, it's a new flavor on what happened 10 years ago, and 20 years ago, and 30 years ago. You know, I do keep mentioning notion. Notion is a no code story, no code was a story from 10 years ago. No code in general, worked up to a point. But it still doesn't sell itself just because it's easy to make and easy to use. Exactly. And go back in our previous generation, and I mentioned in part of the passing access, which I don't even access even exists anymore, but like nobody will need databases anymore because you can just make your own with access. And I made a access database from my mother's publishing business, it was great, but that didn't replace every other piece of software, or neither did Excel. Excel didn't replace accounting software. One, one timeline there, but like we have both, we have both quick and an Excel. Most people don't do the taxes in Excel, most people use quick, quick rules, because it's more complicated than that. And so I suppose there's a point here, which is, you know, this will be more software, and people will use this to make tools the way they did with no code, and the way they did with Excel, and the way they did with all those previous things. But it doesn't actually fundamentally change the dynamic, it just shifts those thresholds another level. And it's interesting, because if you're saying, look, AI doesn't eliminate the need for someone to see the problem, and you still then need to sell the solution internally and get everyone to adopt it. Are we shifting the valued end back to products and go to market strategy, which is what we always talk about? The different J-TOS aren't going to be how good the product is and what it does, but it's going to be adoption, and selling it as this sexy new tool that you all need to have. Is it a better engine, is it a better marketing? Well, this is why people love this word taste, all of a sudden. Yes, the taste makers of the world, when it takes-- But the decision-- Well, though, it's like the decision of knowing-- if writing the code-- writing the code isn't the hard part. Writing the hard part is knowing what the code should be doing. It's seeing the problem and knowing the right way to do it. It's the opinion. And there's many different ways you can look at this. But in principle, what an alarm does is it tells you how many people will probably do that. And so is that what you want? Or do you need to think of a new way of doing this, or have you sort of a new way of doing this, and you want that? Well, the alarm can do it if you can explain it. If you know how to explain it, if you are the kind of person that knows what software is and how it works, and what the things you might ask for might look like. But if you don't know what those kind of modalities are called, and how they work, and what people have done before, then you won't sort of sit and think, oh, well, you know, what we could do is we could take that thing that used to work for this in this industry, and we could change it like that, and we could make it work here. If you're a really good lawyer, you haven't seen all of that stuff. You don't-- that's not what you spend your time thinking about. Do you think that becomes then a de facto new skillset that you can be an incredible lawyer, but if you don't understand how to think through the next or next-of-the-tools, then maybe-- I was going to pull that in another way, which is that the lawyer has all these new way eye tools, and so what matters is your opinion as a lawyer, as opposed to doing the law the way everyone's doing it. As a lawyer? Not the process, but yeah, how you get to it. Yes. Your value as a lawyer is doing something that isn't exactly how anybody would do it. Your value is a developer as writing the code as you want the code written the way anyone would do it, but the point of the product is thinking of a product that isn't how everybody would do it. And as a lawyer, your skill is in having opinions about law. It's not in having taste in opinions about software. It's interesting I'm seeing that even as my-- my stuff in Formula One used to be very factual, and now the reality is good facts and the most adequate or the most recent side facts are easier and easier to get that people are actually asking for me for my opinion on something, and how I would solve a solution, which are things that I would normally never touch. But I must be the same for you as well. It's easier and easier to put together a newsletter, but actually to have a stark opinion that drives a conversation is more valuable. Yeah, so a billion people are using a way to make these letters. Is that true? What is your voice? That a natural stat. Billion? No. No, I'm just metaphorically speaking. Don't be so clear. Don't be so clear. I think I just want a stat and another one. I don't even know anything like that. Well, metaphorically speaking, lots of people have their enormous number of robo newsletters. But then the question-- and the narrow problem is, they're not very good, but the deeper problem is, they all say the same thing. They all say what anybody would probably say, and that has no value. Or it has value for one of them, but not for millions of them. And this is about my point. If you have great taste and opinion, if we're going to use a term about how to be really good sales, that's a different thing to having good taste and opinion about what enterprise sales software should look like and what new problem you could solve with it. As I said, most people on tool builders, the people who are using the tool are not the same people as those who are really good at creating the tool. Now, sometimes it's the other way round. To make good software to do that thing, you have to know a lot about that thing. But those aren't the same point. You have to know a lot about sales to make good sales software. But being good at sales does not mean you're going to make good sales software. OK, there we are. I'll explain the world. It's funny, though, because it is this sort of recurrent thing every 10 or 15 years, like no, Kate, people will make their own stuff. And it's something you see very clearly now around co-pilot and co-work. And what's the word? Chat, e-p-t-work, and chat, e-p-t-open AI just suddenly replaced everybody's chat with this weird, bungled up, completely chaotic, and confused thing called work. And it's like, well, what is this? And why does it work? Because that's what everyone will be using. Everyone will be writing their own code. And it's interesting to know. I did have, I think, this mentality or this thought that the hard part was actually building the code. But it's actually not the code. It's knowing, as you're saying, it's an understanding and knowing the tool should exist in the first place and then getting everyone else to use it, which I agree with the last bit that has always been my struggle. And so now I'm thinking, well, in a world of AI, where you can build your own agents, are we still going to have to worry about adoption and convincing other people to use it if-- Yeah, because people won't see the thing that they want the agent to do. And then they won't be able to work out how they want the agent to do it. They won't be able to articulate that. Most people can't-- It's like content-general. --of how they do their job every day. It's still a thing that people have a hard time doing. Yes, it's funny. People say, prompt engineering is gone, bullshit. The underlying challenge is, how do I work out? How would I tell the model how I want to do this? And that's not-- it's not like you have to say clever things to get the model to work in a different way. It's like, how would I tell a 19-year-old or a 25-year-old how I want to do this? And how would I know that I want to do that? And how would I know that problem exists? And do I have the kind of tasks that are obvious things that you could automate? Some people have a bunch of really repetitive tasks that they do every day. And it's kind of tedious and pain-gain and time-consuming. And they say, oh, I could get AI to do this. A lot of people don't have a specific thing they do every day that's tedious and repetitive. And that's obviously-- Or they may do, but they don't realize that they have it. They may not see that that thing is there. Yeah, because they've always done it that way. And they've cut-- and most people don't-- They've always done it that way. And they haven't realized that they're doing this tedious, automatic thing, because they're kind of not doing it. Or they've never done it because it couldn't be done or because it would be tedious. And now-- and then you give them a piece of software that says, wait, but I can go and do that for you. And it's not-- it's seeing the problem. And then realizing how what the tool would be that would solve that and then getting everybody to do it is quite different from giving everyone a piece of a thing that can make tools. There's a different-- Yeah, because we-- because the tools might be there to make the new tools, but the reality is that the people haven't changed. Is what we're getting to. Exactly. The software has gotten better and better and the no code tools are there. But the reality is we haven't changed. We're still the same people that we were. I like that. OK. I like that. There we are. Have a nice day. We should-- We need to-- I was going to say we need to pad this out for another two hours. This is going to be a proper way out for class. Shortens the syncs. This is good. Shortens the syncs. There you go. Good chat. Three questions, three answers. I like that. 20 soon. Great. Speech you later. Bye.