Design systems and other internal platforms as products with David Demaree from Webflow

Rebecca: Hey David, how’s it going?

David: Pretty great how are you?

Rebecca: I’m excellent. Tell me about the Legos behind you.

David: Okay, so this really cropped up, especially during Covid — like a lot of other hobbies that I did as a 10-year-old that just came back when we had nothing to do. Let's see how easy it is for me to just turn as I have a fake blurry behind me….

We've got the Disney Castle… This is the first one I had, kind of the gateway where around Thanksgiving during Covid I built this Disney Castle, which they just relaunched by the way, because Disney redesigned the Cinderella Castle in Orlando. And so now they’ve discontinued this one. There's a whole new colorway. It's identical in every other respect. I’m sure the collectors are buying it. I don't have room, obviously. So that’s the Disney Castle.

This is the hot new Lord of the Rings Rivendale set. These are all ones that they had been marking as 16 and up and they recently made them 18 and up. So they're the adult Legos.

And over here we've got the Spider-Man office building. We have a Lego store — it’s very meta, like a Lego store building in Lego. And then a few of the modular buildings so I have my little town. And at one time really keeping the little Orlando theme going, instead of the modular buildings, they had Diagon Alley from Harry Potter.

So one side was like Universal with the Spider-Man building and the Harry Potter, and then the other side was Disney.

Rebecca: Very nice. We also had kind of a Lego takeover at our house during Covid. Our whole dining room was lost.

David: IKEA has gotten a lot of my money setting up shelving so that I have someplace to put this stuff.

Rebecca: Well, thank you for coming on the show today, David. Part of the reason I have you here is because you have a really interesting background. So tell me a little bit about your background and some of the projects that you’ve worked on, and where you're at today.

David: Yeah, definitely. So where I work right now: I’m a Principal Product Manager for what Webflow calls the Designer and if you’re not familiar with Webflow, it’s a web design product in a browser. A lot of what we’re talking about today with design systems is from my previous job, so I’ll get to that in a second, but what I work on now is Webflow, which is a web design product in a browser, and it’s a kind of a pro tool for doing the web design that you would ordinarily have to do in code. But there’s a lot of really great visual affordances. And so my area of responsibility loosely covers a lot of the product surface and more specifically the styling and webpage composing — really the core meat of the product. But I work closely with like a whole bunch of other people on collaboration, enterprise features, dynamic data, and stuff like that.

I’ve been doing that since last November, which is the job I took after I left Stripe and I was at Stripe previously for a year where you and I worked together well — or didn’t really work together, but chatted a bit because we were there at the same time. I was working with their design systems team. I think there was a lot of disagreement at various levels about what they were trying to do with the design system, and what problems they were trying to solve so that’s something we can get into. But it ended up being an awful lot of building out the React libraries and design system infrastructure in a really interesting way which hit some very familiar problems.

I think a lot of the stuff that I’ve been working on has related to design systems and to fonts, which are very much part of a design system and the challenges are very similar. I worked on Google Fonts for a year and a half as their Lead Product Manager. I worked on the Material Design for about the same amount of time as one of the Lead Product Managers on the overall material system. And prior to that, I was at Adobe for an eternity — about seven years — first as an engineer on the Typekit web app, which was — for younger people, zoomers and the younger millennials: you used to not be able to use fonts on the web. And then they introduced some standards for doing that, and Jeff Veen and some other folks launched a startup to provide a hosted service for doing that. That was really cool, the team was really cool. I joined as a startup and then when we were acquired by Adobe, I was acquired with them and then just didn’t leave for most of a decade.

Rebecca: Typekit. Man, that is a blast from the past. Just for all our young listeners out there: You didn’t use to be able to use fonts on the web!

David: Yeah, we really come off the full circle from “oh gosh we wanna use fonts! Why can't we?” to “you really shouldn't use fonts. It's bad for performance.” Where I'm like: I will throw six fonts on a page. I mean, I get no page views. I have no concerns about performance. My Lighthouse score is terrible.

Rebecca: Go to town with your fonts. Well, the reason that I wanted to have you on to talk here is the set of experiences you have around design-related systems. I’ve also worked in this space years ago now, but I worked in the space and just have been really struck by how the problem set is the platform problem set.

David: Yeah. Yeah, totally.

Rebecca: It is still very much the platform problem of how you respond to people who feel you’re slowing them down because you’re trying to do things the right way and they just wanna ship. And how do you prove the value of the work that you're doing when it is diffuse and extremely difficult to quantify?

