Pelin Kenez & Naman Khan (Zeplin): Design Delivery is Everything

Blake Bartlett: Welcome back to the BUILD podcast. I'm Blake Bartlett, a partner at OpenView. We're here to help software founders and operators identify and unpack sustainable growth strategies in the ever- changing world of SAS. Today, we hear from Pelin Kenez and Naman Khan from design software company, Zeplin. Pelin is Zeplin's founder and CEO, and Naman is Zeplin's CMO. In this episode, they walk us through the importance of design delivery and what makes it so challenging, and how Zeplin reached tens of millions of dollars in ARR profitably, without raising capital. Hint, it has a lot to do with product- led growth and embracing the community for both product feedback and viral promotion. All that and more in this episode of BUILD. Let's dive in with Pelin and Naman. Well, Pelin and Naman, thank you so much for joining us here on the BUILD podcast. It's great to have you on the show.

Pelin Kenez: Hey, Blake. Thank you. I'm also very grateful to be here. We are very excited.

Naman Khan: Thanks, Blake. Great to be here, an honor to be with you.

Blake Bartlett: And I want to start out by getting some background on Zeplin, so maybe the founding story, the background story, would be great. How did Zeplin get started?

Pelin Kenez: Actually, Zeplin started completely as an accident. I didn't have a goal to build a company. I never really thought of being a CEO. I was a product designer working at an agency in Istanbul, Turkey. We have four co- founders, by the way. My co- founders are all engineers. At that agency, while we were working on the apps that we were building, we were having a lot of back and forth, while sharing the designs and while collaborating on them, and we searched for other tools. We couldn't find one that we really liked. And then we said," Hey, let's build our own solution." And it started very community driven. In three months, we released our first beta. We shared it on product plans and in the first week, 6, 000 people signed up. Then we actually realized that our own problem was actually an industry problem. And then we applied for YCombinator, came here to California. Right after YC, we raised our seed round, and now we find ourselves in a position that I now live in San Francisco. We now have 60 people at Zeplin. We are planning that 60 other people. We are at ARR in tens of millions. We are profitable. We recently surpassed four million users and every month, product designers are publishing seven millions designs to set plan. All of this happened before we really seriously method in our go- to- market functions. We actually have an amazing user community that really loves that plan. These were all actually the results of that. Only in the last year, we actually started investing in our go- to- market and now I'm actually very excited of our next phase of growth.

Blake Bartlett: The mission of Zeplin is to deliver on the promise of design. So what exactly is the promise of design and why is it hard to deliver on it?

Pelin Kenez: The potential of designers actually connect. When done well, it can greatly increase the usefulness of a product. You can make the experience for your users very pleasing, thanks to that design. But it's also not something that you can just get by really throwing resources at it. It's all about empathy. You need to care those users. You need to care their experience. It's not something that actually you can pay for. It's more of a mindset. Naman actually has a great story here. When we first met and I was trying to explain to him, what's the promise of the land. Naman, do you want to jump in and tell that story?

Naman Khan: Is this the yogurt story? I can tell the yogurt story. This is great.

Pelin Kenez: Yes, yes, the yogurt one.

Naman Khan: So it's sometimes hard for people who don't work in product design to understand the potential of design that Pelin's talking about. It's easier to use a consumer goods example because it's very tactical. That's where my yogurt story comes in. For those of you who need to know, I like yogurt. I tend to eat a lot of yogurt every morning for breakfast. One of the challenges I have with eating yogurt every day, is I hate yogurt product packaging. The main reason is I would grab a little cup of yogurt. There'd be this metal foil on top. I would have trouble opening it. I'd finally kind of open it. It wouldn't really open straight. Then there'd be yogurt on the back of this metal foil. I would want to lick it, because it's yogurt. Then I'd cut my tongue on the sharp edge. Things would splatter everywhere. It's something I did every day. You may say this is a small thing. Like what's your problem? It's actually an issue. The issue is I think about the person who designed that yogurt packaging. I think did they just not care enough? Did they just not think through," Hey, when I build this thing, how is the user going to use it? Do I have empathy for the top five use cases? Do I care about making their experience great because it's probably something that they're going to do every day for the whole year. If I make this experience better, they may love my product even more before they've even tasted the yogurt." When Pelin talks about the potential of design, just think about those things you do every single day. You don't need a gargantuan feature. In many cases, you actually just need to care enough to design the thing that you're building. Whether it's an app, or whether it's a yogurt container, you just need to care enough so that you're delighting the user. As Pelin said that actually you can't throw money at that problem. It's a mindset. You have to care about it.

