Accelerate Innovation

Cristobal Chao at UXDX Community: Innovation and Change. Video: https://youtu.be/mwqr1BQJQ6U

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Background

[00:00:00] I'm going to speak about accelerating innovation, and before I start I'm going to give a little bit of background about myself. I'm from Spain, and I went to the United States 11 years ago, to San Francisco, and I started working for a company called Hatchery Labs [?]. It was an innovation consultancy, mostly made up of designers, and I was one of the very first engineers. I worked there alongside other people to build startups from zero. A few of them went on to raise different series, and one of them actually became a unicorn, which is very, very exciting.

[00:00:40] After that, Google acquired us in 2013. As part of this acquisition I was the only engineer, and those were very exciting times, because we were part of this transformation of front end, UX and UI at Google. I was part of the team in Material Design building the first two versions, and I was also part of the transformation to this new front end, UX and UI in Google Search and Maps.

[00:01:09] Most recently, in the last four years, I started Torii Studio, which is a front-end consultancy that helps companies build products better and faster. The idea is to create systems and processes that help these companies build quicker at the same time as they are building beautiful products. Anyway, this is pretty much everything. One thing I have to say is that in the last four years at Torii Studio, five of the startups we worked with were either acquired or went to series A or B, and one of them became a unicorn, which is very, very exciting.

Are you solving the right problem?

[00:01:46] Anyway, I'm going to start now with innovation. As many of you know, you probably have an idea now, or you had one in the past, or you may have one in the future. And the thing is, there are many ways that we can build our ideas. At the end, we want to be innovative; we want to innovate in the space. But the most important thing that you should ask yourself is: are you solving the right problem?

[00:02:15] And probably the first reaction is, "Hell yeah, I'm solving the right problem. What are you talking about?" All of us think that we understand the problem better than anyone. But let me tell you, you probably don't know what the problem is. This is based on many different studies that you can find out there on the internet, but most ideas don't go anywhere, and the main reason why is because we bring our own biases and experiences and we think that we know everything. Probably a little bit of ego from everyone. But anyway, that's how we are and how we operate.

The Kremer prize and Paul MacCready

[00:03:00] With this, I'm going to tell you a little story. This was over 60 years ago. Henry Kremer, who was a magnate, came up with this question: can an airplane fly powered only by the pilot's body power? It's this idea of flying a bike, like E.T., as we saw in the movies. It seemed very crazy then; to me it even seems crazy now. But the thing is, he offered a hundred thousand pounds to whoever was able to do it and cross a canal over two kilometers. Very interestingly, he offered a hundred thousand pounds, which now is around two and a half million dollars, which is a lot of money.

[00:03:50] So guess what? Big companies like NASA were there. A lot of companies were there too, and individuals as well. Ten years passed by, and no one had figured it out yet. These companies were spending a lot of money, but not only that: any time they wanted to test any of their planes, it took months, even a year, to be built, and most of them broke in the moment. So remember: 10 years, and no one had figured it out yet. They were probably running just 10 experiments in 10 years, which is very, very little.

[00:04:33] Eighteen years later, Paul MacCready, as an individual, went to this competition, and he came with this perspective in mind: how can you build a plane that can be rebuilt in hours, not months? His main goal was to actually find a system that could allow him to do this. If he was able to do it, he thought, he would be able to find a solution. In six months, he was able to create a system where he could rebuild his plane once, even three times, every day. So he could validate his ideas and understand the problem better and better. A few months later, he was able to cross the canal and win the prize. He was competing with many different companies like NASA, and as an individual, that was a huge achievement. He invented this golden ring [?] that he's holding there, and that was the innovation. But before he got to this innovation, he had to understand the problem.

[00:05:41] This story is called "You Are Solving the Wrong Problem," from Stanford University of Innovation [?]. This is actually a paper that I would recommend you take a look at and go a little bit deeper, so feel free to use your phone and scan the QR code. It's very interesting. But I think the main takeaway here is how Paul MacCready was able to innovate. The main reason why he did it was because he was able to make quick iterations every day. He was able to experiment, whereas others would take months, even a year, to do it. So he had way, way more advantages than his competitors.