And again, these are the problems of the platform. So yeah, I just wanted to talk to you about what you’ve seen in this space and how you’ve navigated some of those challenges of convincing people that this is worth doing and it's worth doing right — even if doing it right makes some things feel they’re slower first.

Like working on Material, that was also a moment in time — a huge moment in time where Google was like “let’s look better.” I don't know if you were there at the origin of it, but what do you know about the story of why that happened and how it actually ended up? I think you could say pretty clearly it’s been successful on a time horizon of about 10 years.

David: There’s a lot — even just in those sentences — to unpack there, but the answer to some of it is right there. So I wasn’t there for the inception. Material was publicly announced back in 2014, which is when I was still at Adobe for a while, but the whole industry kind of took note of it.

I would say there was a very accurate but at the time very overwrought, statement of purpose from Matias Duarte, who’s the VP of Design, and the main champion for Material, and had been a design leader on previous, very well-regarded, mobile interaction things like the Danger Hiptop, which I think was the T-Mobile sidekick, or that’s how most people knew it. Also like LG’s webOS stuff, so Palm webOS initially. Basically a lot of stuff that had not really succeeded in the market but had been very interesting mobile interaction paradigms. Matias had been all over those things and he came to Google, and initially where this all started — if memory serves, and also from talking to people, who were there, who I worked with — was that, first of all, the main thing that Google knew was a gap between the whole Android platform and iOS, was that interaction design. And so they needed to level that up to be competitive, and so they brought in Matias who had a lot of really great ideas.

And as part of that, they developed a visual language. The way they approached it also as a way of differentiating from Apple was having, what they called, a quantum paper: a physical metaphor, which was not constrained by physicality. So for example, you’d have buttons and surfaces that had a little bit of physical rules.

There was a lot of rationality to how different layers and shadows went on top of each other, and over time, that proved to be very restrictive. We can come back to that. But I think it was very appealing inside of Google because they’re a very rational engineering-led organization and what resonated with a lot of other people was that set of rules where there are some things about stacking things. There are things about relationships and space between different panes in some kind of physical space that make a lot of sense and which have a nice physics and logic for things that you're gonna be touching. And I think that was the key insight, less like a design system but like how do you operationalize it?

I think that’s really what we wanted to get into but I think that that was really the appeal to it. In terms of how they got it done, Matias had been doing stuff on mobile, and the main interest — the now and forever home platform — for Material is on Android as the design language for the Android operating system.

But there was also the opportunity of how do you then have a cohesive design language for all of Google? Because the problem then, which also persisted over time and has kind of like finally started to gel, is that Google products did not look similar from one to another if they didn't have the Google logo with the rainbow colors and the bad font. Ugliness was almost the house design language for Google products until very recently. So they tried to have the design system do two jobs. One: to be the house design language similar to Apple's UI kit but for the Android platform, and also have that as the brand design language for Google products across all the different surfaces.

This is why you have Material Design injected into the iPhone so that things may not feel like iOS, but they will feel like Google. And that also leads to the maybe unintended side effect of Material being this more general thing. Like maybe you wanna try to use it on products that are unrelated to Google, but because it is so pervasive with Google products, it will always feel like Google, at least in that original Material 1.0 flavor.

Rebecca: It’s interesting you mentioned that the impetus for this — and again, I’m indeed talking about platforms generally — was competitive. It was the fact that Apple was eating Google's lunch in the phone space. That gives you a really clear rationale for why to go do something like this. I haven’t seen that stark of a rationale in other cases.

David: Yeah.

Rebecca: And I’m curious, what have you seen work? Obviously, that’s a very successful rationale and it’s a quantifiable one. What have you seen work when you don’t have that to talk about what the value of doing all this work, imposing all of these constraints? How do you talk about the value of that?

David: One thing is just — and this is something you’re speaking to — I almost feel like I should have this needlepoint hanging on, if that was physically in an office or like a Ted Lasso to scrawl it on a sign and paste it above the door. Apple and Google are the exceptions to every design systems conversation for the reason you just named: they need to have a platform language.

The only other player that could conceivably have a design language that works the same way is probably Microsoft, and they’ve had several over the years that the current one is Fluent, which is actually pretty cool. So if you’re not a platform vendor where you’re putting out the basic visual metaphors for a whole platform, your design system use case, first of all, has to interact with those other things like web browsers. Like Chrome has its own kind of de facto language and it varies from platform to platform, et cetera.

