Courtney Scharff, manager of marketing ops at Figma, on Figma's marketing operations stack

Actually, I think we were a pretty early customer, especially for the size of our company at the time. The guy who started it, Avi, we worked really closely with him—we'd have Zoom chats with him and we had a Slack channel to give him feedback. We weren't a beta customer, necessarily, but it kind of felt like that. We would share feedback about what would be helpful or ask him questions in Slack. That was the early days of using Parcel, and now the two people on my team are also using it.

Is there a threshold of usage where the lack of ‘enterprise features’ like SOC-2 would come up at Figma if it was a large enough number of people using the tool?

It hasn't come up yet. It probably will at some point in the future, but there are other marketing tools that we use that, at least for single sign-on, they don't have it or we don't use it, for example, Marketo. For us, because it's still such a small team using it, it just hasn't really come up yet. There might in the future be some audit of our systems and it could come up then. That's where things like this came up at my previous company, because when I joined GitHub it was not a huge company either. It wasn’t a small company, but people were still able to sign up for various tools on their own. As long as there was some security in place, it was fine. 

But then, as we became a much bigger company, the legal team or security needed a list of every single piece of software that we used. And if it didn't meet certain security requirements, we'd have to do an audit and see how business critical it was and all of that. So it hasn't come up yet, but I think it's something that probably will come up. It's probably a byproduct of the fact that we're still a really small email team. It's not hundreds of people in there, it's literally three to four people at most, and I don't actually see my team growing a ton in the next year or two.

Since adopting Parcel, have you looked at other tools like Litmus?

We actually also use Litmus. For me, I never would put it in the same category as Parcel, because Litmus was very much like an email preview tool. I've used Litmus for a long time now, I used it at my last company as well. I wouldn't go there to collaborate on code or anything like that. You could do that, but it's not a code editor built for email, it's an email preview tool where you can edit code. Whereas Parcel, when we had originally started using it, there was no email inbox preview function, and so we kept Litmus, because we still needed that, and we only really need that when we're creating new templates. Most of the time we're using existing templates and layouts, and we don't actually need that inbox preview functionality that Litmus offers, that's why we wouldn't use it for that use case. 

The reason we have Litmus is because when I first started at Figma our team owned marketing email as well as transactional email. We were just too busy and it didn't make a ton of sense, so the product and engineering team now owns transactional emails. If they make a major update to layouts, they're going to use Litmus to test that. Whereas, I guess we could have them in Parcel, but it's kind of a mix of two different types of emails that are completely unrelated. I don't really know that we would need a bunch of product and engineering people in Parcel testing emails. We do use Litmus, but to answer your question in a more succinct way, we haven't looked at other tools to replace Parcel. We've been generally really happy with it. It meets most of our needs, and I think we're still not even using all of the features on the Business plan.

Does it boil down to just those folks are used to using Litmus? It has the preview function, which Parcel has a preview function, but is it inferior to Litmus'?

It's not, it's a different space for them to use. Yeah, it's just nice they just have a different space and we could create a workspace. Another thing that we liked about Litmus is that you can share a login and you can't do that with Parcel. We would need to add another seat for every single engineering person that needed to use it, and it doesn't make sense.

Do you still use Atom or another IDE for stuff, or anything that touches code you can do in Parcel?

Correct. I actually recently got a new computer and I don't even have Atom on it. I can do everything in Parcel.

It sounds like you guys handle a lot of requests for emails from different teams on different projects. Do you make use of the components and stuff like that in Parcel as a way of dealing with lots of different kinds of emails going out? I'm curious about the workflow around that.

We probably need to do more there, this is something that my team and I have talked about quite a bit, we've done a little bit with the components, but not a ton, to be honest. The workflow is that we have all of our different email types in folders that are related to the different types of requests that we get, and then we usually just duplicate a file and replace the content. But again, it's more we haven't been able to spend the time to sit down and be like, ‘okay, these are the components I need.’ Also, part of that is that I need to create some documentation for how to use these and where they are for my team. I think the components are really cool, and we could be doing more with them, but we don't use them a ton. We're more duplicating files and replacing content.

We don't have a ton of different templates, maybe six to eight core templates that we would be using. So for example, sending an email for an event follow-up, we just can go to our events folder and see the most recent one that we did, go in and replace the content. It already isn’t super slow. I think for me to build an entirely new email with an existing template, five minutes maybe to build it and then a few more minutes to check the links and do all that. For me, the components would be nice, but it would be an incremental amount of time saved, and I’d have to spend this time upfront to create them.

Some other folks I've talked to raised the idea of if they didn't have access to Parcel, what they might do is basically have a GitHub repo for all of their email templates, just to have version control and not just have a folder full of HTML files, and train the team in the basics of Git and have them run it like that. How convinced are you that that could be a suitable replacement for what you're using Parcel for now? Would that be what you might do if Parcel didn't exist?

