The Role of Design on Product Teams with Tyler Wanlass, Buffer

Episode Transcription

Tyler Wanlass:

I don't even really delineate design and product in my mind. They're so interconnected. Design's about solving problems, product is about helping fit ambiguity and getting it to customers, and you need both of them.

Christian Beck:

This is a Better Product original series on The Business Impact of Product Design. I'm Christian.

Anna Eaglin:

And I'm Anna. We've got a really interesting person featured today. I say that word intentionally as Tyler Wanlass is with the head of design and the interim head of product at Buffer, meaning he's both a design person and a product person.

Christian Beck:

That's quite the combo, and one you don't come across often. As a side note, Buffer is a social media management platform and is currently looking for the next VP of product, so if you're interested, tell Tyler this show sent you.

Anna Eaglin:

As Christian alluded, Tyler's career is a bit an Orthodox. He went from design to product and then became the head of design and is now the head of both products at Buffer. Being curious about his transitions, I asked him to tell us how he went from design to product management, and his response isn't what we expected.

Tyler Wanlass:

I spent most of my career actually as a generalist and trying to shape that. I think most people are trying to be a specialist. They're trying to just really go deep on one area. You think about the usual trope, Jack of all trades, master of none, but the added version of that is like master of none might be better than master of one. I've done everything, really. I've been a software engineer in the past. I've been an entrepreneur and built businesses. I've done the product stuff in various forms, built lots of products. Then I've also had a pretty traditional design background.

Christian Beck:

As he joined the team at Buffer, he migrated into more of a GM role with one goal in mind.

Tyler Wanlass:

Do whatever it takes to get this product working. It was doing all of the PM roles, but also was doing sales. Sold our first $23,000 in MRR for that product. Was doing support. Was doing design. Was doing all of the product stuff, so just kind of a good fit for me, actually. Let me do something different every day and have a lot of autonomy and responsibility.

Christian Beck:

Now, as we know, at some point, Tyler became the head of design, requiring him to now go from generalist to a specific area. What he found was an opportunity to bring together disjointed products creating a cohesive experience for customers.

Anna Eaglin:

With his background, it was a gap he knew how to fill. Getting to the theme of conversation, let's dig in with Tyler on why these different products and the different experiences needed to come together. I mean, ultimately, why do users need, as he said, a cohesive feel?

Tyler Wanlass:

This has to lead back to your strategy, really. For some products, actually, that's probably okay. If you are selling to a disparate audience or disparate markets, it's probably okay they look different. Might even be okay that they're not branded under the same company. In fact, that's actually a really valid strategy. For Buffer, we've gone through a couple of phases of bundling and unbundling. This is the phase of bundling for us, which is that we want to sell to the same customer and same department, same company, and you want to make sure that if you're using one part of our product, it's easy for you to expand into another part of our product.

If you think about our core product, initially, we might've measured activity around monthly active users, and we're now actually rolling out a product where we went and measured daily active users. We're thinking about how do we make sure that customers have a bunch of touch points, how do we make sure that they can buy from one company multiple things, and so making sure that it looks the same works together, all those kinds of things. Almost felt like buying an Apple product today and none of the things work together. That'd be pretty frustrating, but they've built that ecosystem. That's part of their core strategy. That's kind of where we've leaned as well.

Anna Eaglin:

I want to talk a little bit about specifically the role of design in that. Obviously, you want it to have a cohesive feel because if I buy this, I start using this, just like Apple products. To me, that's a great example. How do you do that with a design team?

Tyler Wanlass:

Start very tactically. You want to focus on things like structure, communication, and process, and really basic things. Is there a weekly or regular cadence staff meeting for this team? Can we make that a first team? Do designers think of design as a team at the company? Then we're thinking about you get into things like design systems, you get into things to thinking about like principles of design, how do we think about designing these products to bring them together?

Actually, early on, I went rogue. I started working on a design system myself. I started actually mocking up what the products would look like if they actually all lived cohesively into the same design system, and that was the first little bit of leverage I had to show people, "This what the world could look like. That's the design superpower. Let me show you what the future looks like," and people will just join you. They'll go with you if you paint that picture.