Pelin Kenez: And I'm actually still having the same yogurt problem, Naman. I can continue with why is hard to deliver. It's hard to deliver because yes, you can design something, but the discipline required to make the real product is different. It requires a connection between functions that are really diverse. Let's say it's tough for a designer to fully understand what their developers are faced with or the same applies to developers. It's tough for a developer to do the same. In fact, I actually studied industrial product design and 50% of our training was on post- design workflow because it doesn't matter if you have a great design unless it's built or produced well.

Blake Bartlett: Within this idea of the promise of design and delivering on the promise of design. It leads me to the obvious question, which is what is Zeplin's role in that? I know for me, as a SAS focused VC, I hear the Zeplin name mentioned alongside various design tools like Figma Sketch, Adobe XD and others. Would you all describe Zeplin as being a design tool or is it something else?

Naman Khan: Blake, it's actually something else and yes, you're right. It's pretty common that we get described as a design tool. We're actually not a design tool at all. You actually don't design an app in Zeplin. It's actually a tool that provides a very different set of value for users. It's actually a tool that you use to bring designs to life. It's a tool you use to deliver on that promise of design that Pelin talked about. Absolutely, we support all of the major design tools like Figma, and Adobe XD, and Sketch. But we're really about moving from design to an actual app with running code. When you want to do that, you have a very different set of challenges that are unique, very different than creating the design, and that's what Zeplin solves. So in addition to having designers and developers, we actually have copywriters, product managers, marketers, all of these other disciplines using Zeplin to bring that design to life. It's a segment we'd like to think of, that we like to call design delivery, as opposed to design creation. We summarize Zeplin really as the following. That it's an organized place where you can publish designs, where the entire team can collaborate to ship beautiful products together. We really focused on providing that organized workspace, the ability to publish designs, where everyone on the team can work together. And then the focus is absolutely on delivery or shipping that product.

Blake Bartlett: What exactly is design delivery? What does this look like in practice in real life?

Pelin Kenez: I can take that. So there are actually many steps to bring a product to life like research, ideation, design creation, and designed deliveries is also one of them. We mentioned that product design has a lot of potential, but transition from design creation to design delivery is often underestimated. It's actually where the infinite possibilities we mentioned with design meets with the reality. You have your technical limitations, you have your time limitations, resources. Design delivered also requires precision. I can give an example here. Imagine a button being a few pixels off, and I'm not even mentioning the visual software. Because of that, a few pixels, let's say when you translate the title into another language, your users may end up with nothing on being able to read that. One other thing that I can mention about design delivery, it's also there incredible diverse set of skills come together. Naman mentioned some of them. You have your designers, you have your developers, you have your create people, PMs. We told these people with all these functions," Now you need the effective collaboration. Now that actually becomes very critical." That's why we think that here you need the right tool. You need direct process. You need the right skills for this specific step.

Naman Khan: It might be helpful with another analogy. I'll bring analogies in, yogurt and all kinds of stuff. An analogy to think of that I think may help people understand design delivery is just think about building a house, or let's say a skyscraper. Building a house, let's say. The architect is the designer. The architect is the one working in a pretty sophisticated, specialized piece of software to architect that house. Designing the floors, and designing the layouts. It's like a highly skilled function. Great. That's what they're using. But when you go to build that house, the person on the ground at the job site pouring the foundation, that's a very different functional skill. That's the delivery of that design. The person on the ground like pouring the foundation, they're going to need something very different there. You probably don't want to give them access to the native architectural design. They're not an architect. They actually don't need to see that. What they need is a blueprint. That's why you often see people on the job site with a blueprint. So think of Zeplin really is that design delivery tool that's helping bring that architect together with the people on the ground building. That's what design delivery is. It's its own category. It's its own set of problems, and that's exactly what Zeplin has been solving since its inception.