That's exactly what we did when I worked at GitHub, which makes sense. It was a really cool process and it was based on the idea of components. Essentially what we did there was we had a GitHub repo for all of our emails, and essentially to build a new email, you would create a new markdown file, it would have some metadata in it, so you could do the preview text. This was so long ago now, but it had some bits up top that would then be used to generate the email, and it was just a really basic markdown file. There's some HTML break the paragraph type of thing.

You would create that, and then we had this internally built preview tool, that would run locally on your machine, so you could preview the changes live, similar to Parcel. Every time you would save it, it would be regenerating the full HTML file. It would add all of the styling and CSS, and then it would add all of the HTML tags and do all of the inline styling for the paragraphs and stuff. It was really cool actually, because what that enabled us to do was, if we needed to make an update to the CSS of our emails, we could just do it in one file versus other ones. That was really cool, and again, that was all built internally by people who work at GitHub, so there were just a lot of cool parts about it that I didn't really know how they worked, but they worked. That was great.

At that time, something like Parcel didn’t exist and there were collaborative code editors, but not ones built for email. Given a choice today, I don't think I would want to go back to that, because Git can be really frustrating, and sometimes getting all that stuff to run on your machine can be really challenging and frustrating. It just relies on a lot of other things to be working and packages to be updated. That was always a thing, but it was cool in the sense that it still had that component feature. But I think I would still choose Parcel.

Also, one of the things that I think is really cool, especially as a manager and people on my team, is all of the hover states within code that give you background and details on why that's important for email—the accessibility checker, the light mode, dark mode preview without even doing the inbox previews. All of that is much more than I had in this GitHub thing. What could be cool is something automated that just was a backup of all the emails in Parcel to GitHub. I don't know if a server went down or something, but something that's automated and I wouldn't have to train people on my team to run Git and do all of that, and have command line tools installed and all that.

If you have a wishlist of features, what other stuff is on there, stuff that would be useful for you?

Ok, so number one, I know that Parcel got acquired by Customer.io, so I understand that. One thing is being able to sync the live HTML to Marketo automatically. That's a big one, just because we send all of our test emails from Marketo and not from Parcel, and there's a couple of reasons for that. It doesn't really make sense for us to update. In Parcel, you can say this is the subject line, whatever, all of that stuff, but we don't really need to put the subject line in Parcel, because we need to put it in Marketo, and it's nice to have that be where we test from. So it would replace the need for us to be constantly like if we make an update, copy and paste the code over into Marketo. That's number one.

I think the inbox previews are great. I actually really like the idea of getting an early round of feedback through Parcel versus Marketo, again, because sometimes we just need to send an initial thing and we want people to look at it just in the browser, they don't necessarily need to see the email in their inbox. The use case for this is not the standard emails that we send that usually don't have a lot of changes, but if we're working on a major product launch where we have tons of people, it's nice to have people have comments and things like that.

Oh, I have a big one, actually. Automated version control, there's none of that. Even for the feedback, what I really want is this to update to the most recent version automatically, and then I also want to be able to see version history and go back to a previous state without creating a new version manually. We never ever do that, ever. So for us, it's like, oh, we can undo up to a certain point, but if we went and did something else and came back, there's no backup. That's the biggest one and that's also related to the feedback functionality—I don't necessarily want to create a new version every time I'm asking for feedback. Then if a reviewer is coming and someone previously made some feedback and then we changed it, that person is now seeing the outdated version. 

That creates like, ‘oh, well, this doesn't sound good.’ I'm like, ‘oh, we actually changed it, sorry.’ It's just extra work. So I think that's the big thing, and then there's just been some bugs too, to be honest. Sometimes things just don't work as expected, and so those are the two big ones, I think.

Does the prospect of having Parcel integrated more deeply into your ESP, is that attractive or something you would want to try?

It's a nice-to-have, it's not a need-to-have. It would be cool, but I don't think it would drive the decision to pick one ESP over another.

You mentioned your team that uses Parcel is around four people. Is Marketo used by many more, or is it pretty much the same four of you?

Pretty much the same. We have some people that use it on a reporting basis, so they're just like, ‘oh, I want to see some email data,’ or something. But generally, and then there's some other people on the marketing ops team, which is my core team, that would be using it for lead processing types of things or operational programs. But it's still a pretty small group.

Out of curiosity, are the folks coming in and who you're onboarding—to what degree are they technical?

As part of the interview process for someone on my team, they're actually doing a code exercise, so they’re coming in with some level of that. I would say that everyone's level of comfort with updating existing templates is really solid, and they have a really solid understanding of HTML and some basic CSS. But the level of knowledge, if we had to create a new thing with different types of layout and functionality, isn’t as advanced for people on my team, but definitely on the more technical side. It's not like someone's coming in who's never worked in HTML and doing that. I actually did have one contractor who they had been positioned as someone who had this technical expertise, so I was like, ‘great.’ They didn’t and that was a train wreck, and they were in Parcel trying to update stuff and it was horrible. So yeah, definitely the people on my team have that technical access.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.