Just kind of basic stuff that are really getting the team talking, thinking about a design system, getting everybody bought in on the why, what the problem is we're trying to solve there, and exactly what you said, you want customers to feel like they're coming to one set of products, they all work together, they're interoperable. Then I think then shifting to a bit of a higher level goes to those design principles, the strategy around that, how are we going to execute on that, what's important, what does that roadmap look like, and just rinse and repeat that.

One of the other things though, I think if you come into an organization where design maybe is more nascent, one of the things that we've done at Buffer is just made design really transparent and accessible to the rest of the org. One of the tools we use that internally we call the Design Digest, every single week we share a couple of screenshots and a few snippets of what the design team is working on, so anybody in the company can see ground-level what's in discovery right now, what the team's designing, what we're thinking about, what we're hearing from customers. It's visuals. Again, it's a superpower. People love that stuff. That takes many reads. Everybody's reading that, and they're getting a digest of what's going on with company. Those are some of the early building blocks to get people aligned and running in the same direction.

Anna Eaglin:

Yeah. I like that. I like that a couple of things that you called out. First of all, it sounds like you made sure you were a designers felt like they were a team, that they weren't just subcontractors that were placed all around the company, and in bringing them together, you identified a philosophy, your principles, why this team exists and what they're trying to do. I love the idea of calling design a superpower because you're 100% right, as a product manager, when I present things, no one gets excited about the spreadsheets or [inaudible 00:05:53] tables, but when the design team shows stuff, man, you're right, it helps people see the future. It's also a great persuasion tool. I'm curious, bringing products together that have been running very independently I'm sure is a challenge, but from a design perspective, what kind of challenges did you and your team face?

Tyler Wanlass:

I'll start with one challenge that we faced early on and we're still tackling today, and that's around our design system. We don't have a team that's resourced just to work on that. We don't have a set of engineers that are just helping us build components. We don't have a designer that's full-time on that. Very early on in that process, I reached out to other peers, other companies, see what was going on, and you get to a bigger organization, you absolutely have the resources to have a team rallied around that.

That's how you get things like Shopify has Polaris, this beautiful design system, and you see it all throughout their product experience. It's fantastic. GitHub's similar, et cetera. One of the challenges early on was communicating to not just... designers get the value right away, but to your product cohort, to the company, like why is it important actually that we put resources, time, and energy into designing a design system, and why should we go through the cycles to implement that in the product, or in some cases, redesign some things in the products that they feel cohesive?

That challenge, again, was like really about show people, don't tell. Show them what that future could look like, show them how that could impact customers, impact the business. Show them how that relates to the challenges the business is having. For us then actually, it was customers were having trouble landing and expanding, as you noted. We're having trouble actually using more of our products. This is one way we can solve that so we can align along the problem and solution there.

That was a big one. That's one we're still working on. That's one where, externally, I think customers will look and say, "Oh yeah, these all come from the same company," but designers, of course, saying like, "Oh, yeah, but you've got a different date picker here, and this date picker works slightly differently there." That's progress though. If I zoom out, that is progress, and we're making progress there.

Anna Eaglin:

You're right, and it's hard to get those things prioritize on a backlog when you're like, "It's bothering me though. I don't like it," especially when you have... I don't know if you have existing codebases you have to deal with too, but that gets really challenging.

Tyler Wanlass:

We do. I mean, we're almost 10 years on, so we're in the thick of technical debt. One thing I think about is there's this concept of the broken window effect where if there's a small bug, a visual bug, a UX bug, whatever, the longer it persists, the more your team ignores it. They don't see it anymore, or what you might hear folks say too is, "Well, that's been broken in production for a year." What I hear when somebody says that, somebody is saying that, they're saying, "Well, it's not a big deal. It's been that way for a year," and what I hear is customers have been suffering with that for a year. Thousands or millions or however many customers have been experiencing that.