Blake Bartlett: It's a really helpful explanation. I think the analogies, Naman, that you've given with the yogurt example, or the architect and the builder example, it makes sense. On the architecture one, it really makes sense because I could envision getting a really flashy design file, perhaps even something that's in 3D, perhaps even something that's virtual reality or something like that. But again, if you put yourself in the shoes of the person, weighing the foundation, that flashy picture isn't going to help. They need the specific context, they need the specifications for their actual job. That makes a lot of sense. It also makes sense to me, thinking about this in the context of design tools, which is that a lot of the emphasis and a lot of the conversation recently has been around the actual design tool itself, which is how is the design being made? What does it look like? What you're illustrating here and really pointing to, and it resonates with me, is that that is only the starting point. How is that design being communicated to the next links in the chain? And how is that design being produced and recognizing that that is a multidisciplinary task, and that it needs tooling and that it needs collaboration help in order to make it happen and make it effective.

Naman Khan: Yeah. There's almost like, and now that I think of it, there's like a bit of an irony here. I think product designers are so awesome of having user empathy, which is I don't want a user to ever need training on this app on building. I think they're really, really good at that. I think one area where I see the opposite happening, is they're not as empathetic with their own team, which is that," Hey, like if I've got a developer, I've got a copywriter, I've got a QA tester. Don't I need to provide them with a collaboration workspace for my designs where they will feel welcome?" I think inviting the builder onto your architectural file is not being very empathetic to your colleagues, right? I think you need to be," Hey, there's a specific phase where now this becomes part of a bigger group and we need a special place to now bring this thing to life, a delivery platform, right?" Like a design delivery platform, not a design creation platform.

Blake Bartlett: So diving into the specifics of what that looks like, how has design delivery historically been tackled? What does the better way look like today?

Pelin Kenez: I can continue with this. In the older, and I was actually in that role, I did all the things that I planned to mention here. The design and the delivery were actually very siloed. You would design in your design tool. Then you would either email this files or share them in something like Dropbox, and while sharing them you would prepare all these, what we called red lines, which basically explains the old spacing, pitting between elements, all the necessary information that your team needs. Basically, you are trying to explain the design intention in these PDF documents. I need to mention as well with the design tools. We recently see that some teams are also doing these in design files. What we think is what's happening here is now, instead of putting all these resources to somewhere else like Dropbox, we see teams, let's say, replicating a design file page. They prepare all these manual things in the design file. And then they might others to look at it. But what is really hard here is you need to maintain this process in the place that you actually have to keep iterating. In some of our calls, I even see things like from screenshots from design tools, they have these separate pages. In that pages, there's a big, large text layer and arrow pointing at some screens as saying," Hey, this is not finalized. Don't work on this design." And it's getting really hard to maintain because this process is overall very iterative. That's why at Zeplin, we think that there is a better way. Design delivery is actually not new. Many of our users, like let's say Autodesk, AutoCAD, they already have an established design deliver process, as there one of their core steps. They have to walk this process into groups. We think that there are three main components... Naman, do you want to jump here to give more details on them?

Naman Khan: Sure. As Pelin says, there are really three pieces to design delivery. The first one is finalization of the design. What this means is that developers, testers, copywriters, all of that multi- disciplinary team that need to bring that design to life, have it being a living app and code. For them to do that, they actually need a locked design. As Pelin said, even one small change, you move something a couple of pixels, can have a major impact downstream on this app, so you need this locked design. That's core to design delivery. Is the design locked or am I looking at the native file that I don't know if it changed five minutes ago?

Blake Bartlett: It's the age old question of, is this really the final version or is there still a final version to come?

Pelin Kenez: Final, final.

Naman Khan: Totally, and like in the old days, in the old world, people would literally do final dash five, final, final dash five, dash one. I think we are seeing people just say," Well, check my design file and the latest one is in there," but it's really just the same problem. You're just masking it. So finalization is key.

