Mark Robbins, software engineer at Customer.io, on the email coding stack

Parcel came out subsequently and that's how I first started using it. It was just like, "Cool, here's a code window, here's a preview of the email," and I can send it to multiple accounts. It's really quick, really easy. So I started doing that a lot. 

The other thing I was using it for as well is just experimenting and saving little experimental bits of code that I was playing around with.

Previously, and to an extent even now, I still use CodePen for that. Going onto CodePen, I create a new pen, play around with some code. It’s like, "Does this work?" and then I save it there. I started moving things that were more email-related over to Parcel because then I could send a test out and it was just quicker and easier. 

Also, things like the code formatting. In email, there's various annoying things with code and with stuff like conditional comments. If you've got code specifically for Outlook inside a conditional comment, that just shows as a comment because it is just a comment. So in the code, it's highlighted as a comment if you're using anything else, but in Parcel, it's not. You've got the syntax highlighting so it's easier to read and see. That was a nice little advantage. As it grew, the new tools coming out of it were getting really useful. The Accessibility Checker, absolutely everything I was doing was running through that and I really liked that.

But while I was at Salesforce, we were on the free plan. We never got the paid one because I wasn't building and sending email campaigns. It was more of an experimental sort of testing work that I was doing. It was really useful. Actually, I haven't built emails for campaigns really for quite a few years now. It was only for the first couple of years, my email journey. Everything else has been more building the stuff behind that, the tools around it. 

Yes, that was the big advantage with Parcel. It was quick and easy to send tests and you've got this nice view of the code. But since I've joined, I've got full access to everything now. I can really see how a lot of the more advanced features, the components are just amazing and you can very, very quickly build an email. It takes some work to set that up, so you have to build them all out. But then once that's done, it's very quick to build an email and update all your code as well.

How do you compare and contrast Parcel and Litmus? What is different about Parcel for that developer use case and in general?

Generally speaking, I'd say Litmus is an email testing tool that has email creation, as well. Parcel is an email creation tool that has testing as well. So the focus, I think, is different. Litmus, when used for the testing, is really good.

When I was at Rebel, we were paying $500 a year and then, they changed their pricing plan and tried to put up to $20,000. So, we left at that point. The pricing is high, but I think the UI of its testing side is good. I think the builder is pretty basic. It is good for what it does, but it is very basic.

If you are writing email code, I think Parcel is way better than anything else. If you are just looking to test it and money's not an object, I think Litmus probably is the best option. 

There's a number of improvements that we are making to it so Parcel is as good or better than what Litmus offers. Also, Litmus, when I started out, was very focused on developers. In recent years, they've been more focused on marketing managers and CMOs. They're more interested in the people who are controlling the purse strings. So, a lot of the content and stuff is based around that, and it's less and less about being actually in the weeds and writing the code. However, at Parcel, we're trying to still be very focused on the core users.

Do you think that the use case you had for Parcel at Salesforce is a compelling, big part of Parcel's future? Or is Parcel's future more for SaaS, email developers at brands and agencies? Is that the key constituency going forward?

What I was doing as an edge case was because there were two of us at Salesforce doing that. But then we had a big team of people creating emails to send out. So, I think, the people doing the experimental stuff and the software engineering side of things, that was quite a small market. However, the people creating the emails—the email developer—I think that's our current market.

The stuff we're working on is getting more people on the design and content side of email coming in as well, but currently, the focus is very much on the code editor. But it's building the tools to make it more friendly to the designers and to the content folks as well. I think that’s where we're heading.

How does Parcel think about expanding within the organization to marketers and designers and content writers and others?

I think it's to get everybody involved. You've got your developers who are creating the code, the designers are designing, and the marketers, I guess, are doing the copywriting and the content. At the moment, I think it varies on how brands do that, but it's quite often the design and content will be done together and then, given to the developer to build out and send, which is very slow if you're doing that for every email. 

Quite often, it's like, "Here's a template. We're just changing some content." That makes it a bit easier, but the way we're looking at it is that the developers will create. Well, we're going to have a number of default components, which are just really simple components that anybody could use, but then, a developer can come in and create their own components. So, you've got this component library of all different setups. The designers can then add styles to that. If you've got something that's simple like a CTA link in an email, most emails have a big box with a call-to-action on it.

The components of that was one we had prebuilt, but you can do a lot of options on the styles of that. But the designer could then come in and say, "Okay, here is the primary button, here's the secondary button," and do two styles. Then, when the marketer comes in to create the email, they can say, "Right, I'm putting a button in. Do I want to use primary or secondary style? Where's the link going to and what's the link text?" From the marketer's point of view, it's really simple, and we can also close these things off. The designer has this and it's like the designer says, "Right, if you're using this, you have two options: primary or secondary. You can put whatever link you want, whatever text you want, but there's only two style options." That's going to give the designers control.