So first of all, you’re gonna have to have some interplay with someone else’s design language or design system. And secondly, your need to have a differentiated design language is very different because, one, you're probably not running a third-party platform on the same scale, or maybe you are, but, the use cases or the scope are gonna be a lot different and you can be very crisp about where do you need to give people third-party flexibility? Where do you need to maybe give customization or not (usually not)? But I think the biggest difference is just really that the impetus to make giant systems and giant changes that are maximally flexible is just not there.

To give you a really concrete example. One problem that Android had faced for several years, and I think is still kind of grappling with, is that if you’re using Material Design, which is a very – almost hyper-cohesive, it is an extremely rigid and cohesive visual system, including now in its current form as Material 3. It used to be stacked boxes with shadows. Now they got rid of the shadows. But you have a certain approach to, not even round recs, but like squircles and shapes that are very difficult to produce, pastel colors that need to be algorithmically generated, and stuff like that. You can inject your own opinions of like, “My app is red, therefore, it is my app and not your app.” Or, “we’ve made the typography a brand typeface instead of Bravado.” But the Material 1.0 gave you only those levers for customization, which was very frustrating. Whereas UI Kit on Apple is minimal enough that a lot of times as long as your things are 44 DIPs high as opposed to some other number, you're fine. As long as your buttons interact in certain ways, you're fine. So they were kind of operating on a very atomic level of “here’s what you need for all the interactions and the general shape of things to be consistent, but within those boxes, you can color however you want,” and Google was a lot more prescriptive.

So for most design system use cases, the goal is not to provide a whole third-party ecosystem, the boxes to color in to make their own applications, because you are one of the companies probably making those applications. It’s all about what you want to get out of it, what do you need to be cohesive? What are all your different touchpoints?

And if you really have like one product and it’s not that big, you could talk yourself out of having a design system. It may still be a good practice so that you can keep flowing and moving effectively and efficiently. But the goals are not the same as if you were having to have a suite of 50 products each with a thousand screens, and they all need to look like they’re part of a cohesive whole.

Rebecca: So, you leave Google and show up at Stripe, which is a very different company and a very different size — orders of magnitude, I guess — from Google. What were the problems that the design system was trying to solve?

David: Like I said earlier, I can dig into that. I don’t think there was an agreement necessarily on what they were trying to solve. Rather, there were a few different problems, and the design system team had a few that they were focused on, and leadership had a few that they were focused on — both the short and long term.

From the company's perspective, there were kind of two things. One, most Stripe products that had a user interface lived within what they call the Dashboard, which is the management UI that merchants use to manage their Stripe accounts. And so that became a kind of internal platform that needed some guidelines to tell people if you’re designing a screen that’s gonna live in the dashboard, the dashboard team is not building or designing that for you, you have some other team doing that simply because that’s how it has to work at that scale.

So they need some visual guidelines, either just documentation of here’s how things are supposed to look, or ideally React components that they can just drop in that are gonna be pre-baked to have the right presets.

And then maybe you need to tailor them to a use case. Maybe you need some widget that doesn’t really exist. But that was like probably the most urgent use case regarding people trying to build within the dashboard. The kind of next-order concern is when you start to try to do extensibility and there was a lot of focus while you and I were both there on what launched and is available now with Stripe Apps where at the time that we both started, there was not a design system for how you could cohesively build in the Dashboard, or there was a component library with various things that people could use.

The design system that my team ran was called Sail and it was what a lot of teams used to build on the Dashboard. But it didn't have an up-to-date Figma sticker sheet or symbol set or library so that the designers could know what they could work with. We didn’t have great documentation for how the design and the engineering would interchange.

And again, we had tons of conflicting inputs. On top of that, which was a problem for internal clients, there was a big push to now make that available to third parties so that other people could build on it. And Stripe employees, some of the best engineers in the world can get on Slack, they can hop on a call, they can mend and make do — third parties can’t do that. They need to work with entirely what they have been given from you as a platform vendor; that was one category of problem.

And then the third one, which was always kind of on the horizon and never clearly articulated as a priority, but kind of understood to be something that was important, was that we had other product surfaces and other brand surfaces that needed to have some cohesive Stripe identity. And the way that had worked for the most part is there were a few typefaces, like Inter, Roboto, occasionally a version of Söhne, which is a house-licensed version of a font from Klim Type Foundry.

So like the white background, a bunch of purple, a few instances of green, and then a semi-bold sans serif typeface. And you had a lot of stuff like the terminals, the physical payment processing thing, which I've mainly interacted with at my barber who uses it for their credit cards. But you also have the dashboard, their new Link, which is if you've ever had to make a bank payment and asked for your bank account info rather than a credit card, you might see a little logo that says Link, that’s Stripe's in-house payment platform, and then all the other stuff.

