Avi Goldman, founder of Parcel, on the email developer experience

I always knew in that journey that I wanted to start my own company and build the products. At the end of 2019, I started playing with a bunch of different ideas, but I couldn't get the idea of improving the email creation process out of my head. I went back to that learning from 2018, when I was in San Francisco, to look at how do we help people create emails? And to bring the tech from almost arcane to try to modernize it, and bring a lot of the best practices from adjacent industries to email creation.

What was Parcel’s initial product-market fit and who were the core early adopters?

It was the two opposite sides of the world, those are really the people that I got the most interest from. It was folks at Uber, I spoke to the team over there and they thought it was really cool—they had their internal tools to do what we were doing, but they told us they would love to not have to maintain it themselves. 

There was also a ton of agency or freelance interest: people who were doing email creation as their job, running their own agencies, small agencies, who wanted to make their teams more efficient, especially folks who had really talented email developers who weren't comfortable with Git, who were using FTP servers and Dreamweaver in order to sync their creation process.

It was on both ends of the spectrum. The middle was very lukewarm. But it was clear that there was a ton of interest on the sole developer side, a ton of interest on the agency side and a ton of interest on the enterprise side from folks who needed to scale. That's where I saw the initial lift?

Can you talk a bit about the workflow that folks go through with Parcel? If I’m creating an email newsletter in Parcel, let’s say I have a template written up that I copy from week-to-week, changing out the pertinent text, and then that gets copied and pasted into my ESP?

The best way to think about it is very much like Google Docs. If you're writing your marketing copy in Google Docs, you’re sometimes editing the copy in Google Docs and sometimes editing it directly in the marketing platform. 

Then it’s about how often you go back to that template that you're duplicating. Do you want everything to be stored in Google Docs and always copied over, or is it just this one thing, and then you have our template that you duplicate that has the copy filled out and you just fill in the blanks? It really depends on the team's workflow and how they want to use the product. It's very flexible and it's not opinionated, so that's really up to them. If they're using it the, quote unquote, 'ideal' way, then ideally they're creating the emails inside of Parcel and then just hitting export and throwing them into Customer.io.

For each weekly newsletter, they would hit duplicate in Parcel, fill out the content, and export it. What they get with that is they can use all of Parcel’s testing tools, so link validation, image validation, accessibility validation, and make sure it's all good to go there. We have integrated inbox previews so they can actually test to make sure that it's looking correct in all email clients. There's also a kind of QA review, comment, feedback, and approval, where you can send a link and get approvals from your CEO and your team to make sure that you have clear feedback.

You can draw anywhere on the email and say “This needs to be changed.” You can add versioning. Tying that entire process together and having the full history and the full control, if you're fully integrated into Parcel, then you're going to want to do the full creation in Parcel. If you're simply doing a one-off developer handoff, if you're working with an agency and they're building in Parcel, then yeah, they're going to build that template and they're going to hand you the code and then you're going to do whatever you want to do with it, and you're never going to look at Parcel again. It really depends on how much they want to centralize.

What is the core thing that Parcel's code editor does better than Litmus?

When it comes down to the question of the audience, this is interesting. Parcel has always been an email developer-first product. You land on the website and it feels like a developer product. You have a command palette and it's an IDE front, first and forward, and you have a file tree on the left that looks like VS Code. It is a developer product. 

When you're comparing it to Litmus, and that's probably one of our top competitors, it's about the developer experience as a whole. If you're asking for one single thing, you could say it's the auto-complete and integration with the editor. We’re going to highlight the problem messages as you type, and we've got much better code formatting and all the tools that are there.

Or it could be that you really care about the previewing tools and our live preview experience is better. Or it's that we offer ‘inspect element’ and it makes it really easy to jump into code and to get details. Or it's focus mode, where we keep the code in sync with a preview so you're able to stay in line or it can be any number of things. It depends on what that person's pain point really was. 