But then, if anything changes and there's a bug that comes up or something happens, such as if there's a new Outlook bug that pops up or a new issue with Gmail, then the developer can go in and make those changes without affecting what the designer has done and without affecting what the marketer has done. It still looks the same, it still has the same content being sent out, but the code underneath it has changed. That can just change across—you change that one component, it changes across every email and now every email is fixed. You don't have the design change, you don't have the content change. Similarly, the designer could go in and make a change. They save that and then that design change happens across everything resulting in quick rebranding. The idea is to be very quick to produce these emails and make them very customizable.

Since a lot of the products currently are drag and drop builders, which is great, you drag something and it has the default styles on it. But it's not the default styles that you've defined. It's default styles defined by the company that built this drag and drop builder. Then, you can change them all and save it and edit the content. You can't change the code underlying that. Now, if a bug comes up, you have to wait for them to fix it. I can tell you from my experience that that takes years sometimes and these bugs can be fixed in that time. They come and go all the time. 

People say email coding doesn't change. It really does. The new issues pop up all the time without any information around it, and then, stuff will be broken until that's fixed. So having that ability to quickly go in and fix the code without touching the design or the content side of it is, I think, really powerful.

What was the kind of developer workflow pre-Parcel? For people who weren't using Parcel, what were they using to manage all this?

I think it was sort of, "Here's a design, write some code," and then, the copywriter or the designer would go in and tweak, change the content in the design and send it over to the developer. Then, the developer would probably copy and paste the previous email and then, change the content before sending it out. 

For that, generally, I think Dreamweaver is still the biggest platform to use. Litmus did a report recently where 29% of the people said they're using Dreamweaver. Dreamweaver's crap. It's built for the web and it's just not a great product to use for this sort of stuff. But people like it because you've got the preview there. That's what most people are using now. Yes, that's the process I guess that people have been using. Some people, on more advanced setups, will be building their own component libraries or snippet libraries just in VS Code, host it on GitHub and go that route. 

How we used to set it up before I started getting into the software side of it was, it was started off in Dreamweaver. Then, I moved everything into just a code that might've been Sublime or something like that at the time. Then, having a gulp or grunt workflow to then build it. So I could build out the pieces, run the workflow, and then, get it built out of that, which is quite clunky, but it saves a lot of time. This is just an evolution of that and that’s what we're looking to do.

Do you see a lot of friction around getting people to change the tool that they develop in? Is that one of the major obstacles or hurdles to get over for adoption or is it something else?

I think that's it. A big part of it is getting people to change and also, in its current state, Parcel is for developers. We've got the review function now, which is cool. So, you can get people to look at your design, review it, and add comments and stuff, which is nice. But ultimately, it's for developers to use. 

So it's getting the developer to switch over and it depends what that developer's role is. Email developers, I think we can get quite easily. Having a not insignificant market share in such a short time, I think, is quite amazing, but email developers, I think, are easy. However, if you get people who are doing web and email or people even like full-stack folks, I think they're harder to get across.

Having more integration or more collaboration around the design and content side of things and having that controlled in Parcel as well, would possibly bring more people over. That’s because for people who are email specialists, I think, the benefits are quite clear. People who just dabble in email once in a while don't perhaps know the intricacies and the fine-tuning points. There may be a lot of very bad code out there and a lot of very bad advice and articles telling people how to build email code. People maybe follow that and it gets stuff that's workable but is a bit buggy, not at all accessible, and is really bloated. 

A lot of people are happy with that, and those are the ones that are harder to get. I think those people are not really invested in email and are just sort of, "I don't want to set up another bit of software to use just for email when I can just do it all in wherever I have got set up already."

Do you see Parcel as being like, "Here's a way to get the benefits of this system in a SaaS tool?"

Yes, so it's getting that speed. The speed of building, I think, is a big advantage with Parcel. With components, the way those work, and the snippets as well, it's just very quick to build emails.

Actually, combining the snippets with a component so you can just type in a shortcut, and pull in the components straight away makes it really quick and easy. That's a big advantage. Some of the other tools around it, like the Transformers that we've got are very useful just for making optimizations to that code. So, by just inlining the codes, minifying it just to reduce the file size, you can fix a load of accessibility bugs and some of the simpler ones, quite quickly. I think that's the big advantage with it.

On the flip side, the disadvantage is the integration with other tools which is lacking at the moment. That's a tricky one to do because I'm not very good at the business side of things.

On the free plan, you've got 50 emails, but if you could then host those on GitHub, that would be useful because then you've got the central place where you could integrate into other tools. But then you'd have more than 50. Does that remove an option for people upgrading?

With the components, you make one change in one place and every email that uses that component is updated, which is amazing, brilliant, and just fixes things so fast. But then that's every email. However, those emails are still in Parcel and we still need to move them from Parcel to whatever your sending platform is. We're lacking a bit on that side of it, but I think every tool that isn't directly built into the sending platform is.

Outside of agencies, where do you see Parcel having the best product-market fit?

It's good for anybody sending emails that are beyond the basic ones. If you are managing multiple brands and you have different styling and stuff, I know Sinch which has got Email on Acid and Mailjet and all of that, and they use Parcel. They've got a really good component framework built and they can just make one change. It just changes this template from Email on Acid template to a Mailjet template and that's amazing.