I think from a product perspective and design perspective, if you prioritize some of those... We like to call them design snacks or we call them... We have a quality team actually within the teams that do that. If we prioritize those things, we make room in our backlog for those, not only is our customer support team happier, engineers are happier because they're progressively cleaning up tech debt. Designers are happy, but overall, we care about quality, so that broken window effect starts to go away. You start to see people taking action and feeling authority to do that. It's positive.

Anna Eaglin:

I like that. Obviously, it sounds like something you're still continuing to work on today, design ops too as a existing inside of an organization. I think it's come a long way the understanding the value of UX I think even just in the last five years. We don't have to fight as much to kind of get a seat at the table, but definitely things you're still trying to work on. You've mentioned that you are the interim head of product right now, and I'm curious, coming from design, having a design background, but also having a very generalist background, you've done a lot of different roles and products, how did you take on that role, and what were you thinking you would be some of your first charters as you took on head of product?

Tyler Wanlass:

Transitioning into this role, we were coming from what I think is common to a lot of companies in which our CEO was our defacto product leader for a long time, very nitty gritty in all the product day-to-day decisions, and we're transitioning out of that, actually. That's where we're headed. What ends up happening there is the product is great, but as a CEO, you don't have time to focus on process, you don't have time to focus on nitty gritty stuff, and just focusing tactically first, are we actually executing on the things that are in our pipeline? Is our shipping cadence good? Do we have a great discovery process? Do we have good communication channels? Focusing on those things before you can go high level, and so same kind of thing there.

Really basic stuff. Do you have a weekly staff meeting? Do you have a weekly product meeting that has an agenda that your team is talking about things that are important and you're moving issues forward and you're cross-communicating about what teams are working on? I'd like to think that all the PMs at Buffer know what other PMs are working on. Even if it's just tangential, that you have an idea of how you can connect, support, provide value, or get out of the way if need be. That's really helpful.

Same thing I mentioned, our Design Digest brought the same transparency to the product teams. We have a monthly product recap called Product Beats. That's also little bite sized, "Here's what's going on in product. This is what happened last month. This is what we're focused on next month." Everybody in the company can latch onto that. They know where they can support and fall in and help out and that sort of thing.

Documented processes just wasn't a thing, so really simple things really like who are key stakeholders, what types of decisions should you be involving stakeholders in, how do you work with what we call internally customer advocacy. That's our customer support team. They're huge source of feedback, but they're usually also the team that gets caught off guard when something gets shipped and it generates bugs or support tickets and that sort of thing, so creating a clear channel for that.

Then unique to this role, one of the first things I had to do actually was hire a new PM and a backfill role. That was, just add onto the things there, but a great opportunity actually to bring somebody in new, reorient some of the culture there, reorient some of the processes, and make a good shift there.

That's the tactical stuff, just day-to-day, how's it working, how's it running. The biggest stuff though then I had to shift to, really, was all the high-level stuff, thinking about our product strategy. When the CEO is running product, it's pretty easy, actually. It's like they have a pulse on the market, they know what customers need, they know what's going on, they've lived and breathed that for a long enough time. They can just say, "This is where we're going. This is what we're doing." You get to skip a lot of the communication stuff that happens there. If it's coming from the CEO, great. Let's do it.

Moving into this role thinking about, "Let's articulate our product strategy. Let's get really crispy about what that is and how that will impact your customers, what we are doing and what we aren't doing." For us, that also led into really being specific about our target customer, who are we here to serve. We're SaaS product and risk. We're in the SMB space, which sometimes can mean you're serving everybody. You know how dangerous that is as a product person. How do I make decisions? How do I prioritize what should I work on?

Then layering on top of all of that just some basic stuff like OKRs, like, "Let's create some alignment through some shared objectives, let's get us all headed in the same direction. We've got five cross functional product teams today, so we have enough teams actually that we do need some sense of cohesion, some sense of direction and stuff there." Those are the basics. Those are the things to lay out and get going so the team can operationalize and make stuff happen.

