I’ve been on the trail of “no code” martech these past couple of weeks, covering event-triggered marketing automation as a no code programming paradigm and mapping a partial taxonomy of over 75 no code tools.
I also ran an impromptu survey of no code usage with readers, the results of which I’m sharing here. Given that my audience is mostly marketing operations and martech pros — and the savvy CMOs who love them — the data is skewed through that lens. Out of 97 respondents, 40% identified as marketing ops/marketing tech and 25% as tech-savvy marketers (both flavors of marketing technologists).
As you can see from the chart at the top of this post, Zapier is by far the most popular tool used by this audience, followed by IFTTT and Airtable. From there, it stretches into a long tail of less commonly adopted no code products.
Given the above, it’s not surprising that the primary no code use case reported in our survey was implementing workflows and processes (82%), often across multiple apps and platforms within a martech stack. Next most popular, but significantly lower at 37% and 35%, were publishing web forms and setting up databases. Essentially: collecting, routing, and storing data.
Less common with this audience was building websites, chatbot flows, interactive content, and other web apps. There may be plenty of marketers creating such things with no code tools, but not so much in the domain of marketing operations. As our study of job responsibilities of marketing technologists revealed earlier this year, those activities are probably more in the camp of brand/demand builders and marketing web developers.
This is further bolstered by the data that 67% of the participants reported using no code tools for the purpose of building internal apps and workflows.
It’s interesting to note that 54% also reported using no code tools for their own personal productivity. “I’ve got a job to get done, and I can save time by setting up this little automation.” The potpourri of marketing operations responsibilities has a bear unlimited supply of such opportunities.
It also suggests a healthy evolution of the relationship between marketers and martech, with people increasingly bending the technology to their desired processes — rather than bending their processes to the technology.
Finally, it’s often debated if no code is a gateway drug to “real” programming — or if you need such programming skills to really take advantage of no code tools.
I suspect that debate will continue for some time, but the data from this survey implies that you don’t have to be a “real programmer” to harness the power of no code solutions. 71% of the respondents said they either had no coding skills or just a little bit, such as familiarity with HTML.
21% of participating claimed to have intermediate or advanced coding skills. For them, no code is a practical, time-saving short-cut. Just because you could write something from the ground up in Java, doesn’t necessarily mean you should.
Only a small 7% reported having basic coding skills. This bimodal distribution — either no real coding skills (71%) or professional-level coding skills (21%) — doesn’t seem to support the “gateway drug” theory. You’d expect a more even distribution of coding skill advancement among no code users if that were true.
Why learn to code if you don’t have to?
I realize that will set off a heated debate about the importance of understanding the concepts of coding to be effective as a no code practitioner. Which I generally agree with. But that’s a post for another time.
Airtable was a surprise to me. Thanks for the comprehensive list. Most interesting use is chatbot as I cannot understand how they are using it? Probably for triggering next steps.
Binomial distributions suggest two subgroups are being combined. It would be interesting to see if the two groups show different profiles in the tools and applications, although there’s only so much you can do with 97 responses.
I’d speculate that the people with coding skills use no-code tools to save time, while the people without coding skills use them because they have no alternative. Ironically, that suggests the people without skills will be creating more complex no-code applications, pushing into territory where a coded solution would actually be more efficient if they knew how to do it. This is how you end up with crazy-complicated Excel spreadsheets because the user is a bright person who is using Excel for something that should really be done in a database. Those are the no-code situations that create the most risk in terms of quality control, security, etc.
You can certainly see how no code tools could get people without “coding” skills (at least conceptually) into trouble with more complex apps. But in practice, I think most of the things being built are extremely lightweight. In Christensen’s disruption innovation model, this would be no-code creations that would be overserved by traditional coding — and therefore unlikely to ever be built by someone as a code project.
There are some crazy-complicated Excel spreadsheets out there. But the vast majority of Excel spreadsheets are pretty straightforward, and you wouldn’t dream of having a software developer build a custom app for each of those.
Trained coders have no monopoly on organized thinking. Indeed, business users understand their own needs better than anyone else, so there are many situations where giving them a tool to create their own solution will hvae a better result than forcing them to work with a developer. The difference between coders and non-coders is that coders have the option to code when something is too complicated for a no-code solution. Non-coders are forced to push the no-code tool beyond that point or bring in a coder, which is a big barrier. What’s interesting is the line where something becomes ‘too complicated’ keeps moving as no-code solutions become more powerful.
I guess we also have to distinguish between use of no-code and projects that are formally governed — there’s perhaps an implicit assumption that no-code projects are built by individuals without supervision but that’s not necessarily the case. For example, nearly every marketing automation system has a no-code interface for building multi-step campaign flows, but these are as tightly governed as any formally programmed system. (Or should be.)