How do you keep those things cohesive so that even if they have their own brands like Link does, or where you have some white labeling where the Stripe terminal shouldn’t say Stripe, it should say Original Shark Barbershop, what parts of that should still be cohesive and consistent? That's a whole other kind of hybrid, first-party, third-party problem.

And so those are kind of the three different categories of problem. It's really hard to tackle all three at the same time. And there was an agreement on which ones to do first. I’ll say the design systems team focused mostly on the second one, which is how to build the infrastructure so that whether you’re in the dashboard, or Link… What is the shared infrastructure at a very low level to support all three kinds of things, which, ironically, created almost a “non-design system” design system, where you had the platform to build a design system? There was a lot of talk of that, and then we would need a Dashboard design system, a Link design system, an Apps design system, and these would all be local design systems.

And the feedback back from leadership was, “Right, but isn’t that your job? Shouldn’t you be building that?” And that right there is the first big philosophical difference. What leadership and users are expecting is we're gonna have all the tools we need to build cohesive design.

It’s very tempting sometimes to abstract that out and say, “We’re gonna give you the tools to build the tools, and then you can build the tools, or then eventually, maybe we can build the tools.” It’s like, yes, but we need those tools first before the abstractions to build the tools. And I, at least while I was there, don’t think we ever saw eye-to-eye on which of those we were solving.

And then there was economic turnover, the layoffs, there was just total chaos. So I think, on top of the baseline disagreement, there were a few months where people were having trouble talking about what they were talking about.

Rebecca: Right. Well, you’ve touched on so many things there, and, again, one of the very consistent platform problems is: we have to build A before we can build B before you can have C, which is the thing that you actually need, but trust us, everything will be better when we’re done.

How have you seen or have you been successful at telling those stories to the leadership of “you can’t have this today, but you can have it tomorrow and things will be better”? And what does it take to keep leadership and stakeholders believing that the grass will be greener when we get there? Just kind of curious, strategically, how do you keep engagement in a project like this that doesn’t have rapid payoffs and can actually be perceived as slowing you down?

David: I think the key thing is that it requires a bit of flex on both the stakeholder and leadership side and on the team side. First, I can say that I think one of, the key principles I hold onto and that I try to preach to the teams working on these things — and it doesn’t always land, at least not right away — is that a design system similar to a font library, an observability library, a test framework, any of these things, these are ingredients. These are always going to be secondary to the main dish or even the side dish, which is the product itself.

And the teams that are gonna be consuming these systems or these libraries and the leadership that decides like, okay, is this the right approach, or endorses or doesn’t endorse things, they are thinking only of features. In the case of executives, they’re thinking not only of the features but what is the business impact the features are gonna have. And the thing that’s important to come out of that is empathy for where everyone is coming from.

Because if you’re on a design systems team — and this is again, is gonna be true for a lot of the stuff you’ve worked with on dev productivity and any number of other things is — you are way close to the metal. It’s just worth acknowledging and accepting that the people you’re talking to will never know what you know about the thing that you are doing.

And I think the first failure mode — it's not a total failure mode and I have total empathy for it — the pitfall into which a lot of folks fall is that the first barrier is that everyone needs to understand things the way you do so that we can understand why we’re doing things. And I think at some point like that may be possible, but not on the timescale that it needs to be done.

And so you have to kind of declare some bankruptcy on that and figure out how to code switch. And another part of that is like if people are asking for metrics or for proof points of like, okay, why is this good? If you’re gonna spend 18 months building out this system, you need to give us all the data that tells us that this is worth an 18-month commitment.

The other thing you gotta remember is their mental model — I’m thinking mainly of leadership — is feature work of like if you spend 18 months developing features, they had better be blockbuster, business changing, life-changing, “that alone gets you a blockbuster IPO” kind of thing, and in your mind, you're just doing 18 months of little bits of mise en place, so that at the end of it you can then make thousands of really great meals and those two viewpoints aren’t compatible.

Rather, they may be compatible, but unless you actually start to bridge those gaps and speak a common language, you’re gonna be talking about different things, not realizing you’re doing it. And so the first thing for design teams or for infrastructure teams to accept is if they’re asked for data or proof points, they’re initially gonna go to kind of a very perfectionist level of how do we show the kinds of data that would be comparable to what you get from a feature? How do we show a revenue lift? How do we show a retention lift? That is not going to happen.