Anna Eaglin:

Coming from a design background, you're head of product, so we talked a little bit about the things that you did to help to try to bring these disparate teams together, focusing on the Buffer product, and then maybe how that breaks down. How do you think your background in design has influenced you in your head of product actions or role?

Tyler Wanlass:

If I'm looking at it from purely design perspective, I think we know that product design and product manager is two roles, need to work together really closely. Those are some of our closest actual allies that we have. I think thinking about that actually from a design perspective, now being in the product world, if you will, it's like, "How can I actually incentivize product to work closer with design? How can I actually bring some of the stuff that design does really well, like prototyping, discovery, breadboarding, all these great fantastic tools We have to explore ambiguity and find solutions, how can I bring some of that to product as well?"

Now, actually, we're in a place where we've got product designers and product managers that are working super close together. They're in the weeds together. They're exploring lots of things. They're throwing away a lot of ideas, which actually I think is just a fantastic sign of a really healthy team. It's not, "Did you design this thing and were defacto going to build it?" but we designed it, and actually, now we've used it and tested it and talked to customers, it's not great, but I think actually pairing those two, so now I can actually see designers on the team prototyping something. Product is helping them get that in front of real customers and test it with them and just collaboratively work on that together.

That feels super positive, and that's just a relationship that constantly nurturing and keep growing there, but it's tough actually because as you're asking that question, I don't even really delineate design and product in my mind. They're so interconnected. Design's just about solving problems. Product is about helping fit ambiguity and getting it to customers. You need both of them. Internally, we talk a lot about the default actually is thinking about problem and solution, and we think about design and research as the solution phase and product is about the problem phase, like what is the thing that we need to solve that will have big impact for value for customers and the business. That's the default, but we talk a lot about how to blur those lines and maybe you both can play a part of that role.

Anna Eaglin:

Personally, that's one of my favorite parts about the product process PM and design working really closely together. I think some of the most successful things that I've ever had a chance to do, I've had really, really good relationships with my designer, so I 100% agree with you. You mentioned incentivizing that though. I think that's really interesting, incentivizing product and design working together, and the idea that they can learn a lot from each other. How do you incentivize that?

Tyler Wanlass:

I think, so if we focus on the inputs, we focus on the work that's going in, a lot of times, you'll see the emphasis being on just the raw output. Did we ship a thing? Did to get to customers on this date? First thing, it's reorienting the team to think about the inputs. What are we putting into the process, and what's the actual output we're hoping to see. For designers, I talk a lot about business, actually. I talk a lot about the business of design. It's not enough actually to design something, but it needs to have the impact. What matters is what we ship, and what matters is the impact that has on customers and our stated business objectives. For designers, lots of business.

For PMs, what I talk a lot about is if we're too prescriptive, this is me as a product person, if we're too prescriptive about the problem and the solution, you're going to get back only your best ideas. If we say to a designer, "Here's the problem, and here's how I think we could do it and can do it pretty quickly with engineering if we did X, Y, Z," that's one path, and sometimes you need to do that if you have a bunch of constraints, but I really push product people to think more about the story, the narrative, the impact on the customer, and what the problem is, understanding the problem, and let design go wild on that. Let design really think about ways to explore that.

There's so many great examples of this too in the world. You think about the classic train problem. A train takes two hours to get from two locations. How do you make a faster train? The answer actually is let's just add wifi to the train. People don't worry about the commute time anymore. That's not the type of solution you would get if you went to engineering. It's not the type of solution you would get if you went to product. Product be like, "How do we optimize the timetables and turnover times and stuff?" It's like, "Let's flip that upside down. Let's invert that problem and think about something different."

Incentivizing, probably not so much as aligning with what we hold them accountable to, but to some regards, yes. For design at Buffer, I think a lot about the career framework that we have. A big part of that actually is how they dive in and work with product on those things, how they measure the impact that it has on customers. It's not enough to have the fantastic designer prototype, but what is the impact on customers, what's the impact on the business? How do you prove the monetary value of having design with an organization?