Pelin Kenez: Here I can jump saying, because this was a discussion we had with Naman before. When we say finalize, I was arguing with Naman," Hey, there is not really a final ration with design." You keep reiterating. It's not the final, final version ever, but I think it's more on giving the clarity of what we will be working on this specific phase.

Naman Khan: Yeah, that's true. That's the irony of final design. There is no final. Think about the apps you use every day to hail a cab, or book a hotel, or whatever. Those apps get updated, usually every quarter or every month on your phone or your device, right? Those apps are never final. The app you use to book a hotel today, it probably looks completely different than that same app even six months ago. And so they're actually never final. That's why we use this term finalization, which means that," Hey, is it ready for the rest of us to dive in and build this thing?" That's super, super important in design delivery is having a finalized design, even though we know there's no such thing as final.

Pelin Kenez: And I can mention a real life example here. As a designer, I work on a page. Let's say it takes a week for me to finalize it. Then I don't know if my developer will start working on it next week, or the other week, or tomorrow. I also don't know, it might take, let's say, a month for them to build it or a week. But while they're working on these designs, I'm actually not pausing. I'm not stopping. I actually have to keep working on the next iterations. If they're working on the version one, I need to keep the creating for version 1. 1. I'm constantly taking on this. That's why it's becoming more important for me to be able to communicate what is the locked version that I want to share with my developer?

Naman Khan: Yeah, that's an excellent point. By having that locked version, the designer can keep working on the next grade iteration, which is part of the design delivery for sure. The second one, is something we think of as inclusive collaboration. What we mean by inclusive collaboration is that at this design delivery phase, as Pelin mentioned, you are bringing together an incredible variety of disciplines. And so they really need a unique workspace for them that spans their different functions. Think about it. It's a workspace where developers are going to need code samples that they're going to put in react code. It's that same place where copywriters are going to come in and need to experiment with UX copy and multiple languages. Those are two pretty distinct functions and you need a place that's inclusive to both of them, where not only can they use that collaborative workspace without training. So it's pretty general, but at the same time, it also has to give them really specific functional output, like code samples, right? That's really key to a design delivery function, is being able to span all of these different needs that come in.

Pelin Kenez: I can also jump here to give some more context on how it looks in a real project. Let's take a login screen. You've logged into this before. I mentioned, I worked at an agency, and that agency I worked on Turkey's largest. e- commerce apps login screen. I worked on a huge bank's login screen. I worked on Lipton's login screen before, and these are all very different companies. These are all very different type of group that I worked with. But one common thing was that whatever the company type of team size of you are in, you have a lot of people that has diverse skills. Let's say for that login screen, your developers needs to understand the layout and identify the react components, let's say that they need to use in that page. And in the meantime, your key engineer is trying to make sure that that screen will behave right in different devices. Your copywriter, at the same time, will need to understand the context first to communicate well with your users. Or let's say they will work on localization of that copies. And again, those are incredibly different functions. Design delivery is all about bringing these people together. Providing them an accessible place or workflow to actually work together, to achieve the results that they are aiming for.

Blake Bartlett: That makes sense to me. I know one thing that I initially thought of, when I thought about the design delivery concept. It made sense to me that designers and developers would be in that equation, and that there needs to be collaboration between those two parties. But spending more time with you all, it's helped me to understand that it's not just designers and developers. But as you mentioned, product managers, UX people, copywriters, QA engineers, the list goes on. And it really creates this need for, as you describe it, inclusive collaboration, which I really resonate with the idea of multidisciplinary collaboration, that it's kind of context for everybody that's involved in this delivery process at all stages of the delivery process as well, which is a combinatorial challenge when it comes to collaboration. But that is where the opportunity is because that's where the pain is.