The data doesn’t exist. I will actually call out Material; we burned a lot of time — I’d say about four or five years ago — where leadership had written a bunch of OKRs from the perspective “Okay, we’re gonna crank out a whole bunch of components, we wanna show a huge lift in CSAT, we wanna show all these different impacts.” And spent the entire year just with the team trying to figure out how we measure it. Eventually, Matias was the one who said: “Wait, why have we spent the entire year not making these impacts, but just discussing how we might?” Because the thing is we ended up not knowing how to measure it and had to declare bankruptcy on that part.

And so I think the lesson to take from that is you can’t treat these like they’re apples to apples. Design system work like any other platform work is not gonna show the same impacts on the same timescale. So you just need to be very upfront with yourself so that you can be upfront with stakeholders about that point. So that’s one.

The second aspect is that you can’t actually go off into a room for 18 months and build the perfect system. One, it’s not gonna be 18 months if you do that, it’s gonna be three to five years, which is basically never. So you need to keep yourself accountable to some kind of regular update and delivery, and not just update in the sense of like, we’re working on it. You need to show the work on a regular basis to keep people engaged. You need to look at it almost as an engagement or a community management strategy where you’re gonna be building things, serving a community by building components, guidelines, and systems.

And they’re not gonna be perfect. Like the nature of systems thinking and systems design is that you are not gonna make one change that has a fully predictable result. You’re gonna put it out there, get a mix of positive and negative feedback, and then iterate. So I think kind of taking that approach of just really focusing on how are you serving the people. What are you hearing from the people? What are you feeding back to them? And how do you keep a good feedback loop with your internal — or in the case of Material, external — community so that people stay engaged? That is the most important thing. The people and the relationships are far more important than the output. And the thing you can take away from that is you can be a lot less precious about the output.

There is a real temptation to say, that not only are we going to optimize for how we scale design, deliver design, elevate quality, implement accessibility, and all the other things we hoped to get out of a design system… But if you look at these things in isolation, that leads to a perfectionist impulse. You don’t just wanna say, we’re gonna give you tools so that other teams could if they choose to prioritize accessibility because you're gonna keep hitting a very familiar wall where if it still requires work on their part and it hasn’t been a priority for them to make products accessible or cohesive or to have good usability, you can make it cheaper, but it needs to be as cheap as possible, or basically free, or else, if it’s a priority for them, they’ll just do it themselves or they would’ve already done it themselves.

So I think grappling with that, it’s not gonna be perfect. Your goal is to change the conditions so that people can do things the right way more easily than they would do the wrong way. And you need to be able to do that in a way that takes into account all the variables of a massive system.

It’s hard. Imperfection is part of the game. I think that the most successful design system teams and practitioners I’m aware of are the ones that just take that to heart and do the best they can with what they have.

Rebecca: Again, everything you just said, resonates a lot with so much work that I’ve done in these platform situations and that it’s always interesting the kind of marketing component of this job when you own a platform of some sort. That relationship building and I think we’ve run into this a lot in productivity space, where there are things that we can measure and we measure them, but proving that this thing that you did directly made these 10 people more productive by five minutes. Drawing those sorts of conclusions.I think you make a great point that sometimes you lose so much time just trying to prove to yourself that you should do something that you’ve all already agreed you should do.

David: And then there’s a failure mode embedded there too — another common pitfall. Usually, not in this conversation, in other conversations, pessimism is my brand. So having 20-30 whole minutes where I’m mostly saying positive things is an odd experience.

I think the common failure mode here is: for good and bad reasons for a lot of leadership stakeholders the reason they would fund a design system or any other piece of platform or infrastructure is this sense of velocity. Like they want to fund a component library because in their mind you have a lot of teams building buttons and they’re not the same button.

And if they were the same button, then all the cycles that are being spent on building buttons could go to something else that’s more valuable. And they wouldn’t have to hire more people to get more features. They would be able to get more net new stuff out of the people they already have. And therefore, that’s a very vanilla kind of business efficiency.

And there's a lot to unpack there. First is, even in a world where that happens, which almost never does, because you can't build one button that has a sane API that actually meets every single use case — unless you’re Apple and you truly force everyone into a box and then you build out capabilities over two decades, like that's the only example of that that’s ever worked, and it involves Steve Jobs and Scott Forstall threatening people.

