Video: The future of design with Jeff Veen

Design is in the midst of continual change, so it’s increasingly rare to hear from those who have gone the distance in digital design.

We were lucky to have Jeff Veen in the office recently, whose career has spanned everything related to design – from redesigning Google Analytics to VP of Design at Adobe. He’s also inspired a whole generation of UX professionals as co-founder of Adaptive Path. Rarely does a usability workshop go by that doesn’t include a concept popularized by Adaptive Path.

Jeff sat down with Paul, our VP of Product, for a conversation about the current and future state of design, hosted by Emmet, our Director of Product Design. The conversation ranged from their experiences of working at Google, to the pendulum of moving from large organisations to small startups. They also looked towards the next generation of successful designers – those who are able to move beyond the level of the interface.

For the readers amongst you, a transcript of their discussion follows the video.

Emmet Connolly: Jeff Veen is a design partner at True Ventures, a venture capital firm in Silicon Valley. He is also an adviser for about.me, Medium, and WordPress. Jeff has an illustrious past that I will try to summarize very quickly. Jeff was the co-founder and CEO of Typekit, who were then acquired by Adobe. At Adobe, Jeff was VP of Product. Before that, Jeff was a founding partner at Adaptive Path, influential UX consultancy firm. Adaptive Path developed an app called Measure Map which was acquired by Google and became Google Analytics. Jeff also worked extensively on redesigning Google Analytics while there. Before that, Jeff was a founding member of the Wired Magazine web team. I could keep going back back further.

Also joining us is Paul Adams. Paul is the VP of Product here at Intercom, running the PM design and research team. All of our product development is done here in Dublin so Paul oversees that. Before that Paul was the Global Head of Brand Design at Facebook. Before that he worked at Google as a UX researcher. Paul worked on a wide range of Google products, instigating the Circles concept in Google+. Paul is also the author of the book Grouped, on how our lives on the web are influenced by social sciences. Even before that, Paul was a design engineer at Dyson.

With all of our impostor syndrome firmly established for everybody else in the room, I think we can delve deep into asking some questions.

A designer in a VC firm

Emmet: Jeff, maybe I will start with you. Your current gig is working with a VC firm. I’d love to know a little bit about what that work actually involves. I’ve heard of quite a few designers moving into this world. John Maeda is working with a VC firm now, I know Google Ventures also have a quite large design involvement in what they are doing. What’s going on there, is that a trend, and what’s the actual role?

Jeff Veen: Yeah, I think so. We were talking about this yesterday at the Web Summit. I started it off with a bunch of statistics that there have been over 50 companies in the last five years that have been acquired by tech companies, and that had a designer as a co-founder. I think that’s more interesting than on the VC side. On the VC side it is interesting too. There are 7 of us in the San Francisco and Bay Area as partners at VC firms that are designers by trade. I think this is an interesting trend for the importance of design and the way we think about where we are putting capital, and where our values lie as an industry. I think that’s very interesting.

From a personal perspective, I think it is super weird to have this job. I had no expectation, whatsoever, that if you asked my what I did for a living I would say, “I’m in finance.” I never would have imagined it.

The job is great. I don’t think I would have chosen VC. I chose to work at True Ventures for the people there and the work they do, as opposed to what the VC world is like. True was the lead investor in Typekit, that’s how I got to know them. I got to know them really well. It turns out that the capital part of it, the money part of it is entirely secondary to what they are trying to achieve. It’s kind of the means to an end. What they are really trying to do is to support a new kind of entrepreneur in the world, and to make products that have a significant impact on the world. They do that in a really community-centered way. Two weeks ago, we did our annual founders camp which brings all of the founders of all of the companies together. We all get into a hotel and all the founders lead sessions and it’s just this great community building thing. That’s what I love about it.

My job is half on the investing side, and the other half is on the platforms, the portfolio. It’s very similar to the work that I did when I was at Adaptive Path, with the exception that we choose the clients instead of the clients hiring us. It is mentoring of the founders, helping them through these growth stages that they go through. I can’t tell you how many of our companies are hitting 50-60 people now, have gone through 2 or 3 rounds of funding, and they are coming to me and they are saying, “I think someone should run design and product now. How do we structure this?”. It’s organizational change. I find it tremendously fun and rewarding.

