Chicago Camps

Braden Kowitz (Video) — Prototypes, Process & Play 2015

Braden Kowitz, Design Partner at Google Ventures, presented at the 2015 Prototypes, Process & Play conference and shares his thoughts on how slowing down can actually help you move faster and how designers can shift how they work to play a stronger role in product development.

We hope you enjoy Braden’s presentation, “Design What Really Matters” and don’t forget to get your tickets for Prototypes, Process & Play on August 11th and 12th!

Braden Kowitz

Design Partner, Google Ventures

Braden Kowitz is a product designer, prototyper, and storyteller. He’s also a Design Partner at Google Ventures and founded the team’s Design Studio. He advises startups on UX Design and Product Development. Before joining Google Ventures, Braden led design for several Google Products, including Gmail, Google Buzz, Google Apps for Business, Google Spreadsheets, OpenSocial, and Google Trends.

Braden started his career building virtual reality simulators at the Beckman Institute, and interactive visualizations at Lucent Technologies. Braden studied Computer Science at the University of Illinois at Urbana-Champaign, and Human-Computer Interaction at Carnegie Mellon.

For more, keep up with Braden at or on Twitter as @kowitz.

Design What Really Matters

Designers love to delight customers with look and feel. But if a product doesn’t solve a real problem, customers won’t care how pretty it is. For design to be effective in a business, it needs to move beyond surface-level work and contribute to the very core of how products are developed.

This is a pragmatic talk about how designers can work differently to have a stronger role in product development. We’ll see how slowing down can help you move faster. We’ll look at ugly design that leads to great products. And we’ll learn how a careful design process can help companies take big leaps safely.

Presentation Transcript


Braden Kowitz:

Thank you for having me here today. I want to talk about doing design work that really matters in your organization, and some of the things that get in our way when we try to do that stuff. But to start, I want to embrace our negative side and talk about our chief complaints as designers. A complaint that I’ve heard forever. Can you think of what it is?


Make the logo bigger.

Braden Kowitz:

Partly. The big one I heard before is we don’t have a seat at the table. I think since the first table was invented we were complaining that we weren’t at it. But the good thing is this stuff is kind of changing. When I joined Google ten years ago it was a very engineering‑centered organization. I thought I had a seat at the table, but it was more like a bean bag in the hallway. That’s more of what it was. Google is now still a technical organization, but it’s a leader in design, as well. In my experience at Google Ventures, I’ve had the chance to talk to a lot of CEOs. When I first talked to people about designers, they used to say tell me about this design thing. Hmm. Now they’re like “I need to hire designers!” They need it right now. If you’re at a small company, you probably have a seat at the table. It’s very common to see a designer in teams of six or so. It’s impossible not to have a seat at the table with a team that small. But over time they tend to lose it. I find that interesting. I want to find out how we can stay involved in a core part of a company. If you don’t work at a startup, I think it’s still true. Design is so hot right now. People are looking to design in business schools. It’s hard to find a business school that isn’t teaching design thinking. They want us to solve big business problems and we have to step up and actually do it now, which is great.

I want to talk about how we do that. Particularly in this product development cycle, how design fits in it. You have to be living under a rock not to know the whole launch early, launch often, iterative launch. But to bring everybody up to speed. You have an idea how to make your product better, you launch, and then you look at the metrics. Who here has done this or heard of this before? Great. Pretty much everyone!

So where does design fit on this cycle? We usually at the beginning of an organization design fits somewhere here. And it tends to be visual design work. So engineers build it and they go to the designers and say can you please make it look a little bit better? Do we like working here? No! We want to get involved before they start building it. When the organizations let us do that, we can start doing more interaction design. We’ve got visual design and interaction design. Often we think of products in these layers. Interaction design, how it works. But then there’s this deeper thing. The what it is. What do we call that kind of design? Just shout it out if you know it.

Conceptual? Product. Product is what I’ve been hearing a lot. Now some people use the word “product design.” Yeah, high five.