Other than that, you have to choose your battles. So you're always gonna have teams that are gonna be solving their specific bespoke needs in their own way. They're gonna be building the buttons. It's just the nature of the game. But if you then go to those stakeholders and say, “You're wrong, velocity is a myth, this is never gonna happen, read The Mythical Man-Month” they will decide that you’re a jerk and it’s not gonna go well for you. It’s gonna be a career-limiting move. So part of the balance here is you need to not engage with that and instead show here’s what we can do to make things more productive.

I mean, to the point about like how do we measure things? I have worked in situations where people are trying to figure out like, we are gonna make everyone more efficient by five or ten minutes. We’re gonna improve efficiency by 20%. I understand why someone would think that is an outcome that you can measure because it has a number and it is something that seems physical, like productivity.

Productivity is the outcome of a complex system; you actually cannot measure it in that way. No one has ever done that except through a proxy. So you can get creative and say “All right, we're gonna identify and I’ll agree on a proxy for efficiency”. Can we reduce the number of steps needed to create a bespoke button that aligns with visual guidelines? That’s a goal. Is that an OKR-able goal? Is that something you should put in your OKRs? Maybe, maybe not. But you know, the point is, you could do it. There are ways you can solve that problem.

So I think long story short, the answer is you can try to solve the problem as best you can. You can try to have a negotiation. End of the day it really may be the case that someone is gonna come to you saying, make my team more efficient. You know it’s not going to happen, but you need to try to do what you can, point to what you did, and trust that it will be received well.

Rebecca: I actually on an ill-informed design system effort a few years ago, back in 2016–2017, and I don’t think that the system itself was a huge success for all the reasons that you said like the button problem is real. But one of the ancillary benefits we saw was that it really reinforced technology choice across a whole bunch of disparate front-end apps and really enforced, at the time that was React.

People were motivated to switch to React so that they could use the design system even though the design system wasn’t at the end of the day that great. I’m curious if you've seen any sort of benefits, like secondary effects, of introducing a system and what it makes possible, or how it changes the nature of how software is built.

David: Actually the first thing on my mind is wanting to slightly modify, or give context to what I said earlier, because it can sound like I’m saying that executives are always asking for silly things, they want metrics, they want velocity, and executives listening to us be like, “Hey, what’s wrong with that?”

And another piece of empathy that’s really important in systems work is to understand — the way I put it years ago talking to someone else who was kind of joining product management at Adobe was — it's not that executives are dumb. They're usually actually very smart people, very accomplished people, and often, have 10 times more energy than any of us could hope to have.

You need to have a little bit of craziness to be really successful as a VP, SVP, CEO… that type of a person. The thing is, they have a very narrow bandwidth for any new information because they are getting whatever you’re trying to get them to understand, whatever you’re trying to explain to them, and whatever they want to hear from you has to be done in like a 10th the time with four times the clarity, because every conversation you’re having, they are having times a hundred, but across the entire organization or across their entire domain. So it’s important to understand that this is why it can feel like “Wait, I matter. I’m really important. Why can’t I have all the time to tell my story?”

It’s because of fairness, because you’re one of many things and if you’re a platform team, you're not a main dish. You’re not the feature that’s gonna make their quarter and get them in good with their boss, with the CEO, or with the investors. So you really need to keep that piece in mind. Following that principle, the thing there is you need to build up trust and you need to do that in an environment where you don’t have all the time and you're not starting out necessarily from a place where people trust.

But over time, as people adopt the system, as people get used to it and get more familiar with it, it creates an environment where you can trust in the materials, you can trust in the design system team. And so, one of the ancillary benefits is that if you provide something that is reliable and you keep it fresh and it has a lot of thoughtfulness to it — and this is especially true in like smaller organizations where you can actually like talk to the people and they can explain the story of why they made the thing — you have come in with a lot and this resonates. I can tell that you’re solving the problem that I have and that you’re thinking about my needs.

Even if it hasn’t been accompanied by a whole bunch of proof points, you can say, I trust that you are solving my problem, I am going to switch to React, to adopt the system, and listen to your guidelines. I’m gonna ask you what you think about some of my interaction design problems because I have a lot of confidence in you as a design system team. And it’s really that relationship, trust, and authority that is the main product of a design system team more than any specific thing that they put out.

And then that also maps to platform choices, it really helps to come in with an opinion. So if the design system team has an opinion of this is what we think is the right way to do front-end development and that includes using React, TypeScript, and having a certain styling approach as opposed to 15 different libraries plus random CSS sheets.

It doesn’t mean that you're gonna be able to turn all of that on a dime. But those opinions have currency and being able to say the design system team thought about it, they didn’t spend forever on it, but they came into it with a lot of experience and a lot of thoughtfulness and made a recommendation.