Paul Adams: Why did you not start your own company? What’s the difference?

Jeff: That’s not off the table. We will see.

Paul: All these people are trying to hire you as there head of design, right?

Jeff: The problem is I’m not very good at having a job. That’s the underlying principle with all the things I have done in my career. It’s more about a short attention span and being a terrible employee than anything else. The other thing I really like about True is how flexible and fluid everybody’s careers are. Three of the partners have also run companies and two of them are right now. There is still an opportunity to go out and build things because that is ultimately what I love too.

Do designers make good founders?

Emmet: There is a whole load of things there that you described that are possibly also trends. You talked about design founders but you also talked about people coming to you and saying how do I install a design function in my team. Paul, I would be interested to hear your thoughts in this as well because I think you have gone through somewhat similar experience.

For people that don’t know, two of the co-founders in Intercom were designers. Paul, you’ve grown a product team from a very small number to an increasingly and rapidly growing number. Are there common stages that teams tend to go through? How do you grow a design function or a product team?

Paul: It’s pretty fascinating. We’ve got such a different perspective. My perspective is a single company in deep; Jeff, your perspective is a lot of companies in, not as deep. I’ve had multiple existential crisis’s over the last few years. When I joined Intercom, to get some sense of scale, I was the 14th person to join; that was just over two years ago.

There was no design team, no designers. There were no PMs, that function didn’t even exist. Eoghan and Des, two of the co-founders, actually did those jobs and did them very well. Both Eoghan and Des are phenomenally good designers and good product thinkers.

There is a whole different bunch of phases. One phase was Eoghan and Des trusting me that I wasn’t going to wreck it. There was a phase where we grew even more, and we started hiring designers and hiring PMs, where I had to learn the other people we hired weren’t going to wreck it. This was, in a sense, a terrible affliction. It’s micromanagement at times. It’s anxiety inducing. I think the reason is that the stakes are high. We are growing so fast, we have so much potential, and getting it wrong is hard.

From my experiences, when I was at Facebook or Google, the stakes are not as high. Complete projects that cost hundreds of millions of dollars can fail and it is inconsequential to the business. That wouldn’t be true here. It’s been hard. It’s the only way that we are going to figure this out, understanding how to share context and history of where the company comes from and where it is going.

Eoghan, our CEO co-founder, very much a designer, is in San Francisco. So so we have to translate his, Des, and Ciaran and David, the four co-founders, original vision into literally the tiniest decisions that get made here everyday.

Jeff: That maps with a lot of the companies I have been working with lately. In that they are, if not co-founded by a designer or designers, typically very focused on product. Even more so than in the past when product didn’t seem nearly as a crucial competency as it does today. Some of the things you are talking about are what these founders are going through. At some point the company gets to the size where their job becomes working on the company and not working on the product anymore. Where all of a sudden I have to work on growing the company, not on perfecting the product. They bring in somebody like you and then it’s this big trust thing that has to happen. You have to let go of the one things you love so much.”

I had advice from my lead investor very early on, who said, “Do you know the first five people you are going to hire for your company?”. I said I did but then he asked did I know what order they would be hired. I didn’t.

He told me to hire the people for the things you hate the most, and hire them first. At some point, you get to the point where the thing that’s left is the thing I love, which is making the product and having the team around me and spending my afternoon at the whiteboard. And then I have to let that go.

It’s made me think a lot about what design leadership looks like now for smaller and growing companies. Who are these people, like you, that we find to join a 30-40 person company, to lead design. I think it is the ambition of a lot of designers to find that role because a lot of them have a background very similar to yours; working on a smaller team in a bigger company, 5-10 years of management experience, have been involved in recruiting at the big company and things like that.

Designers who know how to ship

Jeff: What I always look for from a skills perspective are designers that know how to ship. There’s a lot of designers that are very good at making portfolios and very good at making mock ups, but being involved from the initial concept all the way until the 4th or 5th or 6th iteration of the live product is a very different set of skills. Not a set of skills that are ever taught in design education. You have to learn that on the job. It’s being in charge of both the quality of the product but also the momentum of the product.

Paul: Same. I actually used to say this at Google and I think I used to annoy a lot of people. When I worked in the research team, I used to say to people that all the research studies people were doing, usability testing, formative research, contextual inquiry, all that mattered was what shipped. Or sometimes what did not ship as a result.; sometimes that was the better outcome.