Everyone who gets the right answer gets a high five today. Go to your neighbor and high five it. If you’re a designer and working on a product and doing product design, we should have a debate over this over beers later, but for this talk I’m keeping it at a very narrow definition. I think you’re a product designer if you’re figuring out what the product is. How you’re delivering value to customers, and how you’re capturing some of that value to make your businesses sustainable. That’s the product design I’m thinking about. If you go back to this diagram, where do you put product design on that? We’ve got visual design and further up earlier in the process. How do we go earlier in this process? Where does product design fit? Actually, I don’t think it fits on this diagram at all. I think product design fits something fundamentally broken. If you have a good idea, you build it, you launch it, the metrics are all up onto the right. You call your friends and say I’m crushing it. And then they make fun of you because you said I’m crushing it.” [Laughter] And it works, but not all of our ideas are good. I have a lot of bad ideas, and when I have them, I don’t know they’re bad.

So what happens when you run this process with ideas that they’re a bad but you don’t know it. You waste time building it, you launch it to customers, you look at the metrics and it’s flat. You know it’s not working, but you don’t know why it’s not working. The worst part is once you launch something to customers, it’s pretty hard to take it back. You start out with a nice, simple product and you put in features and some of them work and some of them don’t. You’re not sure witch, and some of it’s not. But you’re not sure which.

Who has attempted to remove a feature from a product that you worked on. Attempted it. Keep your hands up. Of those who attempted, who succeeded in removing? Half the hands went down. Of those who succeeded who did not get hate mail from customers? One person is very good at change management. Excellent. It’s hard to take stuff out of your products. That means we need a way to evaluate our ideas before we launch them. That is what product design does.

It’s a quicker way to build and evaluate ideas without ratcheting them into our products. Prototyping, which designers are great at, and user testing. This is what I want to talk about today. This type of product design. A lot of designers that I talk to and work with, they want to do product design, but they often find it hard to actually get it done in their organization. There is stuff and barriers that gets in the way. This talk is five lessons that I’ve learned from the startup perspective, but I hope also apply other places. Five lessons to do product design in your organization. Does that make sense?

Our first lesson begins in London. The first day off the plane I had a meeting with a entrepreneur and we had some tea and I said tell me what you need from design. I’m here to tell. He said I wish my product could look better. I had to restrain myself from flipping over the table and not say design could do so much more! I sipped some tea. What keeps you up at night? He began to tell me about expanding to new markets. And how his products were so simple at the beginning, which customers loved, but as they’re adding more features it gets complicated. So we were able to have a good discussion about how design can start to address some of his big fears about his company.

So instead of fighting him, I tried to find where his energy was and what he was interested in and work with it. That’s a big lesson. If you join a startup, they’re freaking out and then you join and they’ll be calm and nice to you. And eventually they’ll have an idea that you hate.


You’re going to have to deal with it. You’re going to have to decide how it’s going to work. Typically we tend to tell them all the reasons why their idea is stupid, but that does not work with founders. Because founders are really good at ignoring all the people who tell them that their idea isn’t going to work. It’s why they’ve gotten to where they are today. It’s what made them founders. God bless them for that ability and that courage. But now you’ve got to work with them and that’s challenging.

I’ve been reading about Aikido, which is this martial art. The CEO is trying to suggest features to you by grabbing your wrist. Can you make it pop? Can you make the logo bigger?


Now I’m not saying you should flip your boss on the mat unless he has a really bad idea. But what I do think you need to do is figure out where their energy is redirect it. Don’t attempt to fight. This is the big thing that we’ve learned when we talk to CEOs. They’ll come in with an idea, and it may sound crazy to us at first. But I start with a place of being humble because I’ve seen so many ideas that I thought were great fail, and I saw so many that were dumb succeed. Start with that humility. Help them prototype it and help them test it. If you have a little bit of time, you can also squeeze in some of your ideas, as well. So what we typically do is we run away and do a bunch of research and we come back and say we have the research and your idea is bad. That doesn’t work. This is why researchers get so frustrated. That an interesting idea, I’ve got some too. And then you’re both facing the same direction, you’re working together and it’s much easier for people to see when their ideas are working or not working. Redirect your energy.

My second lesson is about robots. Specifically this robot, which is made by a company called Savio. It delivers things to your hotel room. I forgot my toothbrush, and instead of a person bringing it up to you, this robot will bring it up to your room, which is cool. Our design team fell in love with this robot. [Laughter] Who doesn’t love robots, that’s why we took the job. There was lots of stuff that we could do. We started by mapping it out the whole experience of it. We did it on a white board. But someone will call the front desk and say I forgot my toothbrush. The front desk would put the item in the robot, and then go to the elevator, which is awkward for humans, let alone humans and robots, and then ultimately go to your door.