Then that can help settle some arguments and that has the ancillary benefit of just giving people a lot more trust and confidence in what they’re doing. Again, even if they’re not actually following every recommendation, just the fact that it’s there, that there is a North Star, helps clarify a lot of conversations.

I think the leadership version of that is even if you can’t demonstrate metrics — or demonstrate that stuff on day one, or even if they’re kind of asking me like, where's the proof, how is this gonna help me make my quarter — over time, you can demonstrate how you have helped teams be effective. Like we were a part of this launch, we were a part of this other launch, and so over a long enough timeframe you might start from a place of great skepticism, but you just keep showing up for people, and over time it will make a big impact, and that impact can be infectious across a whole organization. Again, having someone who has a clear sense of the North Star really helps everyone feel more confident that there is one.

Rebecca: This is just reinforcing for me all the ways that platforms are products.

David: Yeah.

Rebecca: I think I am always very excited to see product get involved in these platform conversations because there is a strategy to it, building up that long-term trust, and choosing your battles and choosing who you’re gonna work with and who you’re not gonna work with and all these things to consider especially when you’re trying to get something like this started.

There’s a lot of strategy and tactics to it that maybe aren’t familiar to engineers, but are very familiar to product folks. I know that can be a challenge with any product where the engineers working on the product want to make it perfect, and the product owner wants to make an impact, which may not require perfection.

How have you navigated that with engineers who may be much more systems thinkers, used to doing much more architectural perfection things? How do you balance that with “Yeah, but we gotta show that we're providing some value here.”

David: I was tempted to say I have the cheat code, which is coming from engineering. I can usually vibe with the engineers, and develop a real rapport where they have trust that I know what I’m talking about from a technical standpoint, but that’s a cheat code. And then I get in trouble for using it because I might sometimes fall into the same pitfalls engineers have in working with stakeholders saying either the full agile thing of like “Well, we’re gonna make decisions on the fly, we’re maintaining optionality, what you can trust, and is just like a big long roadmap track of we are here for you or we here for you in the succession joke.”

And what they wanna see is like, “No, tell us specific things. Show us the money. Show us where it is.” And so it’s always a learning experience for me in each specific organization, what is the sweet spot between those two viewpoints? Where are the places where a PM needs to come in?

I still have the strong conviction, like PMs that come in and tell engineers, do this by this timeline without being able to like really stand by that and say, here’s why and I’m gonna get you on board and I'm gonna sit with you as long as I need you to get you on board. That can very often be a failure mode.

But doesn’t mean you can’t… You shouldn’t go completely in the opposite direction. I do think that sometimes if what you're building is really for an audience of engineers, especially internal engineers, and internal designers, the people closest to the customer are often the designers and engineers working on the platform or working on the design system team.

So there will be blurriness between the role of a product owner or product manager and them to even to the point where — and this is something even what should my role be on like Stripe’s design system team I think it was always an open question because the people who have the most strong opinions about what is Sail or Sail Next, what is the thing that we should be building are gonna be the folks building it, and they talk to other teams all the time.

Anytime I would go and have a conversation with some engineering partner or design partner on another team, it was a dupe of a conversation that Coop or Johnno or someone had already had. And so it requires a different operating model of where do you need product management? Where do you need product thinking?

And that also can lead to the pitfall of if you’re letting engineering run the show, are they doing a good job because you might not need product management. I have the heretical viewpoint that we’ve really overused the PM role in a lot of places in the industry where you can have teams that if they can get to a place where they can report up what they’re doing, have really good relationships with their stakeholders, and take on enough of the product hat for people to feel that trust and confidence and faith that things are going well, you don’t necessarily need a PM you might need a project manager or a program manager to help keep the trains running. Very often what you end up with is you hire a PM and then you tell them you’re responsible for the roadmap. You own all the metrics. You’re responsible for success, but the decisions are gonna be made by someone else.

From the PM perspective, that’s a problem. I actually see that as a feature because that means the team is empowered to listen to their customers and do the right thing, and they just need help operationalizing it. So that’s a great place to staff — by Google or Stripe terminology — an L3 program manager who is just going to come in, try to be helpful, and let like an L5 or L6 engineer run the show.

