The Adventure of Inventing: A Guide to Building Impactful Products

Our CEO and Co-Founder, Tony Scherba, recently gave this presentation on building impactful products, in which he discusses the three most important elements necessary to build successful products. Enjoy the video!

Video Transcript

My name is Tony Scherba, as you probably all know. I’m the CEO and one of the co-founders here at Yeti. What I want to talk about today is a little bit… I want to dive into the adventure of inventing. It’s on our wall, it’s on the front page of our website. But we haven’t necessarily like articulated really what that means. And so, I mean, the processes of related to a lot of you of writing a book about our process and how this works. And even this morning you were talking about a lot of the problems that we tend to have with clients or what not is related to not sticking to a process, not sticking to things, and not following a process. So what I want to do today is I want to articulate a little bit further what the adventure of inventing means. I’m going to share with you some of the progress that I’ve made on the book and then after it I’ll probably get some feedback on it.

So this is a [inaudible 0:01:19] book from the 70s. It’s about architecture but it really talks about exploring the way in which things are built. One of the premises of this book is encompassed in this quote, “It is the process which creates the organism and it must be so. No thing which lives can possibly be made any other way.” When we’re building things we’re breathing life into them. So whether it’s organic or whether it’s something incredibly technical we’re trying to give it life. We’re trying to make it live and breathe, and it’s the process that does that.

So as I have been going through and trying to figure out, actually like, intrinsic reasons like why I’m attracted to this, specifically, I have been thinking about my personal life and my personal influences. And so I feel like building things is in my blood, my grandparents. Specifically, this is my grandfather working on [inaudible 0:02:28 bar]. He was a civil engineer; working on [bar] back in the day, one of the stations up here. [Bar] was really state of the art back in the 60s. You know, [inaudible 0:02:41] now. And then my other grandfather opened an auto part store and he was an auto mechanic and he fixed helicopters in World War II. So I feel like personally that if I was born in any other place and time I would be like a civil engineer or auto mechanic or something like that. But I happen to be born in the 80s and grew up with the backdrop of the internet coming about.

So, software is the craft that I’ve picked up. And so over the course of several years building things on the computer, I’ve built a lot of toys. And so I characterize my early career as building a lot of things that were fun. I built the Britney Spears App. One of this was my first website back in the day; it was Rate My Bling. People made [inaudible 0:03:49] bling and you got to rate it. So that was really fun. Rudy and I, nine years ago, founded Yeti specifically around building meaningful products. So it was about making sure that we did things that had more of an impact than just like building a toy or something like that. We’ve had a very successful brand. We’ve been featured in a lot of different media. We’ve worked with… This isn’t even updated, this is like an older slide. We’ve worked with named brands from around the world. Built a lot of things, startups that we’ve helped raise hundreds of millions of dollars, done hundreds of millions in sales from stuff that we’ve built. So I feel very good about all of that.

But really coming back to that adventure of inventing, there’s something around building that is codified in the way that we do things. And I feel a lot of times with software, because its intangible, we lose that. So I think it’s important to look multi-disciplinary and both in other areas of like how other people build things. And when I’m talking with clients, I specifically talk about how building a software product isn’t so much different than building a building, or building a mechanical machine or anything like that.

And so, I have this code up here which I think it’s incredibly valuable. This is, again, from this [inaudible 0:05:43] architecture book. “There is one timeless way of building, it is thousands of years old and the same today as it has always been. The great traditional buildings of the past, the villages and tents and temples in which a man feels at home, have always been made by people who are very close to the center of this way. It is not possible to make great buildings or great towns, beautiful places, places where you feel yourself, places where you feel alive except by following this way. And, as you’ll see, this way will lead anyone who looks for it to buildings which are themselves as ancient in their form as the trees and hills and as our faces are.”