We can’t do this all in a week. Where should we start? We started with the most risky part. The delivery in the hotel room. If people didn’t enjoy that experience at the door, it wasn’t going to work.

One of the idea was to give the robot a bit of personality. This is a post‑it in note from the design project. Anthropomorphic ideas and make it beep. People have very high expectations of robots from cinema.


R2‑D2 can understand what you say, but the Savio robot doesn’t have a microphone. We didn’t want to set expectations too high and then let people down. That was the risk. It was great that we could build personality and delight with customers, but we didn’t want to screw it up. We decided to take a little loop around that cycle and do product design. This robot had a little section on the front where you could put a tablet. We had a spare iPad around. We designed a little interfacing keynote. In just a day. It was a very simple thing. All of the software wasn’t working, so we had to drive the robot with a play station controller. We found a hotel that was amenable. And we scheduled five regular business travelers to come in and pretend they forgot their a toothbrush and call down. But before we did that we hid cameras all around the room, which I think lost our security deposit. And then we watched. They said a hotel is going to bring it up. And they hung up the phone. What’s happening? The experience was great the first time and a second, third, and fourth, and fifth time. We had a lot of confidence after that day that it was going to work. The robot was a huge succeed. It got covered in the New York Times. People loved it. In fact people loved it so much that they started sending in videos of their experience with the robot to Savio.


Okay, someone is at the door! I have a visitor. Let’s see who it is. Oh, hello!

Braden Kowitz:

See the eyes blinking?

Oh, you have a delivery for me? Oh, my! Thank you so much. You did a great job! Look at your little bow tie. Thanks buddy! Buh‑bye.

Braden Kowitz:

She gave it five stars, but she didn’t hit the button. There’s still so much that they could do. It was a super fun project. But the thing that strikes me the most about that team is that everyone on that team had a super power. They were good at something. But most of them were not doing their super power during this time. The CEO is great at fund raising, but he was watching customers studies. The engineer who is good at code was driving it around with a Playstation controller. Everyone was not doing their super power, which is super weird. The reason they didn’t end up doing their super power was because we were focusing on the riskiest thing. When I start a project, I’m usually drawn to the things I’m good at. If I’m a good visual designer, I want to be doing good visual design. If I’m a good interaction designer, I want to start there because I know I can hit it out of the park. If I can hit it out of the park, it’s a risky thing. I have high confidence that I can do it, but it’s not where I start.

This whole lesson is about doing the risky stuff first which will push you out of your comfort zone. If you do the risky stuff first, that’s how you end up doing product design.

The next lesson is short and magical.

When I talk to founders about the types of designers they want to hire and what skills they need they run down the list. Interaction design, visual design, write a brand for us, front‑end code, hire and grow a team, be a great manager. Whew, that’s a lot of stuff. And we in the design world have a word for the mythical creature that does all this stuff. Shout it out.



Braden Kowitz:

Unicorns. A lot of unicorns get hired into startups. Even if you’re not really a unicorn, it can feel good to have the opportunity to do all these different roles in your company. But you realize there’s not enough hours in the day to do all of these things. You can’t be growing a team if you’re talking to customers and talking to customers if you’re designing a brand. There’s only so many hours in a day. Very quickly the organization will grow around you and it will be harder and harder to get stuff done. You get spread thinner and thinner in your organization. This is the death spiral for design in a lot of organizations. You get spread so thin you’re not doing good work anymore. Then when new people come into the organization and they experience design for the first time, that design, they don’t do great work. Or they’re just doing that visual layer on top of design. So how do we avoid this? It’s really hard.

I think it’s about creating boundaries about what you’re willing to do and what you’re not willing to do and being very clear about those boundaries. Two tips for this. One is to say no to projects. Get comfortable saying no. This is hard because we want to please and we want to get a lot of stuff done. Typically if you work in agency worlds, you say yes to everyone. But then you’ll get spread too thin.