I actually think that's the wrong question, but I think we can answer that question people that are asking. If you think about the value of design through the course of typical product development, there are so many steps along the way in which you can prove the value of design. It's really, really simple things. If you have designers in your organization, well, step one's done. Somebody has value design because they've hired a designer into your organization. Do they value product design, or do they value visual aesthetic design? You can [inaudible 00:17:41] that one.

Thinking about design offers a ton of value in the discovery phase. I think what we probably know to be true is that most companies spend way too much time in the engineering and building phase, which is crazy expensive. Do the napkin math and figure out how much it's going to cost you to have four engineers working for a month on a feature, then do the math and figure out how much will it cost to put a designer on a design sprint for a week and generate 10 fantastic solutions that have already been taken to customers for validation and feedback. You'll see really quickly that the dollars and cents is there.

But I think from the design phase starting early on, we can iterate on a bunch of prototypes, we can take those to real customers, and we put them in front of them. There's a bunch of great services that will let us do things like preference tests or usability tests to actually validate, not does it look good, but does it actually achieve the stated goals?

Think about this. We have a lot of complexity in our products around connecting social accounts from networks, and what actually is designed and looks really good might not perform as well as something just has better copy and a couple of steps removed. There's lots of ways to approach that, so using those services before we even get engineering involved to validate those things and see if those are helping reduce confusion or increase time to completing a goal is huge.

The other thing I think is that when we spend time to build those prototypes and we take those to customers and we get that validation, they're clicking through the prototypes, they're leaving some comments and feedback, and they're chatting with us about the problem, think about taking that back to your engineering team and think about the motivation that that brings that, yes, we're solving the right problem, we're on the right path, customers are feeling good about this, we're feeling good about this.

In fact, it shaves off a week because people have clarity in their mind as to what they're doing. They feel motivated about what they're doing. That is huge. It's intangible. It's tough to put [inaudible 00:19:25] you can put a week's worth of salaries on that if you wanted to, if you really wanted to do napkin math and that sort of stuff.

The last thing I think a lot about is that there's really obvious places in which we can define the value of design. At Buffer, we're huge about doing A/B tests. We do lots of feature flags as well. We roll out releases. That's just really simple black and white stuff. This version of this flow, more customers are completing it and thus completing a trial and paying us, and this versions are not. That's really, really obvious. But you can measure those KPIs and conversions all throughout the process.

The other thing too that we look a lot at is we look at how one feature might impact another, so you can do this analysis pretty easily, tools like Mixpanel, but we could say, for example, there's a core product usage metric, and we want more of that because if customers do more of that, they come back week over week, and they're more likely to actually convert their trial, and design can directly impact that, of course. The solution that we design, what we ship to customers and test would directly impact that.

Then the last thing that maybe feels warm and fuzzy is those kinds of churn survey results. If you're in SaaS, and you're looking at why customers are leaving you, we bucket those on a bunch of criteria, but one of them for us is quality, and that boils down to UX, bugs, confusing experience. When you dive in there, that's really obvious. It's qualitative. You can even measure this, and you can say, "The number of tickets we received proportion to our active paying customers." Is that getting better or worse over time? Are we getting better at solving problems for customers through design, through iteration, or is it getting worse?

Anna Eaglin:

I think you answered that question in the way a true product person would in that you're asking the wrong question, and let me tell you why. I like-

Tyler Wanlass:

That's awful.

Anna Eaglin:

No, I love it. I love it. I love the way you broke that down too in that there are some, like you said, there are really tangible benefits. I mean, you A/B test, you can see something's better, but also, again, that classic thing we understand of if I have a designer work through this before I have four engineers do it, I'm definitely going to save money. I'm going to have quality, and then thinking about churn and quality. I think that you have broken that out in a really logical way that I don't think I've ever heard put together before.

