Why we built a MailChimp integration

At Typeform, we have an amazing Customer Success Team that knows our customers inside and out. They spend lots of time pouring over feature requests and customer pain points. One of the hottest topics? Native integrations—seamlessly sending data between typeforms and other apps.

Integrations help with all kinds of jobs-to-be-done. Marketers who generate leads with Typeform send contacts directly into their MailChimp lists. Recruiters send applicant data directly into their HR systems. And many others use Typeform to sign up people to their Slack channel, update Trello cards, and send data directly into Google Sheets. We had an endless list of possible use cases!

Of course, we couldn’t build everything at once.

What do we build first?

To figure out which integration to tackle first, we weighed in a few crucial factors. We looked at things like:

• the potential value for our customers

• how many people would potentially use it

• the complexity of development

As we dug deeper, we found that one of our biggest use cases was marketers growing their MailChimp lists. This was perfect. We already had a bunch of customers asking for this. Plus, growing an email list brings a lot of value for people, and it’s an ongoing use case which keeps churn down. The fact that MailChimp has such a strong brand and product was the cherry on the cake.

There were still a lot of open questions, and we wanted to test our biggest assumptions as quickly and cheaply as possible.

Enter the Google Design Sprint.

Start with what's hardest

A Design Sprint is a five-day activity based on design thinking. It starts with empathy and creativity—things that are close to our core values here at Typeform. We knew that companies like Medium and Slack use it to test new ideas, so we decided to give it a shot.

The concept of Design Sprints was developed at Google Ventures, who define it as “a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.”

In these five days, you come to deeply understand what problems to focus on, build a prototype to test your assumptions, show it to customers, and see if it works. If so, awesome. If not, at least you learn a lot in just a week.

We started by defining a good challenge for the sprint. We put a lot of effort into this step. A challenge which is too narrow kills creativity, and the results are not insightful enough to justify the time invested. On the other hand, a challenge that is too broad makes it hard to satisfy our constraints.

Examples:

• “How to build the MailChimp integration.” Too narrow.

• “How to integrate Typeform with third-party tools.” Too broad.

In the end, we found a compromise that made sense to everyone:

“Find a way to encourage a maximum number of marketers and founders (our core personas) to integrate their typeforms into their workflow.”

Next up: focus on understanding the problem. In the first couple days we stayed away from brainstorming solutions. On Wednesday we sketched our ideas and presented them to the team. Thursday was when we started prototyping our solution—a well-balanced Frankenstein born from our ideas.

The most exciting part was the the last day of the sprint. We invited five customers to come to our office and test our prototype. Our biggest assumption was put to the test: Would people be able to connect their MailChimp account as easily as filling in a typeform? Turns out, yes!

So we had a rough design, and it was time to translate our learnings into a backlog of user stories.

User story mapping & sprint work

We started with a “User Story Mapping” session. Story mapping is based on a simple idea: walk through your customers’ journey with your product, and build a basic model that outlines this journey.

Why story mapping? Because it centers on the big picture, something that a long list of individual user stories often misses. This focuses teams on outcomes over outputs, and helps you to avoid building unnecessary features.

User stories are not a one-way communication of business requirements. Stories should spark conversations between team members. Story mapping enhances this communication, and allows you to scope releases easily, together as a team.

Story mapping gave us unified ownership of our solution. Instead of a product owner mapping the user journey on their own, our whole team provided input and “Have you thought about that?” moments. This really made the difference.

Here are some tools we use to keep our workflow as smooth as possible:

• 3 amigos: a quick daily chat where our product owners, developers, QA’s, and designers outline user stories.

• Backlog refinements: whole team meeting to review backlog and make sure all user stories are understood, scoped, and estimated.

• Event storming: a team session to dive deeper into trickier parts of the product, like error handling.

• Spikes: investigations to make sure we have the information needed to start a user story. Example: before we implemented tracking, we checked in with the data team and nailed down the most valuable metrics to watch.

Release and learn

After lots of hard work, we finally released the early access version of our native MailChimp integration. Here are a few key learnings we’d like to share with you.

1. Release early and often

Reducing scope is extremely important. The biggest learning for us is to always keep the MVP (minimum viable product) mindset—release early and often. To be honest, we didn’t always stick close to this guidepost, and it ended up biting us a couple times.

2. Test big assumptions cheaply

One of our past mistakes was building features based on our own assumptions, not grounded in customer research. Now we talk to as many customers as possible to really dig into the problem. We test our riskiest assumptions early.

We also found design sprints to be an awesome tool. They’re a daunting investment—a full week’s worth of time for a whole team—but it was worth it. Looking back, it was just a blip on a long timeline.

3. Asking is free

We also asked for constant feedback. We queried our database for users who had integrated a typeform through Zapier, then emailed them asking for feedback. We also built a “Request integration” button on our integrations page which asked users their needs and desires through this typeform. To date, it’s received more than a 1,000 responses.

So there’s an inside look on how we built our native integration with MailChimp, from idea to first release. By sticking close to our values and executing on a validated solution, our users can now seamlessly connect their typeforms to MailChimp groups.

In case you haven’t seen it, the MailChimp integration is already sitting in your Typeform account. Go check it out, and please let us know what you think.

Want some more? Find out how to make your MailChimp surveys dazzle