With stuff like that, there's a big advantage there. But really, if you're a small ecommerce company and you are sending emails that are designed—not just simple text but if you're doing anything that's got some level of design and layout going on—it benefits them really because managing the code is so much work. We've got the speed to create the code, but its management and being able to make updates and very quickly get to the root of issues as well, is what it really helps with.

Is Klaviyo a competitor that comes up on the ecommerce side or do you have any competition around ecommerce-specific marketing tools?

Yes. In its current state, I think the biggest competitor really is Litmus. Maybe Email on Acid to a lesser extent, although I know Email on Acid uses Parcel and Parcel uses Email on Acid, so it's a good relationship we've got with them. But they've got an email building tool built-in and the previews there.

I’ve never used Klaviyo so I don't know that much about them. But those sort of tools are more CIO competitors than Parcel competitors, which is one and the same. I don't know what the plan is for the future of Parcel completely, but I could see one potential option of selling white label versions of Parcel to people like Klaviyo and Litmus and actually building the brand that way. Whether it's white label or white-ish label, have a little "Powered by Parcel" or something like that with really good emails that's powered by Parcel. So I think that side of things could grow quite well. Then, building it into the ESPs, will solve the problem of having to sync with an ESP if it's already directly built-in. But I don't know what other people in the team think about that. That's a potential route that we could go down.

What’s your take on where we are at in the trajectory of the ‘email developer’ role? Do you see yourselves being in a moment of growth?

Since I started, it's been growing constantly. It's been quite slow, but growing. When I started, I think most people writing HTML for email were marketers who knew HTML. Then, that specialist role developed over the years of somebody coming into it who is maybe coming from a web background. What's definitely something I've seen more of, is people like "I do web, but now I'm learning about email and I'm coming more from that angle." That's been growing and people are specializing in it.

It's a tough one because for a lot of brands, whereas they're building out your team, it's like, "Do you have somebody to write your email code or not?" It's like, "Yeah, there's definitely benefits to it, but are those benefits going to cover the cost of that salary?" That can be the hard one to say because it's, "Oh! You can use a drag and drop builder and get something that's possible." 

How much better is it? The code's definitely going to be better. It's going to load faster. It's going to be more accessible. There's all these benefits to having somebody who knows the codes to build that. But those benefits are quite hard to judge financially. However, I think that the role is changing. It’s been improving, and there's just the way the code is handled now. If you look at the web and the way the web's changed over the years, a lot of people don't really write HTML, CSS, and JavaScript to build a website.

It's all like frameworks and, "Oh! Just going to run up a new website. Here's my tech stack," and it's just a load of different tools they're using to write a bit of HTML and CSS. But for building a simple website, it's overkill and I don't like that. However, for building complex websites, it's needed. 

The same thing is happening in email. It's taking longer to get to that point. So, having Parcel as your tech stack, as part of, or could even be your complete tech stack before email is probably where things are moving towards. So it's about having these component frameworks, stuff that you can build in a more future-friendly, manageable, and maintainable way. You're not writing HTML and CSS. You are writing Parcel components and you're building it that way. That's where it's going, I see.

What are some of the major opportunities for new stuff to build that you see right now both for Parcel alone and Parcel's roadmap? As part of a combined Parcel and Customer.io, what is enabled by that deeper integration?

Design systems is the big one. Being able to have all your designed components pulled together really quickly. You can have the designer build them, have the copywriter write the copy, have the developer do the code. That's the big opportunity of putting it all together. There's other things like the tracking and analytics and stuff at the moment but it's separate. 

There's the Customer.io version and there's the Parcel version. However, I think there's a bit more that can be done around that. All stuff around the email space of deliverability is something I'm not that up on, but we've got a few tools built into Parcel. There could be more done there. 

I think Customer.io have got the reporting of split tests and the journeys and all that stuff. They've got a really good product on that side. I guess expanding it further would be good and CDN would be a useful thing to have.

You can upload and host images through Customer.io. While it is an option in Parcel, it's not really good for anything other than testing. It's not really a good place for hosting images for campaigns, but having something which is a bit more built as a CDN would be great.

I'm a huge fan of Cloudinary and the work they do with the hosting and just the manipulation layer that you can put onto things. That, I think, is brilliant and it works so smoothly and it's really, really useful. It is a really good tool for managing content for email in the way that you can crop things at the source rather than having to do it with CSS, because then with email, it's not reliable. So being able to manipulate the images before it hits the email client so you don't have to do it with the code in the email is a really useful thing and I think there's an opportunity around that.

Another thing, Parcel is good for building things. Components are good for building things—building emails, branching out more into HTML email, amp email, and text email and having all of those coming from a single source and from that as well to potentially building landing pages. Then, you could build one design to create a HTML, a text, and an amp version of the email, and it creates an HTML landing page. You could then move that into SMS marketing or WhatsApp marketing and send a link out which will link to the landing page. That gives the same experience to those users who are getting the email and people getting the HTML email or if it's supportive, the AMP email. They can get the extra advantages but it's all coming from one source file. That side of things, I think, could be big.

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.