I want to round out this conversation. Thinking back now, so head of design, head of product, looking at how the organization's structured and the things that you've done, what are some of the things that you would recommend as things that either you think you did really well or things that you didn't do well that you would recommend like when you're thinking about both of these organizations, "Here's how I would structure that or here's how I would think about these organizations."

Tyler Wanlass:

Yeah, I think actually the number one thing I would probably recommend is thinking about written communication or taking a position or point of view on something. I think one of the things I've learned with both of these organizations is that culture, of course, is a by-product of what you do, and if you don't actively shape it and state it and talk about it, it won't change. It won't actually improve.

For the product work for us, it was really big in terms of product strategy. We have this default assumption of what we were building and why we were building it and that sort of thing, but I don't think we had gone to that level of granularity of communicating, "This is actually how the growth loop works. This is how the customer journey works. This is how this actually impacts our business model, and this is why we can make this decision and this decision about what we're going to build."

Just talking about it, writing about it, and the classic thing, of course, is any leadership position, you have to talk about that thing until you're sick of talking about it, almost until you bump into somebody in the proverbial hallway, because we're all remote, but you bump into somebody, and you're like, "What are our three product objectives this quarter," or, "What are our three strategic bets?" Now we're at a point where the entire company will recite those. I love that. I'm tired of talking about it, but the team is just now really grasping that, and I love that.

I'd say over-communication, really identifying what those things are, why they're important. When I think about that too, on the strategy piece, it's almost as important to communicate the things that we are not going to do as a company, like, "These are the things that we are not going to work on because we don't have the resources, because they don't align with what we're doing, they don't align with our values, or they're not aligned with whatever that might be."

The other structure stuff too, I would say, is that it's a little different moving through these roles internally because I have an insider bias. I have all this other context about who does what, who works well with who, that sort of thing. I think one of the advantages you have if you're coming in externally is you can look at this and say... you can very clearly see where things aren't working, and you can move people around, you can be [inaudible 00:23:36] you can shift, you can be prioritized, and that sort of stuff.

That personally took me longer because I had this established relationship with people and understood how people work, but objectively looking at it saying, "This is the goal for the quarter or for this year. We actually don't have the right setup. We don't have the right people working together. We don't have the right configuration to attack this problem and get that thing done." We're going through that now. We're doing those things now, and that feels really positive, but I would have done that much sooner. You can't get there unless you have clarity on the strategy, clarity on the goals, why we're here, what we're trying to achieve. That's going to be just one of the many things.

Anna Eaglin:

I want to ask you one final question. If there was one thing, maybe you're on a very, very short elevator ride with someone who is like, "I don't have time to listen to this podcast," what's the thing you want me to take away from this conversation?

Tyler Wanlass:

I think I probably would talk a bit about... We chat a lot about the value that that design can bring to the product process, and we just barely touched on the fact that, again, we spend so much time in engineering and very little in design, like we should just flip flop that. This is the classic you need an hour to chop down a tree, I'll spend 99% of my time sharpening my ax kind of thing. Horrible misappropriation of that quote, but concept there.

I would also probably just highlight that within any of these teams, there's various levels you have to operate at, so tactically understanding the nuts and bolts of the ops piece, do we have a well-oiled machine, do we have things that can go through the process and they will come out the same way every time so that when you get to the high level and you're talking about strategy and goals and objectives, you know that those inputs are really solid, they feed into a really solid system that can then kick stuff out.

I mean, sort of that classic, like nobody likes the concept of a feature factory, but of course, a factory produces consistent results over time. That's what we're trying to build, trying to build a business that produces consistent, durable results over time, and so thinking about those two, not neglecting them, tactical side and the high-level side.

Anna Eaglin:

Join us next week as we continue the series on the impact of product design. I'm Anna.

Christian Beck:

And I'm Christian, and this has been Better Product.

Anna Eaglin:

Better Product. Thanks for listening to the show this week. If you're looking for more resources on how to design, build, market, and sell better products, then head over to betterproduct.community to join, well, the community. As always, we're curious, what does better product mean to you? Shoot us an email at podcast@innovatemap.com.