Iteration in digital products

[00:06:25] Today we're talking about digital products, and you may think this is a different space or a different story, but it's actually very, very similar. Stanford came up with this design thinking process that most of you already know. It starts with empathizing with the user, defining the problem, ideating solutions for the problem, prototyping and testing, and we want to do this again and again and again. We want to iterate. These are the iterations that I was describing before.

[00:07:03] There is this famous quote from Albert Einstein that said, "No amount of experimentation can ever prove me right; a single experiment can prove me wrong." We are talking about the same topics again and again. Every iteration is an experiment, so we want to experiment. That's the main mindset that we want to have. The more iterations we make, the closer we'll be to the final solution. But we need to understand that every iteration is not a solution; it's getting us closer to understanding the problem.

[00:07:39] Here's one of the questions that you need to ask yourself in the life cycle of any product, which is: how accurate are our assumptions? When we are trying to iterate in digital products, we can start with paper, which is the fastest way to get you there. You can start by drawing something quickly and then validate your assumptions, but the quality of feedback is not going to be that great. You want to go all the way up, from wireframes to low fidelity, high fidelity, fully functional, and product. And product is actually the real deal. That's when you actually get punched in the face, and it's painful, especially if you are just doing it for the first time. And now you can understand why: when we're trying to build something and it takes a long time and it fails, because it should fail, it's very painful.

[00:08:34] Another question you want to ask yourself is: how fast can we iterate? The faster we can get to the product, the better, but that takes the longest. So we're going to start with paper again, but at the end of the day you want to get to the product as quickly as you can. And again, it's usually very long, especially if you are in a big company, companies like Google, Amazon, Apple. It takes a long time to get you there. It's exponential, if you think about it.

[00:09:08] When I was at Google, there were products that took years to be built, and that's another reason why we can say that Google, in the last 10 or 15 years, hasn't innovated much. There were some innovations, I have to say, and I'm proud of some of them, but we haven't got there. Big companies especially have a big, big problem here. If you look at ChatGPT and Google these days, the main innovator was a very small company in comparison to Google.

Designers and developers together from the beginning

[00:09:38] Now we're talking about the life cycle of any product: how can we divide the different responsibilities? Nowadays this is how we see the picture. Developers own the product; the rest is owned by the design team. This happens quite a lot, and I want to challenge this a little bit. If we look at the innovation phase, it looks like this: development is just 10 or 20% there, and design takes almost the hundred percent of it. We want to question this with: what if we can have designers and developers being part of this innovation from the very beginning, and mixing responsibilities? I think that is very, very important.

[00:10:32] How can we do it? What we have to do is unlearn everything that we've learned. We want to apply a kid's mindset. A kid is the fastest-learning creature in the world. There is no one faster than him or her. Kids are super, super fast learners because they don't really care. They experiment with everything that they do. They don't bring their own biases. They fail and they don't care; they continue. And what they are actually doing is learning everything at the speed of light. If we look at ourselves as adults, we bring our own biases and we become very rigid. So we have to be flexible. We want to apply this kid's mindset. We want to play. We want to have fun doing these iteration processes.

Design systems and reuse

[00:11:24] So how do we start? If we look at today's life cycle of any product, we can look at design systems as a tool to get us there. Design systems, as you may know, can bring consistency to every single product, because it looks and feels the same, which is awesome. But I think the most important aspect of design systems is the reusability part, because you can start reusing things in such a way that you don't have to build them, and that allows teams to put together different experiences very, very fast, instead of spending so much time building the perfect components. If we can reuse those components, at the end of the day we can iterate as quickly as Paul MacCready, and I think that should be our goal.