A lot of people struggle with this idea. The same is true here that; I judge our team, our product team, PMs, designers, researchers on what we ship. That’s all that matters. As I said earlier, the stakes are higher in a startup than in an established company but I think the same principles should apply.

Jeff: There’s a balance. The stakes are higher in a small company because you have so much influence. But at the same time, I have found it has been so much easier to ship at a smaller company than at a bigger company. There’s so many more people that care about what you are doing at the bigger company. I found this when I was at Adobe where it was intoxicating to ship something that ten million people would see.

But at the same time, so many people wanted to have a look at what we were doing. We did legal reviews, and marketing reviews, and then PR, and then all of this stuff, boards of advisors. All of these things that led to this glacial pace of getting stuff out. This was the Adobe that we changed to – instead of shipping every 2 years, we were shipping once a month. Still, that process was so much heavier and so I think there is some balance between the two. You can have a small amount of influence through a tremendous amount of people at a slow pace. Or a much smaller audience but way more impact and much faster pace.

Maintaining pace at a growing company

Emmet: I’ve wondered about this a lot. Is it a immutable law of the universe that once you get big, inertia starts to set in or that slowness starts to set in? Is that something that you think about with the companies that you deal with as they scale? How can a company avoid that as it scales?

Jeff: I don’t know, to be perfectly honest. I don’t think anything is immutable. I think there is really interesting stuff happening at what Zappos is going through right now – trying to implement holocracy to get around this problem.

When you are a small start up you can do anything. You don’t have to worry too much because nobody is really going to come after you. If you are Adobe, or Facebook, or Google and you do something, of course you have to do an analysis of the IP you are developing to make sure there is no patents because somebody will absolutely sue you for that. Those kind of things by definition slows things down.

Paul: It’s just a fascinating question for me. Emmet and I talk about this a lot. As we’ve grown, I think that we are getting slower. At least, if you take the output versus the number of people we have. Besides the legal part of it, because that’s a whole other thing, in terms of product engineering and design, is your experience that it needs to be slower, necessarily?

Jeff: It doesn’t need to be. That was one of the huge changes that we made at Adobe, which was coming in with a much more agile process. The company was going through a huge shift in its business model, like you probably all, whether you like or not, Adobe customers. There was the creative suite and the creative suite came out every two years and Adobe had no connection with its customers. They literally put the software in a box and sent it to people, other people who sold it to customers. This shift to, “We are going to ship all the time and we are essentially going to be continuously shipping,” … They ship Photoshop four or five times a year now which is remarkable considering the breadth and complexity of that product. Remind me what your question was.

Paul: Does it necessarily have to be slower?

Jeff: I think you can fix a lot of things in a company all the time. I think it is a continuous reinvention process. The step functions of going from 10 people to 20 is huge.When yo don’t fit around the same table anymore. I remember that stage. Twenty to fifty and then fifty to one hundred, those things, you have to put infrastructure in place that change up how things work. I’m on a Slack team right now with 300 people in it and Slack doesn’t work at that scale. You have to cut it down.

Paul: We use Slack too. We are at 170 or so in the company and it works well. You’ve hit breaking point?

Jeff: Yeah. The same way you would with 300 people all emailing everybody everyday. Do I sit in Slack now for a living? Is that my job to just go through all of this? At some point you have to put some structure on top of it. Now they have roles and departments and stuff which I think is a great addition. That’s the kind of stuff that has to happen as you get bigger.

Paul: That makes sense

The changing role of design

Emmet: One of the things that I am sensing in what you are saying is that there is almost a changing role for design in a lot of these teams. I think if you look at what Google looked like ten years ago – highly engineer oriented, engineer driven company and culture – has done well to evolve into something that has design as a central aspect of what it does. Is that indicative of a change? Are we seeing new types of companies as a result of that?

