ESP choice not driven by creation tools
Courtney Scharff, manager of marketing ops at Figma, on Figma's marketing operations stack
ESP selection is driven by who can segment audiences, route data, and send reliably, not by whether the coding tool sits a little closer to the send button. At Figma, the same small group uses both Marketo and Parcel, but Parcel still lives upstream as the place to build and review HTML while Marketo remains the system of record for testing, subject lines, reporting, and launch. That makes deeper integration useful for saving copy and paste work, but not decisive in platform choice.
-
Parcel solves creation workflow pain, not core ESP pain. The team uses it for shared code editing, previews, comments, and QA, while Marketo is still where emails are actually tested and sent. That separation explains why integration is convenient but secondary.
-
This pattern shows up beyond Figma. Zapier builds and reviews emails in Parcel, then exports code into Iterable and HubSpot. The operational gain comes from components, versioning, and feedback, not from replacing the ESP decision around data models, journeys, and channel orchestration.
-
Parcel's long term strategy is to become the creation layer across fragmented email stacks, and Customer.io bought it to tighten that loop. But even Parcel's own roadmap centers on automatic export and design system propagation, which treats the ESP as a separate system that still has to earn the budget on broader workflow needs.
The next step in this market is tighter handoff between creation tools and sending tools, with fewer manual exports and more shared components flowing straight into campaigns. That will raise the value of integrated stacks like Customer.io, but most large teams will still choose an ESP based on segmentation, analytics, governance, and existing data infrastructure first.