Naman Khan: Yeah. You know, there are really few examples where such different disciplines have to come together. I think this is really why this sort of developer designer, this whole thing has always been such a big challenge for the industry, which is how do you bring it all together, right? How do you bring all this stuff together? Just making it easy and not requiring training is sort of what we're all about. And then the final step in, just to answer your question, Blake, in design delivery. So we covered finalization, we covered inclusive collaboration. The final one is what we call automation and scale. This is really all about delivering on designs and eliminating all of the duplicate work that goes on without design delivery. A developer today, when they see a design, they may have to code the layout multiple times when they really don't need to. It's probably the same layout, but they don't know that. There is some great progress that the industry is making in design systems to solve this. The issue just is those design systems tend to be in the design phase. They tend to help designers a lot that designers can reuse design elements and not have to duplicate stuff, but it's not moving into the developer world. With a design delivery platform like Zeplin, what we really do is take things like design systems and we extend them into the developer world. So a developer going into a Zeplin workspace will very quickly be able to determine which of these elements that I'm looking at are part of a design system. I will not have to like recode that layout multiple times. And then the final bit of it is just automation. No two organizations build product in the same way. And so just being able to automate that process, we have an open API being able to like connect to tools you already use today. All of that of open platform is also part of design delivery.

Pelin Kenez: Naman, for automation and you mentioned design systems. I have a great example that covering both. Recently, we were talking with a team using Zeplin. This is a little bit specific, but they have a really sophisticated workflow. That's why I wanted to mention. They were actually with those automations, they were getting rid of multiple steps that they were doing previously. What they did was the team used the Zeplin safety IN webhooks. They build a customer flow that maintains their style. Got resources like colors, textiles component in their code base. The way they did it, they know when an asset is updated or edit to their style guide, which is the source of truth for their design system. The automation opens a pull request in GitHub to reflect these changes in their code base. And to me, it actually we are doing the same thing at Zeplin. This is actually really reducing a lot of steps of back and forth and saving a lot of time. I was super impressed by hearing this story.

Naman Khan: I mean, connecting that design from their style guide and design system all the way into like their repo and GitHub, that is really cool stuff, right? That's an example of a use case that you can perform with a design delivery platform. That's the dream, right? Like you design something and it automatically updates code, that's pretty amazing. And so yeah, those are the three pieces, Blake.

Blake Bartlett: So as we think about design delivery, how does Zeplin's product address some of these specific challenges that you've pointed to here?

Naman Khan: Yeah, great question. So there are really four components to how Zeplin addresses design delivery, and I'll go through them really quick. The first one is something we call handoff plus. When people typically think of Zeplin, they do sometimes just think of us as a way to provide technical specifications to developers, and that has become synonymous with handoff. We actually think of it very differently. That's why we call it handoff plus. Handoff plus is really about that finalization of design that we spoke about, right? It provides that source of truth, that crystallized locked version, that the team are super comfortable building upon. And of course, we have tailored specs as part of that, but you know, the tailored specs that we provide are really an outcome of having a finalized design, so that's number one. Number two is something we call multidisciplinary collaboration. This is that inclusivity of different disciplines we spoke about. We have clarity on version history. We have a way you can organize their designs. That all helps making sure that this place where we all come together to ship this thing, it's welcoming to all of us. I don't need training on a design tool. I don't need to do any of these artificial things. The third one is someone we call style guides. This is where we really try to help teams extend their design system. Like that example Pelin gave is exactly what happens here, where you can connect your components from design all the way to code. It's sort of a living the dream moment and that's sort of the third piece. Then finally, we wanted to make sure we are customizable and flexible for every workflow. So we have an API, we have webhooks, we have deep integrations, so you can customize Zeplin to fit your specific workflow. And so these four pieces are really our core value prop. In fact, our engineering team and product team is organized around these four pillars. You know, we're very, very passionate and committed to the design delivery space.

Blake Bartlett: So lastly, let's talk about growth a little bit here. Zeplin, as you mentioned at the beginning, Pelin, leverages a community- driven model that's been very effective for you. So how would you describe your community and who are the members in the community? How do they interact with one another? What do the dynamics look like there?

Pelin Kenez: They are, I can say, mainly product designers and developers, and this group of people they are actually makers. They are living in the building more all the time. They're highly educated. The reason I mentioned that they are makers and they're in the building. Well, they actually know what they want, they know how they want it, and they are also very vocal with these things. They are very vocal with providing product feedback. I think the great thing is how we used it for our growth. Is what's really nice about our communities, that this group, when they find something that they really like, they share it. In general, they trust the experience of their peers rather than what they hear through, let's say, a marketing or a sales resource. In fact, actually the majority of our visitors since the early days, and this is still true today, are people who already know about Zeplin and they already heard about it from the community, then they come to website. That's why I can say that for the specific community, I can for sure say that for them, it's very important what their peers are saying. Not what they see on a, let's say, blog post or whatever.