Jeff: Yeah, I think so. I was a designer at Google in 2005, which I tell people, is a lot like being a baseball player in Europe. People are like, “That’s so interesting, I have no idea what you do.” It’s tough. When we did Google Analytics, we did that 100% off the radar. There was no design review with Marissa, nothing. The VP of engineering for all the reporting and analytics just hid us away and so then we could do that. I think that is the only way we were able to accomplish that and we came via acquisition so we actually had a mandate. We had an 18 month project, you have to finish this to get the rest of the money actually. That’s how it was all structured. The reality is that Google has gotten much better. The thing I found most interesting about it is that it happened top down. It was Larry Page who, from what I have heard, sat down with his direct senior engineering leads and said, “You have to do this. I know you have all these milestones, and these goals and OKRs and stuff, but you are going to do this and we are going to do this by this date and it is going to be across everything.”

Now we have these wonderful artifacts, like material design, as a result of that and I think it has been phenomenal.

Paul: Do you think designers are typically good CEOs? The reason I ask that is that there has a whole bunch of designers who started companies and at some scale, at some point they step back into a product or a design role, who actually hire a business oriented person to take over.

Jeff: I would say that happens in lots and lots of companies and it is not just designers. It’s absolutely the same for engineers that start companies as well. That happens all the time. At some level, especially if you are really growing and you hit 500 people, you are being prepped for going public and all of that entails, having somebody navigate all of that with a lot of experience is probably a really good idea. Not always the case, Mark Zuckerberg has done a wonderful job of taking it all the way from the dorm room to Wall Street. I think that happens all the time and to be perfectly honest, I think designers have a tremendous amount of innate skills that map directly to building businesses in very sustainable and successful ways.

It’s one of the hypotheses that we are working with at True when we are investing. We are looking for very strong product sense and then how that is applied to the rest of the functioning of the company. When I was building Typekit with the team, we applied the same kind of design thinking, more like an user experience process. We would apply that to every aspect of the business and that is ultimately in my career why I ended up starting my own company. I never imagined I would do that but I was always trying to get user experience more ingrained in everything we did. I could do the best possible work I could on a product and then some really crappy partnership would happen and it was a terrible user experience. But we are jamming it together because the salesperson put it together and it doesn’t make any sense. That should have been from the beginning based on user research. We did that for absolutely everything, for all the sales process that we did, for all of the business development partnerships, the terms of service, we spent all kinds of time designing and writing so humans would understand. Customer support, for sure, God I wish your product existed when we were building Typekit because we built all that crap ourselves. All of that, I think, can put a designer in a position of being great at leading a company.

Paul: I consider myself first and foremost, a designer. That’s my original background, and when I joined Facebook, I joined the design team. And after two weeks, they asked me to be a product manager. I came from Google where if you are a product manager, you need a computer science degree. You actually have to have a computer science degree; it’s very explicit. I can’t code to save my life so that was not where I was at. I kind of said this to them and they said, “Well actually, we need you in the product management team because you have a design background.”
It was an amazing experience for me because just prior to that, in the two weeks that I had joined the company, I’d run research on the product I was going to work on. I had four recommendations for big things that I thought we should do and I was being pretty dogmatic about it, trying to make an impression or trying to sell the craft, all the usual things.

The moment I flipped into the product management role I was effectively reading my own research from the other side. I basically decided not to do any of the things. You can imagine this was quite traumatic for me. It just highlighted to me that designers and researchers have a very specific point of view on the world and often product owners or product managers have a very different point of view. They actually shield, by their nature. Their role is shield people from all the crap, basically. That is why I wonder about designers as CEOs. You will read reams and reams of stuff in the media that, says designers should start companies. It’s worth thinking about whether the attributes that make a great designer are not the attributes that make a great business person.

Jeff: I don’t know that the singular vision that designers are often accused of is necessarily a quality of being a good designer. I think it would be the case, no matter what your sort of craft is, when you step up for a role like that, you have to be able to balance those three key components. You have got to be able to think about the user experience. You also have to know deeply the technical constraints of what you are building. And you’ve got to know the business drivers – how is this actually going to be successful and make money? Knowing those three things, no matter what your role is and what your background is, is vital for anything to be successful. We are just, as an industry, after 20 years, learning that that user experience part is an equal component to the overall mix of success. This overnight success that took 20 years to get there.

Paul: I wonder was Apple’s financial success a driver of growing the influence of design inside major tech companies, like Google?