So even flexibility on being able to come in and say a PM is not necessarily gonna do the same job on a platform team that they would do on a consumer-facing team. And I will say, conversely, one of the biggest friction sources for these kinds of teams is when you have folks coming from I’d say especially the consumer product management side, and especially the consumer product executive side who’ve only ever worked in the way that works at Meta. Like we have a giant dashboard, we are observing every user behavior, and from that, we can be customer-obsessed and we can decide what to do entirely with empirical, highly rigorous, very high confidence data about how it’s gonna affect behavior.

Now, in terms of the soul of the product, we can see this on Instagram. In the long run, that doesn’t necessarily make a great product. It does optimize for metrics, so in that way it does its job, but it doesn’t necessarily make people happy.

But on platforms, it surely does not work the same way because you don’t have the data. Everything you have is a trailing indicator. Maybe trailing by a lot. So the most successful cases are where you can be flexible about just what is the product role and be open to having the folks who are closest to the problem space be the strongest voice in deciding what to do.

And then my role can often be just facilitating that. I think one of my best experiences along those lines — I mean Google Fonts — certainly I think that the individuals who are leading that team, I haven’t talked too much with Jimmy, who is the PM who took my role after I left, but he does basically the same stuff I did. A lot of the decision-making on the experience side comes from Dave who oversees the Fonts, from Tobias, who’s the UX lead, and on the technical side from Rod, who's the eng lead. And that’s how it kind of always has been, and it works really, really well for that team.

Similarly, for the longest time, the web font side of Typekit was really overseen by a couple of engineering leads for web font serving and web font technology. And so we would try to introduce sprints, agile, and various kinds of process improvements in my last 18 months or so on the team and my planning meetings with Bram Stein and Persa Zula, who led that work was very, very easy.

They had a Trello board, they would organize what they were gonna work on that sprint and what they had on deck for the next one. And I would ask a couple of questions and I’d say, alright, ship it and then move on. It was the easiest meeting of the week.

Rebecca: There’s a whole other podcast to be had here about the kind of nature of “product for platform” and the failure modes of trying to take external facing product practices and bring them to a platform team. I’ve definitely seen that not go well. There is not a one-to-one mapping of how you do product for a consumer-facing product versus how you do product for people you work with.

David: It’s funny because when I joined Google I initially actually joined as part of their IT organization, Corp Tech. Really the appeal was that Google was very different from what I had been doing. I actually only did that for six months because then the role of Material opened up.

One thing that I and other folks on my same team had observed is they hired a bunch of PMs but didn’t staff them with traditional engineering teams because they weren’t engineering teams. They were trying to have product-like outcomes from a sense that PMs were gonna bring better alignment with some kind of business goal or identify what the business goals were.

But the only resourcing around were like operations teams, people who were actually running fleets of Macs or doing little scripty things to better facilitate running fleets of Macs. First of all, they’re all very product-minded. They want to do well with their customers. They are the domain experts, but there’s no UX team, UX research, normal product outcomes, or product timescales. And so sometimes the answer really is just that product should not be there. And so a lot of folks on that team kind of eventually drifted off to other roles, myself included, because it just wasn’t a good fit for the product skillset.

That’s one of the takeaways from that: you can get creative about how you wanna take, or almost like remix the skillset of a product manager, and apply it to a whole host of problems. But it is not the same as saying, “you have a React code base, you’re gonna take a React developer, plop it into it.”

We would know as developers that even that doesn’t hold up because every code base has its own particular quirks, its own approaches, and of course the people add a whole other layer of complexity.

So if you come in and expect someone to just drop in and be able to be productive… At least with code, you can kind of trust that they’ll find their way. Like JavaScript is JavaScript, but in product you don't have that because if you go in thinking, I’m gonna work with user research, I’m gonna work with UX, I’m gonna define a business case and be able to define these metrics, and what you’re trying to work with is, say the fleet of internal Mac or smartphone deployments. It’s just that the tools and the levers are not there and you need to have a completely different approach.

But I think that’s also true of any product. You can probably seem to be effective if you go from one consumer product to another, but you’d be more effective if you can tailor your approach to the situation.

Rebecca: David on that note, really enjoyed talking to you about your experience in this platform space — on the design side, yes, but again, my claim is it’s all the same problems.

David: Hundred percent. I think the only thing that’s unique about design systems is that this is the design discipline, discovering things that the engineering discipline has had to grapple with for decades, and it has different terms because the people and the surfaces are different, but it’s all the same stuff, which is also great because then you can start to broaden the horizons and find some very interesting solutions.

Rebecca: Thank you so much and hopefully we can reconvene sometime and talk about all the stuff we didn’t talk about, but this has been great, David. Thank you so much.

David: Thank you so much for having me.