[00:12:19] Another thing to keep in mind is we have three tools that can get us there in no time. HTML5 components are available for everyone to start using, and you don't need to pay a dime for them. I mean, the experience looks very ugly when you put together something like this, but at the end of the day you can start testing your assumptions. You can start testing your ideas with a very simple approach. Craigslist was very innovative in its space by using this approach. I know that today it's a different thing. Users are expecting more from you; users are more picky in the digital world. So you may want to evolve over time to things like Bootstrap or Material UI, where it looks and feels better, and where these components will help you get there way faster.

[00:13:19] Anyway, I'm also going to share one very interesting and very exciting article, which was released today by the CTO of Figma, which is "Making Figma better for developers with Dev Mode." I think these are very, very exciting times, because now Figma is getting into the development space, which means that you can use the Figma tool, which you probably do these days, and then connect with the other side of the picture, and connect your tools like Jira, GitHub, even your IDEs, to start getting the most out of Figma, and the other way around. This is very exciting. I hope you can scan it if you haven't seen it yet. It's very interesting. I haven't played with it, I have to say, because this is in beta and it was released today, but from what I read, it has a lot of potential.

[00:14:16] Another thing I want to share with you is a workshop that I did recently. It's free, and you can actually build a design system in a couple of hours, so you can start building these products way faster. This is something that you can do on your own. Again, if you scan the QR code, you will get the URL and you can save it. One thing I have to say is it requires some technical knowledge. It's beginner technical knowledge, because you need to know how to run your terminal. If you don't, you're probably going to have a hard time, but try to challenge yourself. Try to see how far you can get.

AI tools and the next Paul MacCready

[00:14:58] And here's something that you probably know, because it has happened. This is probably the biggest thing in 2023, and you probably know it already: AI is here with us, and we're going to be with it for quite a long time. There are tools like ChatGPT, Midjourney, GitHub Copilot, and this is just the beginning. The reason why I want to bring up this topic is because these tools are free. At least ChatGPT is free. Midjourney you can use, I think, until, I don't know, I think it's a few days, not sure. But I have used it. I have to say, with Midjourney I put together this illustration on the left side in a matter of minutes, and I am not an illustrator.

[00:15:40] I know it's also controversial, but I have to say that if we can use these tools to expedite building products, we should totally do it. ChatGPT also allows you to get to the next level faster and quicker. It's an assistant that is also free, and you can start using it. If you haven't, I would really recommend you do it. I will actually challenge you, if you are interested, to build the design system from zero, from the workshop that I shared before, and see how far you can get even if you are not technical. I really believe you will get further than you think, and you will learn a lot. At the end of the day, these tools are supposed to extend our knowledge, to help us as assistants, where we are actually the digital creators.

[00:16:37] One thing I have to share as well: if you are interested, I am putting together a workshop, and it's going to happen in the next few months. I want to learn more about you. I want to learn more about what topics you are interested in. My main goal is to build something that can allow you to go from zero to one without any technical knowledge. So I would recommend you also scan this QR code, because I would love to get you the right content here.

[00:17:03] These are very exciting times, and this is something that I also want to share with all of you: the next two to five years are going to be very, very exciting in terms of innovation, especially with the tools that we have out there today, which are free and which everyone can use. We can be the next Paul MacCreadys. We don't need to have a huge company behind us. We're going to start seeing companies that are successful with just one person. And I really believe that some of you today, if you are interested in this topic, will get there faster than you think.

[00:17:42] Anyway, this is everything. Thank you so much, it's been very exciting. I've set my QR code there just in case you want to connect with me on LinkedIn. I would love to know more about you, especially if you are interested in this topic, which I love talking about. Anyway, thanks a lot, and I hope to see you soon. And now, I guess, questions. Catherine, I believe you are muted.

Q&A

[00:18:15] Catherine: Thank you. That was really great, so thank you for that. There are a few questions, and I have a few questions, but I want to get to someone's question first, because I like it and it's very topical. With the advances of things like Figma, there are many people who say that low-fidelity wireframes are not needed, let's say hypothetically Balsamiq, or even going from paper, as you mentioned. Would you agree or disagree with this statement?