Jeff: Oh, totally. Why would they change? They were printing money. Money was just falling out of the sky onto the Google campus. Why on Earth would they want to change anything? Whatever we are doing, works, don’t touch it. I think that is why it is so impressive to see how much they have changed. But also the diversity of their business now as opposed to ten years ago, when it was purely that search results page, and we don’t change a single pixel on that page without thousands of AB tests.

There is a corollary to that in the startup world which is that the current environment, being so frothy, means that small companies are probably raising way too much money, because it is all available. You will have a fifteen person company with $20 million dollars in the bank. They find the problem is that they are not motivated and hungry and scrappy and worry that they are going to run out of money in eighteen months. “I’ve got plenty of money.” I don’t think they work nearly as hard at every single detail to make sure that they are both innovating and optimizing at the same time.

Paul: We have a very similar thing here – we call it fighting for usage. In the early days of Intercom, Des, one of our co-founders, will show you. If he goes back to his Gmail account, his first emails were like, “Hey check out this thing we made, try it. Is it good? Is it bad. Is it useful? It’s free.” He was literally fighting and fighting for usage because the company would die otherwise. They are literally fighting for their life. One of the things that we found hard, and I found it hard as much as anybody else, in a period where we are growing fast and have raised a lot of money, is that same level of scrappiness, primal instinct to survive, all those things.

Jeff: My co-founder at Typekit Brian Mason, in a past life was an event producer. He worked on Broadway, and worked in politics; he did those sorts of events. That’s where we got that attitude of butts in seats. The venue holds 700, we have 500 tickets that we have sold, what do we do? You go find 200 people, right now! Where can we find 10? Where can we find 2 more? We would have revenue goals and we are a few thousand dollars off, we are going to go find those people, right now. That kind of mentality driving the business, especially when you hold so dear the value of user experience, you put those two things together, I just think it is magical.

Developing a culture of design

Emmet: In some sense, it seems to me, like you guys are describing culture. And how culture inside a startup or a company might change over time from something that is very scrappy and very oriented to fighting for usage and so on. Is that something that can be designed? How do you shape or mold a team as it grows? Is that something that you think about when you are getting involved with your companies?

Jeff: It’s the only way you have culture is actively and by design. I don’t think culture is a personality that emerges from your company. I think it is something you create, and you do it every single day. The way you do that is you define a set of values that you believe. You don’t just put them on some nice sign on the wall and everyone looks at them in the café and then they walk away. You practice them every single day. For us, when we would do product reviews, anybody from the company could go. We would have engineers, even the most low level system engineers coming to product review because they had valuable insights to offer. We valued design so in all the presentations that we gave ourselves internally, we put our craft into it. That’s the only way that it is going to happen. I think really bad things happen when you just let culture emerge.

Paul: How do you bridge the gap? We have values here, values that the founders and leadership team believe in. These are things that we want people to learn effectively or at least assimilate into that culture when they join. We have posters. That’s the easy and less important bit. The harder bit is transferring that into daily action.

Jeff: Honestly, it is just like the design at Google. It is top down. Everybody in the company is going to look at the leadership of the company and they will either see the values being practiced or not. I have two kids, they don’t listen to anything. But they watch what I do and then they do what I do. That’s the only way they learn. It’s exactly the same in any organization. It works both ways as well. Practicing good values and having everybody see that.

I heard a great presentation from somebody who was hired as the CEO as a 100 person company that was about to be a 30 person company. It was in chaos. He found this terribly corrosive culture in there. The thing that was valued most in the organization was winning an argument. That meant that you stood up for yourself and pushed through and you got to it. It was a small group of people that would just shout other people down. He got the leadership team together and said, “We’re not going to do that anymore, and if you see it happen in a meeting, stop the meeting and say let’s not do it this way, let’s do it like this from now on.” They actively did it and within six weeks a few people had left the company and the company was doing much better from a cultural perspective. I think you can do both, sometimes it has to be super explicit, almost like discipline.

Paul: It’s tricky. We have seven values and one of them in particular, when we got together, no one does that. Then we said “Well, do we want people to do that?” It kind of turned out that we maybe did not want people to do that and so we are changing it. It’s kind of interesting. Did a different behavior emerge and so we changed the value or did we just get it wrong in the first place?

Jeff: It could be a little of both. It could just be you are a more mature company than you were before and now you see things a little bit differently. I think that is totally a reason.