But I think as a whole, where it comes together, one of the things that came up that was a surprise to me that was a value add, was one customer who cut over from Litmus to us was just auto-save. Parcel automatically saves your work every two seconds. We work very hard not to lose your data. That's something that's super important. Litmus has lost trust with people in that area. So it could be any number of things, but it's overall the developer experience that really puts it to the next level.

In Litmus, you can have a developer go in, code an email, and then within the same product, a marketer can use this very friendly WYSIWYG drag-and-drop to tweak it. Is that kind of end-to-end experience something attractive about Parcel and Customer.io becoming part of the same platform?

That's exactly it. When Parcel was a developer-first and really a developer-only product, it was becoming clearer and clearer that while agencies might function like that, when you get into brands, it's just never the case that people work in isolation.

The best way you support developers is by getting marketers off their back—that’s the way they would talk about it. They're trying to do their job, they're trying to write really good code, they're trying to move ahead with the brand to make sure that everything is up-to-date. They don't want to be bothered with small copy edits—so how do you support marketers to make those edits? When we started to look at that, that's when we built out our component system. 

With the same mental model that React or Vue or Svelte or any component system brings for the web, Parcel is for email. 

You can create a component, you can use that component, and when you compile it, you get the full HTML. But instead of having that full HTML in your source, you just have one line that says, like, “my button,” instead of a table TR, TD, tag styles, etc. What's really cool is—and this is where Parcel can really shine over Litmus if you're trying to build like this—is Litmus has something called Partials, which are basically just ‘find and replace this,’ or just ‘insert this block here’ versus components, which allow you to have full logic and conditionals and passing attributes. 

That's where Parcel can really shine over Litmus when you're starting to talk about scale. The vision with components has always been to allow people to build components completely from scratch, maybe have some built-in, and just put a visual editor on top of them.

If there’s a limited number of options, and there's relationships from parent to children of this is a row and rows have columns and columns have paragraphs and images and buttons, why can't we put a visual editor over that? That was the vision and that was part of what really made it clear that Parcel and Customer.io aligned. 

We can talk about visual editors as a whole in email space, and where we're really trying to push the bounds. But with components, what we're able to get people is that full control. Instead of it being a template that someone coded up once, with components, you just change that brand color once and every single email is up-to-date. 

In the past, if you decided to change your brand and you had to go off and re-export it, and you also had to change every single email. So the developer was going off and doing that. Now, every single one can be changed with just a simple export that will give you the latest and greatest from your component system. That's something that no one else is really doing.

Something that's really big in that vision is being able to do immediate automatic exports to your ESP. That's one of the hard sticking points for that full workflow that we were talking about before, is once you create an email, you still have to manually go off and export it. Even if your component system is fully automated, and every email will automatically get up to date, you still then have to go off and export every single one of those emails and put it in. 

Part of that vision, and part of the area where Customer.io and Parcel fully align is if we have your component system fully integrated in Customer.io, and you update your button and you hit save, instead of manually going off and exporting it like you would have to if you were using Parcel externally, it will propagate to every single email or every single message in the future inside of Customer.io. So that everything is on brand all the time—that's the vision we're building towards.

The beauty of working in email—I tell this to my team every so often—is that we don't have to innovate to be innovators in email. We literally just have to work to bring the tooling up to the rest of the industry. 

Design systems are standard for designers, and they're becoming standard for developers. They're just not standard for email. We just need to take that here. 

If we continue to talk about the roadmap and what's been on the roadmap since day one and is still on the roadmap now, you'll see they're perfect parallels in the developer world or in the design world, in the business world. We're just bringing those exact same principles to email and to email creation, to message creation, really.

What is it about email marketing that demands this developer-focused product? What has led to the need for increased complexity of components? How do you think about the tailwinds here?

That's a good question. Email is cool because the industry is still moving forward after 25 years of email existing. There's still a ton of work to be done and a ton of innovation to be had. The question of “Why now?” is also a little bit of a “Why not now?” question. “Why was this not done before?” is a really interesting question. 