The best way I have found to do this is go sit down with your founder or boss and list all the projects you’re working on. If there’s one thing I can get done this week that would make a big difference to your company, what is it on this list? Then take that list over to your desk. When someone asks you to do something, what is your project in these priorities? Very quickly people will say designing that water bottle. That’s low on the priority list. We can put that at the bottom. If they don’t, the water bottle is most important, you have to design it now, then you can say go talk to the CEO. They made this list with me. But you can’t be the one saying no, you can’t have design on that project. Because they’ll figure out how to do it, or they won’t like you for saying no all the time. So instead you have to say no, but we can also figure out another way to get it done. Just give people a menu of options of how to do design. I can do design, but I’m busy. So let’s run down the other list. We can hire a freelancer, grow this team, or choose not to have design on the project.

Make that an obvious choice for people. When design is on the project and when it’s not on the project will make it clear for them the value of design. Create those boundaries.

Lesson four is coffee. Which is great because I had several cups of coffee this morning, if you couldn’t tell. I got to work with this team called Blue Bottle Coffee. They have cafes in a lot of places. They make fantastic coffee. They were selling their coffee online and they wanted to get better at merchandising that coffee. When you’re browsing online and trying to figure out which coffee roast to buy, you have to make this decision. They organize it by region. As we started talking to their customers, we found out when you’re in a coffee shop and you’re talking to your hipster barista and you say I want a cup of coffee and he says Ethiopian or Guatemalan? In their brains they’re like “what?” Who here knows the difference between the two? I didn’t know either. We started with a question that they absolutely knew the answer to. How do you make your coffee at home?

We could select some coffees that were better for that brew method and then we used flavor combination to describe what they might like and give them confidence in the coffee that they chose.

The lesson here is to talk to your customers. Actually, that’s not the lesson. People rarely do it. It’s very rare that I go into a startup and see that they’re actually running user research on a regular basis. What’s with that? Why do we think it’s a good idea but rarely run it in our organizations. Designers are at fault more than anyone else on this. We love making beautiful things, we totally do. I will sit there and polish a beautiful idea to this point where I’m not willing to hear feedback. Maybe it’s too late for feedback because I made it so precious and good.

If I can build prototypes like that, those are gorgeous. But the reality is you don’t need to do all that work in order to get a concept to a phase where you can test it and learn from customers. And the only way I found to get designers, myself totally included, get us to stop polishing and start getting data from customers is to set hard deadlines. So the trick that we use in our team is when we start a design project, we’ll in on Monday and have five day to work on it. On Monday, we’ll plan user research and have customers coming in on Friday before we design anything. It’s terrifying, but it also keeps us at the right level of fidelity to test their ideas. Make sure we don’t build a tower on a bad foundation because that data is going to come in and knock down our tower if our foundation is bad. This is what Blue Bottle launched. But this is what we tested and I’m embarrassed to show this. It’s not a good design. We did it on keynote. Copy, copy, copy. It’s very, very basic. But it’s enough to teach us that the concept worked and we would have confidence to go and do that broader cycle.

So set these dead lines for learning. Don’t over-polish your ideas. Okay. Last topic.

One near and dear to our heart, which is craft and quality. And we talked about how sometimes you have to have that quality low. But in the end we want very high quality in our products. We want them to be delightful and amazing. But if we’re honest about it, we’re not always great at delivering quality. For visual design, if we say we’re going to make something beautiful, we can usually deliver. And with interaction design, if we want to make something usable, we can do enough user studies and be confident.

But for product design and management, we’re often wrong. Even founders are wrong. You say people will love it and they don’t like it so much. People will use this feature and you end up building it and maybe only a percentage or two of your users end up using it. I think it’s important for us to realize that we’re not always great at this stuff and think about how we can get better.

So I want to look around at other issues that have sort of crisis of quality and what they did about it. We don’t have to look so far because engineering in the ’80s had a crisis of quality. Besides the blue screen of death, there were all these promises that engineers made about their ability to deliver software. It was often late and scoped down and it was buggy. When they were building software, I assumed it looked something like this, they had one team that was focused on quality and speed and writing the code and they had a separate team that was focused on quality and writing the tests. Some people said we’ll give you bonuses when you get this thing out on time. And other people said we’ll give you bonus ifs there are no bugs. How do you think these teams worked together? Not so good. It was very difficult to work in this environment. But more importantly, they never got quality software out of this environment.