Blake Bartlett: I liked that idea that I think a lot of times, I even asked the question about community driving growth, which is certainly one aspect of it, the word of mouth kind of amongst the community. But a piece that you mentioned that I hadn't appreciated is the value of community in providing feedback to you from a product development standpoint, product roadmap standpoint. And then being extremely vocal is very helpful to know. Kind of did we hit the mark, did we miss the mark, in terms of what we just shift and where should we be going next?

Pelin Kenez: Blake, I actually even got really wild frames and actual designs from designers. That's the level of feedback that we are actually getting.

Blake Bartlett: That's amazing. The benefit of having designers, specifically in the community, is that they will start doing moonlighting as designers for you. That's great. So how have you, on the growth part specifically, how have you been able to harness and amplify the power of the community to drive the growth piece?

Pelin Kenez: I'll be honest. We don't really have a formal community program. We're just building those. But one thing that we did since the early days, was being very engaged with the community. The way how we did it was the biggest channel was to engage with our community was support. Because we were getting not only issues, but also feedback from these users. And what we were doing is while we are collecting feedback, let's say we edit that feedback to road map. We build it. What we are doing is we were getting back to them saying," Hey, this feature that you mentioned, we actually build it." And not only with them, but on our blog posts, on our tweets, everywhere we were saying that," Hey, this feature that we're releasing now, it actually came from our users," and this is how we actually sold it. And over time, this feedback loop really helped us build very strong relationships with our users. That started to become more sticky. That's the way I can say help us get new users on top of the existing ones.

Blake Bartlett: And in closing, what's your number one piece of advice for a founder or an operator, who's looking to embrace a community driven model?

Pelin Kenez: Okay. This is an ARR one. This is a little bit different for our case. Even we have tens of millions in ARR, we only have all these four million users. We actually never had the revenue goal. We never had the user growth goal, but these are all affected by something else, which was actually our user focus. What we were doing from the early days, that we were talking to users a lot, we were trying to understand the pain points that they're having. Then we were building Zeplin. Having that user focus really led us really then helped us have that user Zeplin love. That then actually lead to path for user growth and revenue growth. We never really had a goal to sell them. We were trying to help them. That would be like being user- focused would be probably the first feedback advice.

Blake Bartlett: No, it's perfect. The way that I kind of internalize that as I hear you say it is, it's kind of focusing on inputs rather than outputs. Outputs is growth and growth is great, but if you only focus on the output, it won't be true and it won't be genuine. It won't be authentic to a community, which in a community driven model, that is what matters. Because like you said, members of a community tend to be pretty aware of if something's marketing or if something's real, and if something is genuine, and is truly human.

Pelin Kenez: Exactly.

Blake Bartlett: And so refocusing that emphasis in community to be about the input, which is really the community member, which is really the user themselves. And if you do that well, and if like you said, Pelin, if the goal is to help, then good things will happen. The output will come, but you got to focus on the right inputs.

Pelin Kenez: Exactly. Yes.

Blake Bartlett: Well, Pelin, Naman, this has been an amazing conversation. Thank you so much for joining us here today on the BUILD podcast.

Pelin Kenez: Thank you, Blake. Thank you. Thank you for having us.

Naman Khan: It's awesome. Thanks for having us, yeah.

Blake Bartlett: Thanks for listening to this episode of BUILD. If you like what you've heard, leave us a review on Apple podcasts and subscribe to stay up- to- date with all the new episodes. Follow me, Blake Bartlett on LinkedIn to join in on the conversation and let me know what you think about the show. Join me this season on BUILD, as we look into the brilliant minds, scaling Slack, Notion, Atlassian, and more to discover what it takes to build an awesome product, and achieve hyper growth across every stage of maturity, from seed to IPO, and beyond. Now, if you're ready, let's build this together. See you next time here on BUILD.