The technology has become really easy, and this is an area where people still get frustrated. There's a ton of opportunity there. The tailwinds of email are also clear. When you make it easy to distribute data and you have a lot of teams that work in silos in those companies, the email creation process also serves a lot better outside of isolated tools. 

Even for Parcel, we were using Customer.io pre-acquisition for our marketing stuff, and we were using SparkPost for our transactional. That's not unique.

Most teams don't have a single tool that does the full job. They're using a CDP to pipe data out. They're using direct integrations, there's a ton of different places that that come from. 

As people's tech stacks become more complicated, there's also value in centralization, at least where you do creation. That's where it becomes really clear that there's a ton of opportunity there. 

As far as the tailwinds of email, there's a ton of investment in it. People are investing more and more as the buzzword-y stuff is like, we have social networks that have become more and more siloed where you don't have guarantee reach to your audience every time Facebook releases an algorithm change, every time Twitter, now X, does something. 

People want to own their own list and own their own audience. That's why we're seeing companies like Beehiiv growing like they are. Email just goes through spurts of growth, and we're in one right now.

You said in 2021 that you were about 3-4% through with your vision for Parcel. Can you talk a bit about your 5-10 year vision for the product and how the world looks different as a result?

The big problems to solve are around streamlining message communication, making every message on brand, and improving communication between companies and their customers. That's the end goal. 

There's a lot of different aspects within that. What we're working on right now is making it easy for marketers to collaborate with developers, keep things on brand, have full multi-brand support, internationalization, all of those things.

Confidence comes from the proper people being involved at the proper time. Part of the complexity of streamlining the review process comes from the complexity of email. “Hey, Gmail just released an update that broke background images this week. Background images in Gmail literally no longer work unless you're using a background attribute.”

Imagine if Facebook broke and they didn't know about it until users reported it? That's what happens in email all the time.

One of the big things we can do is introduce automated testing for email. Can we make it so that we'll check your emails once a day or once a month or once X period and allow you to just move confidently and not worry about that sort of complexity? Why is manual testing still the industry standard? Why aren't there automated tools to just do this in the background?

There's also personalization. How do we make it easy to use personalization? How do we make it easy to have multiple variants? How do we tie into the journeys, like building a journey and having the content be very contextual to that person's step in the journey, and have it different from A to B to C? There's so many more steps to nail down. 

We've done a really good job of solving for the developer aspect of creation, and what we're looking at next is the marketing, design, and copywriting aspects of creation.

Can you talk more about the potential for Parcel to help email developers even if they’re doing their coding in a tool that’s not Parcel?

This has been an interesting challenge. We do want to solve for marketers, but Parcel still needs to keep its developer roots, and we need to continue to serve that audience. 

The reality is email developers are comfortable in Parcel, but we have a lot of software engineers who are interested in the same tools, who don't want to use a cloud-based IDE. There are email developers who do web development too, and so for them changing tooling just to get X, Y, and Z features might not be enough. That's where it's become very clear, and we've had this on our minds for a year-plus now that we need a VS Code extension. We need to integrate with a software engineering developer like experience and developer workflow.

If we can nail down a marketer's editing experience, a copywriter's editing experience, the feedback loop, and the email developer in the center of Parcel comfortably, and a software engineer being able to stay in their tool set and push into Parcel, then Parcel becomes that central location. 

Marketers are going into Parcel to edit, but software engineers can use those same components and commit their changes to Git so that they're using SparkPost and it's just directly in the code base, and push those changes up to Parcel so that the marketers get the benefits of whatever the developers have recently changed. If we can nail down that, then we'll have succeeded in bringing the entire team together. Then it's just about continuing to layer and make those other pieces easier. But that's definitely something that’s on our mind, and it's just time and bandwidth. We really want to get to that at some point soon.

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.