Emmet: It sounds like there is an opportunity in which that can take hold and get embedded as culture among the people there. We have realized that the people we hire today will hire next year. Is there a time limit or a size limit by which that has to take hold?

Jeff: I don’t think so, I think it is fixable, but again it is very explicit.

Emmet: I guess in the way that Google could do it. Changing tack slightly, it seems like a very interesting time for individual designers at the moment. Partially because of the emergence of a whole lot of new tools. Photoshop is something that maybe almost everyone in this room has used but it was …

Jeff: Hang on a second. How many of you use Sketch now? That’s pretty cool.

New tools and new workflows

Emmet: So this is the crux of my question. There are a ton of other tools, prototyping tools and so on. What’s happening there? Are designers finally being given the tools that they need? Is this some kind of implicit failing in the previous generation of tools that we had? Why is the explosion of design tools happening now?

Jeff: It’s a good questions. I think it comes from the fact that we are progressively working differently. There was a time when a designer’s job was to make mock ups. They would get requirements from a PM and maybe even do some research and then draw a picture of what the thing should look like, and then give the picture to somebody else who would then make the thing. So many of the companies that I have been involved in and that I see now in our portfolio, don’t work like that at all. The process is much more like sketching something on a whiteboard, then a designer doing a very quick wireframe, and that goes into Sketch. And then a screenshot from a browser, and then another wireframe. It’s so fluid and it is all happening in real time and there is not this process with deliverables. A lot of the previous generation of tools were designed around this terrible situation where all of the designer’s effort was going into an artifact that was never part of the product. The closest it would come, was when somebody would cut up the layers and take all the bits out and turn that into the UI.

They are doing all this work that doesn’t translate into momentum in the product. These new generation of tools is designed around this much more fluid collaborative process where a whole team is working on the thing the entire time, instead of in stages. I also think that there is no scenario at all where anybody spends $700 for a piece of software. Those days are gone, way gone. I remember that. When I was running Typekit, I would look at the spending that we were doing, and we had two copies of the creative suite back then, but then we were paying thousands of dollars across all of these services that were monthly. Were were using GitHub and Trello and New Relic and all of these things that the team absolutely needed to be able to do there job. But they were all services and they were all vital. They were, what we call, production adjacent – they were not in production. It’s not like the AWS stuff, but they were all these tools that we needed to help us make the thing and work together. That’s what direction I have seen it going.

That’s why we have things that are growing so rapidly, like Invision, which I think is a great example of that. We’ve invested in a company called UXPin which does prototyping and stuff like that. I think it’s wonderful the way tools are changing.

Paul: I think there is a huge other factor too, and these things for me are tied. Have any people here used Personas. There was a time in my career, not that long ago, where I created personas for everything. There was this process of doing research – create personas, create scenarios, create wireframes. And they must be low fidelity, you get crucified if they are high fidelity.

I hope that’s going or gone. Personally, I’m not a fan of personas these days. Maybe in times to come, I will be again. I think that the process has changed a lot, where Balsamiq was for wireframes and Photoshop was for high fidelity mock-ups. Now, I think there is a world where people can design faster at a higher level in Framer, or in code, or in Sketch.

Jeff: The frameworks and the infrastructure that we have to make the code is so much more advanced that it doesn’t take all this time just to get something to show up in the browser or on the phone. You can leap forward and immediately be conversant in the native language of the stuff you are making.

Paul: Something I started doing at Facebook for the first time was designing in Chrome and Specter basically. We have the product, we want to change it and … You’re voice only works in that mic. Design in Chrome and inspector is this amazing thing.

The problem is that you needed low fidelity to talk at a high level and if you had a high fidelity mock people would get in the weeds and the details. You just need the skill now – to be able to talk abstracted to a higher level looking at a high fidelity mock or actual code.

Jeff: I agree

Emmet: I feel like we could keep going for a long time here but I want to also give a chance to open it up to the room if people have questions, it might be a good chance. I will move around with the mic.

Designing around jobs to be done

James: My name is James, I’m from Huddle in the UK. How should teams be built? Should they be built around parts of your product, should they be full stack including apps and service side developers in the same team? How do you deliver the best experience across platform?

Jeff: That’s a good one for you.

