A little while back Mailchimp approached Postlight for some help. They wanted to improve their developer experience and rebrand their APIs. This week we are joined by two Postlight employees, Liz Tan and Adam Pash, who helped make that happen. They share their reflections on the process and talk about what it was like doing design and content strategy for such a well known and beloved company.
Liz Tan This should be also the part where we say Paul invented that term.
Paul Ford No! [Liz laughs] No, we don’t talk about that anymore. Agh!
Rich Ziade We should let everyone listening to the podcast know that Paul Ford invented the term ‘content strategy’. [music ramps up, plays alone for 15 seconds, fades out]
PF Oh, my goodness, Rich. It’s my favorite kind of episode. You know why?
RZ ‘Cause I’m joining you as co host?
PF No… that I just take for granted at this point, maybe I shouldn’t. Maybe I should celebrate that. But we have guests from the company here to talk about work they did. You know why I love that?
PF Tell me.
PF They have to be nice to me. It’s just fantastic. It’s the best kind of guests.
RZ I wouldn’t get ahead of ourselves here, Paul, let’s see how this goes.
PF No, frankly, history has shown that that is not actually a requirement of work at Postlight. Nor is it, does it impinge on your success [Rich laughs] if you tell the co founders that they they completely need to shut up. No, it really doesn’t. I’m hearing there’s, it’s we get disagreed with a lot. Maybe that’ll happen on today’s show when we talk to Adam Pash and Liz Tan. Hello, Adam Pash and Liz Tan!
Adam Pash Hello, Paul Ford and Rich Ziade!
LT Hello, hello!
PF Adam then Liz, tell the people what your title is and what you do at Postlight.
AP Yeah, my name is Adam Pash. I am a partner and Director of Digital Strategy here at Postlight.
LT I am Liz Tan, and I am a Lead Product Designer at Postlight.
PF We don’t do this often enough, we’re going to talk about work we did. We’re going to talk about the work we did for Mailchimp. There’s a case study on our website, there’s all sorts of good stuff. Take it back for one second. Richard you—one day Mailchimp called. And you did the most of the talking. What did they say? What did they want?
RZ Well, you know, it’s it’s actually our favorite kind of starting point, where they said, ”This isn’t good.”
PF Not about us! Not about Postlight.
RZ No, not about us. Mailchimp is a wildly successful company. I don’t think I need to describe what Mailchimp is to anyone listening to this podcast.
PF Frankly, normally we explain everything. But to podcast listeners, you do not have to define what Mailchimp is. [Paul & Rich chuckle]
RZ Yes, that’s right. That’s right. And they said, ”Look, you know, we’ve killed it with small business owners, medium sized businesses and whatnot. We have a platform, we have an API, and we want to reengage” and hard stop. They had ideas, there was a memo if I recall correctly, but there was a lot of ambiguity around it. And so we gave it shape. We flew down to Atlanta to Mailchimp headquarters and we pitch them what we do over six months. And look, full disclosure, we even said in that meeting, we said, ”Look, here’s where we’re generally going to take you, we’re going to aim for this continent, but there’s a lot that’s going to be defined as we go, there’s a lot that’s going to be figured out as we go in terms of what we’re committing to, and what we deliver for you guys.” And I think that kind of ambiguity, which is really founded in a level of trust, and goodwill, you have to build with a client is I think, why this project was such a big success.
PF What I remember, in addition to being really excited to get work with Mailchimp, which is a hell of a platform, everybody came back with lots of monkey related swag, so.
RZ They were very, it didn’t feel like you were going there and they were kind of sizing you up. And eyeing you up and down to see if they wanted to hire you. It was—they were just great. They immediately killed that sort of client vendor pitch dynamic out of the gate. So it just was very warm. And I’m just glad we got the chance to do it. And now we we’ve built this relationship with them. So.
PF Okay, so now we land the work. And it has to get done and actually I’ll start with Adam. Adam, can you describe what we were supposed to do?
AP To set the stage a little bit, Mailchimp is, I know, they don’t need introduction, but they’re an email marketing platform. But they don’t just do that. That’s mailchimp.com. They also have a transactional email platform, which is typically the kind of thing that a developer reaches for when they want to send sort of like one off event triggered emails. Say I have a password reset notification in my application or you know, any sort of like small, again, transactional email kind of describes it. And they had these two different things. And they were they’re totally disparate experiences didn’t live together. One was called Mandrill at the time. Mandrill was kind of beloved among developers for a while and then it kind of got left and staredt collecting some dust on the shelves of Mailchimp. And they wanted to bring Mandrill more into the fold, and wanted to unite these two experiences with the Mailchimp developer for the marketing API and this transactional API. And so we were kind of setting out to do that work, to figure out how we do the content strategy to bring that stuff under one umbrella, sort of folded into the Mailchimp brand and update a lot of really kind of like out of date content that’s lived across all sorts of channels in the Mailchimp universe.
PF Let me point over to Liz, and go, ”Liz, I mean, developers, they’re like animals, they’ll read whatever you give them some API docs [Rich laughs] in a text document. They don’t deserve any better than that. In fact, I’ve seen API docs all over the internet, they’re garbage, who cares?”
RZ Just to highlight that we are recruiting so they’re very cute animals. [Rich & Paul laugh]
PF That’s right. That’s right.
RZ Fluffy, cute, animals.
PF You know, let me, let me just be—I understand this is like a technical writing project, we might have to update our code. Why don’t we need design on this? [Paul laughs]
LT I mean, it’s user experience, right? Developers are users. And so there’s a lot to consider there. I think part of this work was also to establish trust, again, with the developer community. So as Adam was talking about the Mandrill, getting kind of collecting dust, like it, it also made, some developers feel kind of left behind and uncared for. So to build trust is not just to—you know definitely need to fix the content and make the actual, you know, the stuff good. But we also need to give it a nice wrapper to really like signal that.
PF So interesting. So respect is a big thing that you’re talking about here, like we want to show respect to this audience. And we need good design to do that.
AP Yeah. And to expand on that the, you know, Mailchimp is, as you said, enormously successful, but they have competitors. And those competitors were kind of like aimed a lot at the developer community. And that community, once they get engaged in the platform is like, very engaged in it, they buy into it, they stick with it, they spend money there. So it was important, from a business perspective to get those, to reengage with those engineers.
PF Because that’s how you get lock in. Because when the engineer says, ”No, I’d really rather go with platform X” what are you gonna do? You’re gonna say, yes,
RZ If you want to hear a passionate counter argument, tell a developer not to use their technology of their choice, and to just use the other one that’s about two years older. And you know, what you’re doing here in a lot of ways, A, yeah, it’s a tool, it’s, it’s a reference point, you can look up stuff. But really, you’re creating an environment where evangelists can take hold, and actually sell your product for you. Developers are very passionate when they lock in on a platform. Which leads me to a question here, I guess, for both of you. To me, when I think about developers, there is the person that just wants to go right to the docks, they don’t want a story. They don’t want a case study, they know what to do. They just they like to pick up and run. And then there is the developer that is, you know, the API is pretty elegant. You don’t really need to be a hardcore developer. How do you, you know, entice that user in? Like, to me that’s distinct. There’s the pro just likes to play and just immediately brings it, you know, right into their IDE and just wants the code. And then there’s the person that’s like, ”Is this the right tool? Is this the way I should go?” And so talk a little bit about how do you reconcile those two things and affect the pro hardcore user and the the sort of more casual is this the right fit for me?
AP Yeah, so I mean, from a top level, when you come into the site, you know, and you’re evaluating services, you’re just looking at what they look like, you know, are these look like up to date, do these look modern, whatever, you know. But then when you when you want to address those individual users, obviously, the docs person is going to dive into the API reference, right. And same thing you want like a modern best in class API reference that really just sort of like, lets you get into the nitty gritty. For Mailchimp, specifically, we created tools for, you know, four or five different languages that then you get code snippets alongside of the API reference. So it’s really easy, it’s sort of that starts to address both users because it’s just a copy and paste. But to address the less experienced user, the big thing that we did from a content strategy perspective, was we wrote a lot of guides, and the guides were really sort of the context setting that says like, ”Here’s what you use this thing for here are examples of uses. And here, we’re going to walk you through. Like you’re chat app for vegetarians, called Chattaouille—which is a real example we have in one. Here’s sort of like how you would integrate this thing into your into your workflow.” So it really kind of like holds your hand in the process and sort of introduces you both to the product and the use cases of that product. And alongside working code, you can copy and paste into your app and sort of modify to your needs.
PF So obviously, we’re not doing this in a vacuum. In fact, we’re providing a service to our client, right? Let’s talk about that for one second. What is the Mailchimp team like on the other side and how is this working together?
RZ As an outsider who was getting, I think it was weekly or every other week, check-ins. The Mailchimp team did something really impressive at Postlight. And it was, and it’s, it’s going to sound conflicting, but they they balanced it really well. One was, they drove, they literally were like, ”Listen, the 11:08am train is going to leave, if you’ve got thoughts and feedback, let us know.” Right? Which is—
PF That’s why they hired us. Like, that’s the tricky part.
RZ Partly why they hired us. That’s right. That’s right.
PF We were brought in to truly get something done. And we have good partners on the other side, they were good listeners, they gave feedback, and they never got in the way of us shipping, which can happen with clients. Like Mailchimp, on the other hand, was very much like, ”Absolutely, get it across the line.” Maybe ’cause they’re a software firm, and they understood like, ”We got to launch, otherwise, we can’t ever really start.”
RZ I think that’s right. I mean, there were—correct me if I’m wrong, guys. But the audience grew over time, there were more people attending meetings, as the meetings, it’s like, ”Hey, guys, the Postlight team is doing some interesting stuff, you should come give your two cents.”
PF That’s always the sign of a successful project.
RZ It i! But it is also, has the potential to derail a project, right? That really loud person that shows up and you know, bless their hearts. But the train is supposed to leave on time, we have committed—Postlight is very much value driven rather than time driven. We don’t want to drag it out, which a lot of agencies don’t mind dragging things out, we actually wanted to get the work done. So talk to me about balancing that out. I know Liz, you saw some of this, as you were getting design feedback. The trains leaving, but we’d love to hear your thoughts. [Rich laughs] Right? So those two phrases are attention that crops up again and again, in engagements. How did that play out for you guys? Think of it from an advice perspective, what can you share for designers—they don’t even have to be at an agency, it could be an internal design team at any company—that is dealing with that kind of tension?
LT I mean, I guess I’d start by saying that the clients were pretty clear about what they want. And we had a really great kickoff, where, you know, we talked to all the stakeholders, we understood what the problem space was. And on the other side of it, we got a lot of trust from our clients to do the work. At every meeting, they called us the subject matter experts, you know, they they wanted us to bring the answers to them, and help them solve this problem. And they were great partners in that they were the type of partners who cleared the path for us internally for us to do the work.
RZ Did you have an advocate or a couple of advocates that were clearly on our side in terms of like reducing the static as it was moving along?
LT Yeah, most definitely. That was instrumental to the success of the project.
AP Yeah, I can expand on all of that. So we had three tracks of work on this project, we have engineering, we have content strategy, we have product design. And that’s a lot of work going on at any given time. And we have to like communicate that work back to the client. So we had these bi-weekly presentations. And these weren’t just like, you know, ”Hey, here’s what we did last week.” These were like presentations, where it was like, we were sort of both selling and showing like, ”This is what we’re doing. This is your chance, as you said, like the trains leaving the station, this is your chance to say yay or nay on this to weigh in. Otherwise, we’re moving ahead to the next time.” And because I think of that urgency that was created by these meetings, the meetings grew, like, as you said, more and more people started showing up, which then also meant that every time we did another one of these meetings, we were setting the stage yet again, like ”Here’s what we’re here for, here’s what we’re doing,” because people were there who hadn’t seen it before who didn’t really know. And we’d made the mistake early on of not doing that. And then those meetings would get derailed instantly by someone being like, ”Hey, what what’s going on here?” And you’d be like, ”Oh, yeah, well, last meeting. Yeah. Okay. You weren’t there. Okay, let’s, let’s—”
PF ”This is more of a comment than a question…”
AP Yeah, yeah, yeah!
RZ You know what it’s like, it’s kind of like ”in last week’s episode of blah, blah, blah” and it catches you up real quick, because you don’t know who—
AP Every track would start with last week’s recap.
LT It actually, it ended up working to our advantage, because it meant that even the people who have been in the room from day one, know that, you know, what’s the goal here for today? You know, what have we done already, and we continue to take them along on that journey, without them having to be like, ”What did we do last week? What do we do the week before?” Or you know, talk about like decisions that we’ve made last week, and it just sort of dives people right into the work.
RZ Just last thought here, people are busy. A lot of times, this is the thing they get to come and check out. They have no idea what’s been going on, you’re sort of saying, ”Good to have you here.” The owners of the effort, the real stakeholders that think about it a lot, that’s different. But a lot of people visit an effort and just sit in to sort of give their two cents and they don’t know the context. So I think it’s, it’s useful to have.
PF So Liz, you walk in. And you have a very famous monkey [Liz chuckles] it’s an extremely famous monkey and a very nerdy audience that I think you know, Adam, Rich and I are all part of so, I think it’s fine to throw us under the bus a little bit like a very specific audience, they need a lot of focus. They care about deep things about things like dark mode matter about as much to them as maybe the presidential election does. And so here we are, Liz, here’s your monkey. Here’s the developers. It’s a pretty formidable brand, also bright and positive brand. So where do you get started? How do you negotiate that to build a product like this?
LT Research, always going back to, you know, talking to the users talking to developers, we interviewed developers, we talked to all of our wonderful Postlight engineers in house, lots of opinions, I’ll tell you that.
PF They’re all wonderful. They’re very opinionated. So opinionated.
RZ Wonderful animals. Let’s keep up with the theme. [Liz chuckles]
PF That’s right.
LT And then we also talk to Mailchimp engineers internally, what do they want their brand to be? You know, they’re the real, like ambassadors of the developer community of Mailchimp. So we talked a lot about what do we have now? What is the future vision? What do they wish this thing was? And from there, we moved, we moved to figure out what to do with this thing.
RZ Was there like, you know, brand police, like, you know, brand compliance document, you you know, the kerning on the font is not acceptable? Like, did you get any of that? Which I, look, that’s, I’m making it sound really negative. But a lot of people are very protective of their brands. And it’s understandable, in some cases.
LT They have a really strong brand. And I think it makes sense to protect that brand at any cost, and make sure that it’s consistent with what they’re trying to do it. A brand like that doesn’t happen overnight, you know, it’s many years in the making. So I always have, like, a lot of respect, coming into projects like this, to follow their guidelines to, like, you know, we’re an agency, a lot of our work is just to help them, you know, get to the next level, but we’re not here to like, gut their systems, you know, we’re not here to like start over.
AP At the same time, what you end up with, when when Liz is doing that work is something that like, looks like Mailchimp, but for developers, right, so like, it has that brand identity of Mailchimp, but so like, I’m a developer, I land on that page. I know I’m at the developer page for Mailchimp, versus Mailchimp.com, which is a different audience. And like, early on in this process, I think one of the most powerful videos that came out of Liz and her team’s research was a video of a Postlight engineer, trying to find the developer documentation on mailchimp.com. He was looking at it, and he did not know he was on it. And he started clicking all over the site. And this like one artifact, this one video became like a really powerful tool in any meeting to sort of orient people around the goals of this project, which was just like, there is a problem here. And like, it’s, it’s very straightforward. Someone is at the place they’re supposed to be and they don’t realize it.
RZ Postlight’s success is determined by the relationships, we’re able to build beyond the projects they hire us for. We’re excited to continue to do work for Mailchimp. And we’ve built that relationship and built that goodwill. And that makes it way easier for quote unquote, sales, right? We don’t have to go back in and re pitch because we’ve built goodwill, and we’ve built trust. What’s the advice you would give to teams that, frankly, are constantly pitching other teams, even outside of the agency context, because there are departments in big companies that are doing this. And what I watched happen is little by little, we kept gaining trust. And this is sounding like just the most smooth sailing rosy start, but there are bumps right? And so what are you know, how did you meet those challenges when there was friction as you’re going through it?
PF And in specific, right, like, like engineering kind of tends to sell itself. But here we’re talking about the value of content and design. So you really have to show, you can’t tell. So talking about that, right? Like, how did you build consensus around our editorial strategy and our design strategy?
AP You know, it’s it’s a lot of what you end up with, when you need to convince people that that they need new content, new content strategy, a new approach to how they do content, is you need examples, like you need to be able to show them like, here, here’s some weaknesses of what we have right now. I mean, the whole content strategy thing, right, it’s up to you do this giant content audit, where you just understand every piece of content that they put out in the world.
RZ Take 45 seconds and define content strategy.
AP So content strategy—and I’ll sort of use Mailchimp as an example to ground it. It’s about understanding all the digital content that they have. And they’re putting out into the world specifically, in this case around their developer content, doing a full content audit so you really wrap your head around that and inventory of what they have. And then you start looking at at what goals are you actually trying to achieve with this content, how the content is succeeding and failing at meeting those goals and then starting to make recommendations for like, okay, what what do we actually want to do going forward? What makes sense? What will what will best achieve those goals, and that includes doing a lot of research into what other people are doing well when they’re trying to solve those problems and sort of incorporating all of that into a series of recommendations for, for how that content strategy should work going forward.
RZ Liz, a lot of what Adam just said—here’s it, I mean, outsider sounds like design.
LT And honestly, we went down the same path, you know, we did a lot of research of auditing what they currently have on the developer website. We, you know, take a look at what other competitors are doing. A ot of our our work, too had to do with convincing Mailchimp that this needed to feel distinctly for developers, which meant that it couldn’t look just like mailchimp.com. That was a big thing that we needed to fix.
AP And it actually it is, there’s a lot of overlap. And there was a lot of collaboration between the design team and the content team with this. And in fact, in some organizations, I think content is joining sort of the design as part of their their org.
PF No, that’s right, Facebook, they have taken, I think they’re renaming content strategy to content design.
RZ This highlights a great—I mean, a key point is, you know, I always as a product manager, I used to be a product manager in my past life. I always fear what I call the empty shell problem, which is a lot too much design without content. And without real data coming in, whether it’s an application and whatnot, yes, you can pour, you know, Lorem, ipsum, into whatever, it doesn’t do justice to what you’re trying to solve for most of the time. And I wonder, is this something we’re seeing more broadly as a trend where content is almost sitting next to design, as you think about design?
LT I think content is always next to design, I’ve never been successful in a project where we’re just designing in a vacuum. I mean, same goes to engineering, we always need all three of these pillars next to each other to be able to do this successfully. And specifically for this project, like from day one, this is a content lead experience. I mean, if you look at the site there, there is certainly design and there’s design beyond just you know, what you just see, it’s beyond the colors, beyond the font, but without the words like this website would be empty.
RZ Sure. We don’t have engineering here, Paul Ford. Paul, there was an engineering track as well. And they did some really, really great work.
PF We built out API libraries that people could easily plug in, right, like that’s, that’s such a big part of the step.
RZ Lower the barrier, yep.
PF Something wild and almost hilariously relevant to this just happened, which is somebody wrote in to tell us about some challenges that they have reading our newsletter, which is exactly the kind of feedback that you expect to get. And they wrote a PS—this is someone named Adam—wrote ”PS, thanks for the updated Mailchimp Dev docs and API libraries” I swear to God, this came in at 1:18pm. It’s 1:36 right now, ”As a longtime Mailchimp API user, this is a welcome development and perfect timing as a migrating a large audience from an enterprise publishing data platform to custom database app that integrates with more modern services like Mailchimp.” So literally—[Paul laughs]
RZ There you go!
PF The level of integrated brand marketing things happening right now is, is more than I’ve ever seen in my lifetime. Look, you know, as I’m listening to this, I’m hearing a few specific things that are, that are really important, which is one, designing content, living together with engineering, but but really living together and working together. And sort of using the same process. Two, a lot of research driven and not researching as much quantifiable as much as storytelling that you can use to get buy in, over the life of the project. So like, why are we here? Well, let me show you this very short video in which an engineer truly can’t, you know, get, get what they need. And so we’re here to solve that and move it forward. And you know, we did a good job, we literally got an unsolicited email about the job we did, which is a hell of a thing, like, very proud of that. So those two lessons really stuck out in my head.
RZ Yeah, I think I would add one more. You know, user research is is like, ”We should learn how users work.” And there’s another benefit, oftentimes unintended, to going and talking to people. And that is it creates alliances, it creates a connection so that when you do hit some friction, you’ve got people that felt heard, and can connect to what you’re doing and will defend you. I’m kind of wading into sort of the political side of things. But this is meaningful for us. When you’re able to build that goodwill on the floor. It tends to ease stress later on, as you get into, you know, sign offs and big decisions that you know, have to have to be made for the next phase.
PF Political goals are great if you achieve them by doing the work.
RZ Absolutely, absolutely. This isn’t manipulation. It’s just people feeling heard.
PF That’s right. ”I proved that this could work. Therefore, we should do more of it.” That is a completely fine case for anyone to make. Download our new white paper Catalyst. It’s all about that!
RZ I’ve been in that meeting. Everybody on this podcast has been in that meeting, where someone shows up, you’re not sure why they’re there, but they were invited or added on because someone felt it would be important. And they take a posture that’s almost defensive because they’re feeling like why is this the first time I’m seeing this? And it’s, it’s I’ve seen that way too many times. It’s no one’s fault. You can’t canvass an entire company to make sure everyone’s heard. But it speaks to how much people value being heard and listened to, as you’re going through this process. I think it goes beyond just gathering good design feedback, but it goes it goes into something deeper. It’s worth noting, we’re continue to do work with our friends at Mailchimp. I mean, this was a success at all levels, content design, product management, engineering. They’re a great partner. Let’s just say it out loud. You can still do great work and have an okay partner. They’ve been a really great partner for us. But I mean, look not to take away, I mean, you guys did, you killed it. I mean, congratulations on this effort.
PF It’s also worth noting, there’s an article—if you go to our website, and you look up Liz Tan— Liz did this work with a baby literally on her knee as the pandemic exploded.
RZ God, that’s a cute baby though. [Paul laughs]
PF It is a cute baby! We won’t, we won’t say her name because she even has a cute name. We will we will protect her identity here on the podcast. Ouff.
RZ But wait till, wait till Mailchimp finds out we’re billing for that baby. [Liz & Rich laugh]
PF That’s right. That’s right. It’s actually, it’s a, it’s a great article about the complexities of leading and doing your job and moving forward, getting promoted in the middle of truly a global catastrophe. [Rich laughs] So, great work, everybody!
RZ There’s the title for your How To book.
PF That’s right, we’ll put a link in the show notes. No, it’s great work. It was a it was a long project. It was a hard project. And we were hired because it would be a long, hard thing to get done. And it’s great that we’re still working with them. They’ve been a great partner too, we’ve been very lucky.
RZ Guys come back on the podcast again soon.
PF Anytime you want!
AP Our pleasure. [Adam chuckles]
LT Thank you!
RZ Alright. Thank you guys.
PF Alright, so Rich, that really was a little uncanny that I received a completely appropriate email, but also happen to come from another Adam, which is interesting.
RZ Also uncanny.
PF We’re not going to dig into that for—
RZ No, no. They did great work. We’re really, really proud of this work. You can check out the case study and the backstory at Postlight.com. [music fades in] We waded into some new waters with it, and we just stepped up and just killed it.
PF I feel that way too. I feel that this this is just a lovely piece of work. And it looks great too. Like I know it sounds—it’s not something people think about, this is to me, like when design really matters, it’s an environment in which people don’t tend to celebrate design.
PF Like redesigning Vogue, you know, like let’s say we’re gonna give you the whole magnetic pole position, world class designers, working hard, you know, Conde Nast, etc. But caring enough about the developers who are like trying to get the website up that allows for easy signup for like the local charity or the person who makes the the potpourri and they want to sell it, like serving them really well, is the good stuff. I like that a lot. Thank you to Adam and Liz for coming on. We’ll put some show notes in and check out the case study on our website. This is probably the purest expression of this podcast as a marketing product but also very true about what we do and what we care about. So.
RZ Some good lessons learned there. [Paul chuckles] No apologies.
PF No apologies! No, no. I hope you enjoy.
RZ Have a great week.
PF Bye! [music ramps up, plays alone for 3 seconds, ends]