Table of Contents
Do not index
Do not index
Hide CTA
Hide CTA
Hide cover
Hide cover
One unintuitive learning from growing Fillout has been the importance of long tail features - features used by only a fraction of prospective customers.
There's a common temptation to apply the 80/20 rule (the Pareto Principle) to everything in business and software development. This rule would suggest that 80% of the benefits come from the 20% most used features. But when it comes to making software, especially the kind that lets users build their own software, missing even one small feature can be the difference between success and churn.
This is part of what's allowed Fillout to stand out in a very crowded market (form builders). From the start, we've been unreasonably focused on making powerful abstractions. Abstractions that let you create even the most obscure use cases - many of which we never imagined when we first started the company.
Low-code vs. no-code
Generally speaking, there are two ways I’ve seen products handle long tail complexity well.
One approach is to provide escape hatches with custom code. Platforms like Retool have done this to great success. If there’s something you need that can’t be done out-of-the-box, you can always inject your own custom Javascript or Python code.
With Fillout, we went down the other path: narrowing the focus on one type of need (data intake) and implementing no-code abstractions to support all the likely use cases.
Each approach has its pros and cons. The low-code approach narrows down your target audience to developers, while the focus approach narrows down the type of software you let users build.
Accelerated by maturing software markets
The trend towards software that can do it all is only accelerating, particularly as AI reduces switching costs and software markets mature.
When the first cloud-based software tools were developed in the early 2000s, customers had no choice but to work around limitations. But now, with the cost to build software plummeting, there are dozens and often even hundreds of options in every software category.
Software buyers have more options than ever. If you don’t service a customer’s needs well, there’s likely another service out there that does. That means that long-tail features are now a requirement, not a nice-to-have.
Long tail feature examples in a form builder
To illustrate, here are some examples of long tail features in Fillout.
On the surface, it might not make sense to support these use cases since they add a lot of code complexity under-the-hood and only help a minority of prospective form builders. We’ve found the opposite to be the case.
- Answer piping lets you use question responses anywhere in your form, from displaying them to the user to determining which fields and pages are shown. Fillout takes this a step further and lets you to use any information in the form, like URL parameters or even external data from APIs or databases.
- Multi-page forms and page logic let you break up your forms into different pages and control how and when user move between each one. Fillout even lets editors define multiple ending pages and dynamic redirects.
- Login pages let you secure who can fill out a form based on a verified email address, whether or not someone has submitted a form before, single sign-on or even whether an email is present in an external database. Fillout lets form editors reference the user object in the form, whether that comes from somewhere like Airtable or a single sign-on provider.
Many, even most, forms won’t need complex answer piping, multiple pages or login authentication. But the stance we’ve taken at Fillout is that if even a small percent of users find it valuable, we want to make sure we support the use case out-of-the-box. We’re all-in on the long tail features.
Sign up for a free Fillout account to give these features a spin. And if you find a data intake use case you can’t build in Fillout, ping me anytime at dominic@fillout.com.