So very high level, a little bit like, woo-woo. But there is a fundamental way of going about building things that I think this author specifically addresses, and we can apply to our practice of building software. So one of the things that I think is incredibly interesting as I actually started digging into more around– Christopher Alexander is his name - Chris’ philosophy of things is one of the ways that he believes that architecture should be done is going into a community. And not necessarily having an architect build something but having an architect go and work with the community and facilitate a discussion around what the needs of the community are. And figure out how we can build a building that meets the needs of all the people that are in the community.

And so the reason I have University Of Oregon here is the University of Oregon was actually built using this guy’s technique. And so what they did at the University Of Oregon is they had an architect facilitator and small teams, like work with small groups in the community to design the buildings. They would then have construction crews come in and build small iterations of the architecture and then over time continue to evolve it as people went about experiencing the architecture and the layout of the campus and so on and so forth. So you might be drawing parallels already but this is applying iterative design thinking to architecture. And really what he was talking about in his book is looking at the way that really beautiful things evolve over time is that we actually all kind of participate and build these structures and they work really well, and they are some of the most amazing things that we have.

So how do we apply that to the way that we build products? Over the course of time, and I have kind of distilled this down, but we’ve worked on this as a group a lot, is that there’s three components of successful product, like product builds. Things that we‘ve done and we feel really good about and that have been successful in the market etc. So a relentless focus on the user. The user experience is everything. As we just talked about with the architecture; the way a user experiences the product is incredibly important. A roadmap that evolves with your product. We talked a little earlier today about the flexibility and making sure that we’re being flexible. And then transparent and direct communication. If the three of these things are in place, usually we will have successful products.

And so we’ve built some tools around how we can do this. So a relentless focus on the user; I want to talk about that first. And I think is a great quote, “The next big thing is the one that makes the last big thing usable.” From Blake Ross, Co-Creator of Firefox. You’ve probably all seen this before. I love showing this to the clients and making sure that we put it up frequently. But a lot of the things I’m going to show you, you’ve probably seen before but I think in the context of the process and how we’re building it is good to show again. We want to make sure that the center of our world is the user experience. So we can have the design, we can have the technical piece, we can have the business aspects of it, but those all come into harmony when we focus on the user experience.

We’ve developed a general process for how we do user experience. Again, this doesn’t need documenting some of, like, a lot of the conversations that we’ve had and putting it at a very high level to our clients and people interested in working with us on how this works. We go through the process of actually documenting how people are going to experience our product. Again similar to the way that a facilitator in the architectural sense would work with a community to figure out how they’re going to build a building. So the whole purpose of going through the user persona, the user journey, creating task flows, the sitemap is all about building the fidelity of how we’re going to be working with users. And the, the visual design is an incredibly important component. We separate out because it doesn’t speak so much to the architecture. It’s more the trims and the pink color and all that stuff, which should be informed by users but it’s not as important as how to flow between the different rooms and how different components of things work together.

So one of the ways that we can get more insight from our users is by ideating, sketching, and prototyping. And so anybody that’s been in the design sprint with us will recognize this process of ideating, sketching, and prototyping. Observing our users and making sure that what we’re creating works for them. And then creating like validated design. This helps us a lot because not only are we building something better for our users but we’re de-risking the project. It’s very low risk to change structural elements at the beginning of a project when we’re in the prototyping phase. After we’ve developed and launched it, it’s very difficult to do that as you all know.

All these is informed by research. This image just gives an example of how robust research really can be and other many different things that it can inform. Some of you might have seen these things, but what I’m trying to do, the process that I’m going through right now as part of creating this book, is pulling all of the different artifacts that we create and templating them and make them more accessible to people. So this is an example of a user persona. This was the user journey map that we created a long time ago for our client Hello Divorce, which we just launched the product for. Again, we mapped out the entire process. For somebody who’s going through a divorce, what are the things that they going to need to experience?  Some task flows, sitemaps. And as you can see we go higher and higher in fidelity as we develop things. And this will eventually turn into wider frames and high fidelity mark ups that we’ve all seen contribute to the end result. This is a little bit of the look and feel stuff that we can do.