They realized after a while that they couldn’t put the quality team in the corner and say it’s your job to make sure we have quality software. If you look at what engineers do today, they’ll write code and they’ll take a step and write test for that code and go back to the code. That is radical. That change in what they consider their job function to also include quality is a radical change that happened and it gave us quality software. So let’s think about what startups are like today. It’s kind of the same. We’ve got our engineering team that’s writing code and we care about a different kind of quality. Product quality. We don’t really get along with engineers that well sometimes. And the reality is we often don’t have great quality products because of it. Quality isn’t something that you can push off to the side.

Quality is something that has to be everyone’s job. And I take this to be design has to be something that is everyone’s job. I take this in two ways. One at the cultural level in an organization that design isn’t just something that can happen in the design team. Everyone needs to be doing design activities. Doesn’t mean that an engineer needs to open Photoshop, but it may mean that they need to do user studies.

There are things like unit tests that they didn’t do before that they might have to that everyone in the organization will have to do to be part of that process of design. Also, I think it’s a personal reminder to ourselves. Because as designers, we love saying like oh I got it and run away and make a very beautiful presentation and bring it back. I’m a genius! Check out this great design. But that doesn’t do anything to bring other people along on the design journey and help them understand it. So, make design everyone’s job.

Those are the big five lessons I’ve learned about how to make product design work in the organization. First don’t fight with people. Figure out where their energy is and take it with you. Second, do the risky thing first instead of the thing that you know you can do really well. It often pushes you out of your comfort zone, but helps you do the early stage of design and prototype that you need to do. Make room for the work. Create these boundaries so you can do good work and you don’t get spread too thin. Instead of thinking about talking to customers one day, create these strict deadlines, and make it something that you can bring everyone in the journey around. That’s why I love product design. Every time we make a product a little bit more delightful and a little bit more fun, we’re making the world a more humane place. What’s better than that? Thank you.


We actually have a good amount of time for questions. I’m happy to talk about this stuff. But I also work with a lot of startups and talk about things about design teams and hiring. Any question is fair game. Yeah?


So I found recently that there’s a perception of design from both management types and designers themselves that design is exclusively an additive process. So when the manager and CEO comes and says let’s build more stuff on top of stuff. Whether or not you’ve tested it and shipped it. It means add more crap to this. Can you explain a way around that or a way of having that conversation with fellow designers to get past that additive sort of tunnel vision where sometimes design is reducing complexity, removing features, simplifying the process. Sometimes starting over and just creating one really strong nugget of the product. I think, I guess our team has been tracking that cycle. Where it’s just like make more stuff. That’s what design is. And I don’t think that’s the conversation we need to be having.

Braden Kowitz:

Absolutely. This often happens in engineering. It could you please out of engineering, because their job is to build what is asked of them as fast and reliably as possible. They gauge how successful they are at that because of how fast they built that stuff. When that sense grow to the larger organization, it gets to this launch, launch, launch lots and lots of features. But the thing to keep in mind is the features don’t do any good unless they’re working. What I try to do in those discussions is to say how we’re measuring the things to see whether they’re working. That’s before we launch and really after we launch. I talk to companies that launch features and they actually don’t even know if they’re working very well after they put them out. So there’s two ways to do that. One is with quantitative metrics. The behavioral data of how people are actually using your product. But if you can get people watching those user studies on a regular basis, it sort of tempers all of that other stuff. As your product grows, you’ll get feedback from people about features that they want. If you’re not careful, you’ll listen to that feedback and build it. And building it may make the product more complicated for the 99% of other users who like the product the way it is. If all you’re hearing about is that it’s broken, then you’re tempering. You need to compare it with qualitative data and that allows people to balance it. Yeah?

[Speaking off mic]


How do you approach coworkers who tend to see design as the final step before launch? For the company I work in, it’s I.T. will work up a product and then they’ll just call up the design team. Yeah we’re launching this in a couple of days. Could you throw a coat of paint on it before it goes out. You look at it and you’re like it’s not just ugly on the service. It’s the ugly that lies beneath. Why didn’t you call us six months ago and we could have walked with you in this process. But how do you approach them when it’s already too late this time. But to try to train them to see you in a different way?

Braden Kowitz:

First I try not to scold people about that kind of thing. I try to help as best we can.


We just talk behind their backs.