Paul: We are a big fan of this framework called Jobs-to-be-Done and we use it very much at the framework level and not at the actual details level. Jobs-to-be-Done is a whole other philosophy around how you should run these research interviews and come up with these jobs. We use it mostly at the framework level and effectively it’s very simple. It basically says that you should not think about market segmentation, or classical ways of segmenting people, or market or looking for product categories, and you should actually look at the jobs people are trying to do. When you do that you start to see that a lot of software is used in multiple different ways by multiple different people. That’s why I am not a fan of personas. I think they are mostly stereotypes and even archetypes aren’t even that helpful.

We are a big proponent of Jobs. Each of our product teams focuses on a job and actually have a product that is based on that job. In that team we have a product manager, a product designer. We call them product designers, not UX designers, and that is deliberate. The main reason is because we want them to think about the whole stack of the product, everything from the highest level conceptual design to the lowest level visual design, throughout the process of shipping, post shipping, iterating, iterating. So there is a PM, product designer, an engineering lead, and depending on the team there is 3,4,5 engineers. They are full stack engineers. We don’t really make a distinction between a front-end engineer or a back end engineer. The kind of principle is if someone can code, they can code. Languages are easy to learn. That’s the general philosophy, so those teams are designed to maintain speed and efficiency by staying small.

James: What happens when one team effects another team’s parts of the application or code, how do you maintain high quality codes that you continue? You’re saying you’re slowing down. One of the reasons that we slowed down as we got bigger is our code base got horrible and so our developers, they were wading through horrible code in order to improve things.

Paul: On the code side, honestly, I’m not the best person to answer that question. We do move people between teams, so if someone builds up a specialty in part of our code base, after a while they will move to a new team. This was actually very deliberate and strategic, teams that predicted dependencies on each other. We will actually move people as we see fit. On the code side, that is where we are at. On the design side and the product side a lot of it is down to my job – to be the glue between these different teams.

The final part of the picture is that we are building a team, a specialized team. They are called system interface, which is either worst or best name, I’m not entirely sure. It’s very deliberate as well. That team’s job is to own our interface but think at a systematic level. We want them to think about systems and so over time, hopefully, they build reusable components. Not patterns at a UI level but patterns at a product level so a lot of this problem actually goes away. That’s kind of our plan.

Jeff: I think that’s good. We always practiced that lean startup methodology in minimum viable product. I fundamentally believe the sooner you can get something in front of your customers, the more opportunity you have to learn. The more times you get to ship with the amount of money you have in the bank, the more opportunity you have to be successful and improve the product. Nobody ever talks about the technical debt that is involved in going so fast. Because you never go back. We struggled with that a lot and had to take a big chunk of time to re-atomize all our stuff because it got monolithic and heavy. I don’t know what the answer is, ultimately to that.

Paul: To be completely honest, we absolutely have problems here too. People use the phrase, “You are building the ship as you are flying it.” When we started Intercom, and you build the first version of Intercom, or the second, or third, or fourth version, you don’t build it for a bajillion users. Or if you do you have totally over engineered it. You build it for the predictable future. We have had to go back and re-factor a bunch of stuff. Things like our data store. We are working on that right now to build extra capacity, make it faster, a whole bunch of things like that.

James: Does that fit in your Jobs-to-Be-Done or is that separate?

Paul: That’s a very interesting question. It’s informed by them. We can look at features or products that we are going to build soon and easily extract out how it is going impact your infrastructure.

Emmet: I feel like we deal with design debt sometimes just as much as we do technical debts. It probably depends what extent of product footprint that you are actually building out. That is something we definitely try and solve in the same way of adopting patterns and thinking in a structured kind of modular way as well.

Eleanor:Hi, I’m from the real-time messaging app called Say Hi. The role of product designer has gained a lot of popularity in the last five years or so. Where do see it in five years time? Do you think there will be more value in specialization and expertise, or in more of a broad Swiss Army knife mentality where you can code, and design, and ship, and do everything?

Jeff: My guess would be the latter. In fact, I have seen us pull back more from specialization. Earlier in my career, 10 years ago, we had roles of user researcher and information architect and all of this specialization and I don’t look for that all anymore. People will have different combinations of skills and I find that very interesting when you are building a team. I think somebody who is conversant broadly like you said, being able to design but also, if not able to code, very familiar with the capabilities of what we are able to do.