The second point is a road map that evolves with the product. Again, another quote to kick this off, “The measure of intelligence is the ability to change.” From Albert Einstein. This speaks to the flexibility. How important it is to stay flexible when working through a product. We’re going to get a lot of feedback from our users and we need to be able to adapt to that.

So the structure that Yeti has put in place to do that is what you’ve probably all seen as Applied Agile. So this component adds in the flexibility from a road mapping perspective to make great progress. So I’ll quickly go through this because you’ve all probably seen Applied Agile. But essentially, the beginning of Applied Agile is all about being able to create a road map quickly and work with our clients to prototype and build a roadmap for where we want to go. We rapid the prototype to try to get feedback from users quickly and early on. This is an example of a roadmap that we’ll build out. And then part of that flexibility is that we are on a weekly basis, as a product team, working on adjusting things and changing things in our sprints. And then really we’ll even be working with our clients on a lot is making sure that we’re adjusting our roadmaps on a more zoomed out level, and that’s what the vision alignment workshops are meant to do.

You are all very well aware of the sprint meeting agendas. The vision alignment is something that we are still working on because there’s – and I’ll explain this a little bit later – different levels of organizations and different times that we need to checking in on roadmaps and addressing things.

This was from a past iteration of this but it’s a cool quote nonetheless. “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” I think it’s a good quote about planning.  So transparent direct communication is the third pillar of what makes successful products. So a quote from Buddha, “To have much learning, to be skillful in handicraft, well-trained and discipline, and to be of good speech -- this is the greatest blessing.” So one of the things is like we can do the best work possible, but if we’re not communicating to our clients of what we’re doing and we aren’t able to relate that stuff, then we find ourselves in a lot of trouble. So how do we do that is like we run a really clean agile process. I’m not going to spend a lot of going through that because you’ve all seen this. You’ve all seen how we build user stories. How we communicate how long things are going to take by running points poker process. We use our user story lifecycle to go through each of these phases so that our clients know what the status is of everything that we’re doing.

This might be a bit new to people here but when we add, remove, and change tickets, that’s a major thing for our clients. We are changing the roadmap. And this goes into the flexibility as well but a small organization we’re just working with like a product manager who is the executive. And so we can manipulate the backlog very quickly and easily. When we get into medium and large organizations, we need to work with our product manager who then works with the product owner and executive on manipulating a roadmap that is a little bit more high level. And then as we’ve seen with our hospital and stuff like that, there is more tiers of it. We have a granular roadmap and a strategic roadmap and we need to be constantly bundling different things so that we can be communicating what we’re doing.

You all know how to manage a backlog. We manipulate tickets. We move them up and down. You are all very familiar with running a sprint.  We’ve started adding this [inaudible 0:19:55] America has been putting this together. But giving weekly health status reports to our clients on where we’re at in a project and what’s going on. So we’re tracking where we should be if everything goes well, what the current status of our projects are, how many points have been added. So these tools are going to be and currently are very helpful for us to be communicating the status and what’s going on with the projects.

Going back to this [inaudible 0:20:44] book. “This is the timeless way of building: learning the discipline -and shedding it. So what Christopher Alexander talks about in this book is that there is a process to build things. But again, we’re building technical structures. It’s still organic. Everything is based on organic people building organic things. So there isn’t a set way of doing it. There’s always going to be adjustments and always going to be changes in it. We need to try to stick to it as much as possible but understand that there’s going to be changes in that.

So I’ve addressed like three things that I think are super important for building successful products. One is a relentless focus on the user, ability to be flexible with a roadmap, and three, transparent direct communication. And so, you all have seen this but we have a Brand Promise at Yeti which is three-fold. A product designed for your users, on-time and accurate estimation, and transparent direct communication.  And so really our Brand Promise specifically addresses the things that need to happen for a project to go well. And so a product designed for users obviously we’re focusing on the users all the time. And the on-time and accurate estimation is that we are guaranteeing our clients the up-to-date information so that they can be flexible and they can make decisions within the roadmap. And then transparent and direct communication is obvious, we just have to be communicating all the time. So let’s start building. Yeah, thanks.

‍