Braden Kowitz:

That always works. I try to help them with whatever project that is and usually try to save some time and go and find the projects that are happening earlier, which takes a lot of work. It takes a lot of relationship building to get people to trust you, which is why you end up doing that late work to begin with. But it also takes a little bit of room to have the time to find those earlier projects. That’s where it comes into having a staff and bandwidth that is big enough so you can handle those late things or you need the ability to say no to some of those late projects so you can find the stuff earlier on. If you’re swamped by doing all the visual stuff, you’ll never get to interaction. And the same there getting to product.


Thank you.

Braden Kowitz:

Uh‑huh. Maybe right here since the mic is there.


Hi. How do you see product designers working with product management? How are those responsibilities divided?

Braden Kowitz:

You know they’re blending together a lot lately. The product management and design. I tend to think of it on a more granular level. Even within design, two people will say they’re great designers, and other people are great copyrighters and interaction designers. These higher level titles don’t mean a lot to me. What means a lot is the granular skills that are underneath them. When I talk about organizations, we talk about which of those granular skills do you have. Product management. Communication within the team. Those types of things that could make you a good project manager. And the design process, which is where design is also coming in.

We’ve been in companies that say why do we need designers? We’ve got product managers. And we’ve been in companies that are the reverse. Why do we need designers, we’ve got product managers. There’s just so much overlap in those terms right now.


A question. In risk phase you identified, that seems like the closest to product market fit or product fit. What do you think of the allocation of art versus science at that phase. You’re interested in all of these areas of the design process. And that seems like a critical stage to see if the product is going to work in the marketplace. At some point do you think it’s 50/50 science and art. We can use science in our user studies to talk to customers and find out if they like it. But it’s an imperfect science because people tell you one thing and it doesn’t mean that the product is going to be successful. Is it part of it art where directionally this looks good and we think it makes sense. How do you manage that process in working with other stakeholders?

Braden Kowitz:

First of all, the whole art and science thing, I think of design much more closely to engineering actually. So there’s like art and science on one side and design and engineering on the other. Because design and engineering are often trying to get something done and complete a goal.

Art and science are trying to find some truth and make people understand things. Very different goals. I think part of your question is when do you just go with your gut? You’ve got all this data available. I like to just call out the things that we don’t know in meetings. In some cases, we just talk about them as risks, and in some cases we just try to imagine a world in the future where everything exploded and list all the things that went wrong and then go back and figure out well those are unknowns. Some of those unknowns you can deal with, with data. Either hey we’re going to prototype this and show this to customers and do a percent experiment. There’s lots of ways you can do it. If you’re trying to figure out if our logo should be orange of blue, really hard thing to do with data. In those cases you need to say we don’t have enough of that type of data. The data that we’re going to have to live with are the instincts on our team. If you can call out that sort of meta about how you’re making the decision, it gets a lot easier for the rest of the team to trust the designer to make those types of calls or the CEO to make those types of calls or the customer support. They have the best instincts available and that’s all the data you’ve got.



So with working as many startups that you have in a five‑week cycle, have you found a quality method for getting good users for the user research on that Friday? And if so, can you share that?

Braden Kowitz:

Yeah, absolutely. I’ve talked to a lot to teams and they go out and talk to customers and they feel a little bit more scattered at the end of thing. I asked them what they did. I found some random people and asked them some questions and I kind of remember it. That’s why you feel so scattered. It’s about finding patterns. That means you have to have some kind of synthesis process. And in the actual interview you need to have an interview guide that makes you kind of ask very similar questions to the same sets of people. In the beginning you need very targeted customers that you believe would like the particular concept. How do you find those people? Actually we’ve had a lot of luck with Craigslist, which sounds kind of crazy, but there are lots of people on Craigslist, and all you need is a filter to get down to the people that we care about. We post something on Craigslist. Come in and use a product for $100 an hour, and fill out this form and we’ll select it.

When we were trying to find users for Gmail, we wouldn’t ask hey do you use Gmail? For $100 bucks I do, sure. Instead we make a list and we make some up. If they check all the boxes, then this person isn’t the person we want to talk to. You take that giant population of people on Craigslist down to a narrow population of people that you’re looking to recruit. That’s one way. Oftentimes you’ll find people who are harder to recruit. They don’t respond to incentives because they aren’t in communities like that. We’ve worked with colleges for example, and in those cases you need to go another route. In that case we went through their hospital organization that cared about this project being successful.