Paul: It’s actually a fascinating question. I tend to generally agree that generalism over specialism. Having said that, I think it depends. We have emphasized generalist designers for sure because they can have more impact across the company and product faster. As we grow, there is definitely room for specialism – motion design, animation, visual design. We have hired a visual designer who is really talented and that is very much a specialism.

I actually think a bigger problem, or opportunity, depends on how you think about it, is finding designers who can think in systems. The internet is effectively an ecosystem, it’s a network. We’ve interviewed many designers who look like they have a great portfolio, look they have designed great products and they actually can’t think in systems, or they never had to. I constantly encourage all our team to read about systems; basic information systems such as how they work. That to me is a much more important skill to develop.

Thinking visually

Matt: Hey I’m Matt, I work for an UX consultancy called Xwerk. Earlier on, you said that as you hire more people, you eventually secede the role of the holder of the marker and the whiteboard.

Jeff: No, I still always hold the marker and the whiteboard.

Paul: Yeah, me too.

Jeff: It’s always in my hand.

Paul: It’s my favorite thing.

Jeff: I just don’t get into the room as often as I used to.

Matt: That’s kind of the question. Are you always going to get back into that room and is it always a language people understand when you go and draw abstract scribbles on the board?

Jeff: I still do that. Any meeting, any conversation that we are having, is almost always standing at a whiteboard. And if it’s not drawing interfaces, it’s drawing interfaces for how the company should be organized or how we will think about strategy in the future. The way that I think and communicate is typically very visually. The time I spent at Adobe, so much of the decision making, and what ended up as part of the user experience came from small groups of people, all of us doing this together on the whiteboard. It was a big change of pace for a lot of the work that happened at Adobe. It was very meeting culture and so many meetings, people would go away and do work, then we would have another meeting and look at the work. We kind of tore that apart. Ultimately, I would say it was a dozen people who were the core group that had the influence to drive all of the new work that had to be done and that was manageable. It got fractal after that, but the core of what we were going to do and all the strategy came, still I think is very hands on there. So it is possible to do.

Paul: I just want to add one thing. A designer at Google, when I worked there, John Wiley, who Emmet and Jeff may know as well. John said something to me many years ago that I will never forget. He basically said, “Every meeting, without exception, gets better when you pick up a whiteboard marker.” I kind of lived by that. I always encourage other people to do that too. Even when you are talking details, like UI details, it is often more productive to actually to get back on a whiteboard, rather than people huddled over a screen trying to move stuff around. We have whiteboards basically everywhere here, all the walls.

Distributing design around the whole company

Chris: I’m Chris, I work for Banjo. We’ve recently grown to 500 employees very quickly and we are doing a lot of work just now to make the design feel more inclusive throughout the company. I was wondering how you have done that in the past or if you have any recommendations?

Jeff: One of the things that I found worked very well is exposure to customers. The easiest way I have found to do that is through very simple usability testing. It’s like this light going off in so many companies that I’ve worked with where I am just like, “Why don’t we just take 6 or 7 users, put them right through the existing products, we will write down some tasks that we want them to do, it will take fifteen minutes each, no big deal. Then let’s make a highlight reel and show it at the next all hands meeting,” It’s shocking. Especially when you see people who have worked on something, to see a user struggling to get through an interface or through a flow or an onboarding experience. It’s just remarkable. What I find is it is temporarily humiliating, but then turns into a sense of shared empathy and growing that in an organization requires people to see the customers literally using the product. That’s just a very tactical way of at least getting started. Then I will have engineers say, “You remember that woman from Florida who was doing the, and she couldn’t, let’s fix that for her.” What a shift that makes in especially very technical teams.

Paul: I think that’s the number one tactic I have used in the past. At Google it was basic user research. Sometimes we ran studies and the goal of the study was actually to change the stakeholder’s opinion of what’s supposed to happen. The challenge with design is it is open to interpretation. Everyone has a point of view and it is very subjective, or can be interpreted as subjective. The most humbling way to fix that problem isn’t showing the great design work you’ve done, which is just open to interpretation. It’s actually just research, and putting people through torture, basically. Seeing people over and over and over again struggling to use the basic functions of a product.