[00:18:46] Cristobal: That's a very good question, Catherine. I believe those tools are still necessary, especially if you want to prove your assumptions. You just need to keep in mind that these tools are not going to get you the full accuracy of the feedback. The quality of feedback is not going to be that great, but it's a great way to start. Then what you really want to do is build the product. You want to get there, and you want to get there fast. If you don't have a team, there are ways to get you there. As I shared, these days, with AI tools in particular, anyone can actually build their own products. So I would encourage everyone to actually spend time and understand how this works, because at the end of the day the one that is going to learn is you, by spending that time. Those are like assistants, at the end of the day.

[00:19:41] Catherine: Yeah. And being an agency, you've worked with a lot more companies. At what stage do you get engineers involved? Do you have a best practice?

[00:19:53] Cristobal: Yeah. This can be done in many different ways, but what I will say is the most efficient way is to have your engineers involved at the very beginning, when they can be part of the ideation stage. I think that's the right time when you want to have those engineers involved, because at the end of the day the engineers will be able to tell you whether or not something is feasible, and also build something quicker if they have the right mentality. So you want to make sure that these engineers have the right mindset as well. We don't want to build things in months or even years; we want to build things as quickly as possible. So having the right mindset in the team, having the right culture, I think is very important as well.

[00:20:39] Catherine: Yeah, absolutely. I would mention Ed graphs about caveat [?] being on the company's size for life cycle iterations. What large companies and enterprises have you seen do iterations at speed well?

[00:21:03] Cristobal: I will say Google, for example. When I worked at Google, it depended on the team, but I have to say that there were teams at Google that did this very well, when we had small, focused teams where we could have designers, engineers, even researchers as part of the very early stages. That's actually a great way to start collaborating and building something fast. There were times when I was at Google that I could see that happening, and I think those projects actually went very, very well.

[00:21:39] But yeah, I know that is also hard, depending on the company that you work in and also the dynamics. But if we can have these small teams that have different disciplines working together from the very beginning, working like a startup in a big company, I think that's key. And also, I will say, culture. I have to say that Google also had the culture part very well there, in terms of the 20%, which is that you can spend 20% of your time trying to think about a new idea or building something on your own. I don't know if it happens anymore. I haven't been at Google for the last four years, so I can't really speak about it, but when I was there they had it, and actually I have to say that I went through that process as well. So yeah, that's really exciting too.

[00:22:34] Catherine: And did Torii come out of there?

[00:22:36] Cristobal: No, it didn't. I actually failed, because I was not doing the right things. I was operating like a big company, building a product and taking forever. You don't want to be there. And I'm speaking about my own failures, so I know that I went through that in the past. Even though we know the theory, the practice is the most difficult part.

[00:23:05] Catherine: I have one more quick question. When it comes to iterations at speed, there are companies, like pharmaceutical, zero risk tolerance companies, out there that would argue their point that they cannot afford to make mistakes. What is your advice or opinion on that, and what would you say to them?

[00:23:30] Cristobal: I would question that thinking. I guess my question is, why can't you afford to make those mistakes? I guess these companies usually have sensitive data. They have certain things that don't really allow them to go fast or iterate fast. But I think the most challenging part is to be creative. If we can create a process or a system where we can simulate experiences, if we can fake this data, if that is the problem, we can always circumvent everything. I have seen that already from healthcare companies, going from that particular scenario. So it's also about changing the mindset as well. We think that we can't, but why? Let's go to the very root of the problem. And if we can find creative ways to get us there, I think that should be the goal.

[00:24:36] Catherine: Absolutely. Well, thank you so much, Chris. It was an absolute pleasure. I really, really appreciate that, for changing the ways that you work. But as with all things product development related, there is no one-size-fits-all, so please do share your thoughts in the comment section below and let's keep the conversation going. Finally, if this video resonated with you, please do us a favor and hit that like button and subscribe to our channel. This not only keeps you up to date with all of our latest content, but it also helps us with the YouTube algorithm. Lastly, if you want to keep learning, we have a couple of videos suggested here, but otherwise, until next time, take care and enjoy the rest of your day.