There are a bunch of organizations on how to recruit people at our library up there. Yeah? Right over here.


Hi Braden, how you doing? When you go into a company, what’s the strongest predictor that you’ve found of that company’s likely success with design?

Braden Kowitz:

You know, when we choose products, I used to ask all these questions to figure it out. Is this project going to be worthwhile? Do you have a front‑end engineer? Because if you don’t, this isn’t going to go well for any of us. Questions about how to make decisions. None of them seemed to correlate with being a good team to work with. They were random. Some were good, some were bad. Lately the thing that we’ve found that correlates the best is previous behavior. The past is a prologue. I do this interface on the board, this mobile app that they were asking about. You can build it this way. They went away and a month later they were like “We built it! Check it out. It’s in the app store!” I want to work with you more. That’s amazing. Those teams I like working with better.

What we’ll do now is we talk to customers ask when we have better and better experience, we’ll invest more time. I’ve seen people do the same thing. Don’t commit up front. Go down the road a little bit and see how it’s going. Also for hiring. The past is prologue. Yeah? Right here in the middle.

I promised him a second question.


So one of the other questioners mentioned that he got the, the engineers came like way too late for design. And this was just a recent event. I had that experience 20 years ago. So this is historically speaking ever prevalent. So the big question is how do we enculturate this into something bigger than just the people in this room. We all agree and we all know. But regardless of whether you’ve been in this industry 20 or 30 years or if you just graduated from college, how do we spread this word around a bit more and get companies to embrace it more? Instead of having the same CEOs who have the same patterns and do the same thing and ignore design and in fact ignore engineering and design collaboration?

Braden Kowitz:

Great question. I’ll start from our challenge. We’re trying to help them all. It’s to the point we can’t just do design work to help those companies. What makes an impact is if they change. If they think about design in a different way after we work with them. Organizational change, the type that you’re talking about, is extremely hard to do. It’s hashed to get me to change habits. Imagine hundreds of people and trying to get them to change habits. Very, very hard. The thing that we found works the best is doing projects with them to show them the design process in a short amount of time. We bring a bunch of people in the room and show them the whole design process scaled down to work within a week. It gets lots of people involved and they start to understand why you need to do user research and early concepting. I would start there because it is the thing that has worked for us the best. But honestly, like organizational change is hard. And if your current organization doesn’t get it, it may be time to grab that lever and either go to some place that does get it, or start your own company that gets it. Don’t beat your head against the wall forever.

Okay, maybe one more question if anyone has one. And then we’ll go to break. Right there in the blue shirt.


I was going to send them to break. But thanks! [Laughing] No, sorry. We’ll take the question. I’ve been overridden by Braden. It will happen again.

I’ve heard two philosophies with working with customers. The customer doesn’t know what they want. And then there’s the other kind that will take every bit and put that in their product. What is your advice I guess for navigating you’ve got a feeling, I think this will be an awesome feature. But then the actual needs of the customer. And plan that to select what you’re working on.

Braden Kowitz:

Yeah I divide it into two camps. It’s certainly that the customer is not going to tell you how to build their products. They’re not product designers, they’re not founders. They don’t have enough context to actually do all that stuff. But they can absolutely tell you what they need and what’s good for them. And it’s your job to talk to enough customers so that you can see patterns in that and to understand the needs of the company. The customer needs and the company needs so you can build a sustainable business together. Yeah. I don’t know. That quote from Ford where he said if I ask people what they want, they would say it faster for us. First of all, he never said that. Second of all, a faster horse is a good idea if what you end up building is a car. The customer told you what they needed. It was your job to design the product.

Thank you very much.


Chicago Sponsors Camps

  • Rosenfeld Media
  • Simplecast
  • Lead Honestly
  • Columbia College Chciago

Code of Conduct

All attendees, speakers, sponsors and volunteers at our conference are required to agree with the following code of conduct. Organizers will enforce this code throughout the event. We are expecting cooperation from all participants to help ensuring a safe environment for everybody.

The Short Version
Full Version

Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion (or lack thereof), or technology choices. We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, parties, Twitter and other online media. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organizers.