To get wider product adoption, support old standards
"Everything Starts Out Looking Like a Toy" #114
Hi, I’m Greg 👋! I write essays on product development. Some key topics for me are system “handshakes”, the expectations for workflow, and the jobs we expect data to do. This all started when I tried to define What is Data Operations?
This week’s toy: an AI engine to create stock photos. For example, here’s one of a cat wearing sunglasses. How long will it be before this photo could be animated into a fun montage? Probably not long.
Edition 114 of this newsletter is here - it’s October 10, 2022.
The Big Idea
A short long-form essay about data things
⚙️ To get wider product adoption, support old standards
Once an idea becomes popular and widely used, it has a high likelihood to become a persistent standard. Standards are cool, right? They help you grow the installed base of developers who use a solution and also make it easier to market to a large segment of the population. Standards have an ongoing impact, a social observation called the Lindy Effect. The Lindy Effect posits that the longer something has been around, the longer it is likely to stay around.
As a Product Manager, one of the most important adoption cues is to present metaphors that people already know. If I expect a green button to make things go based on my experience with traffic lights, and pressing the green button makes things go, that’s a cheat code for a product behavior. Because the user already knows how to do it, there is a mental shorthand available to ask them to do a thing.
When you want someone to adopt a new behavior, using this pre-defined library of expected actions is a key way to borrow their existing knowledge and ask them to do new things. This applies for simple things like consumer choice, and also for technical solutions like pulling information out of a database. One such long-lived solution is Structured Query Language, which has been around in (mostly) its current format since 1986.
SQL defines a common way to push, pull, and update data. It’s been around for almost 40 years. That’s a lot of developers who have experience with this idea. Even when the standard is boring and technical, it’s valuable because lots of people use it.
That brings me to an interesting decision made by Fivetran last week where they decided to stop supporting SQL users directly in their product. Here’s a quick summary if you’re not familiar with this product. Fivetran makes a product that lets you select data from databases using an automated process, optionally transform that data, and send it to other destinations. SQL was a key part of their product for people with a technical background who needed to adopt it quickly. Support for SQL enabled many people to use Fivetran.
The response was pretty swift from some of their customers, many of whom did not take the news well:
Why do you drop a standard?
I’m sure there were lots of important reasons the team decided to drop this feature. Maybe this feature was a high support burden. Perhaps the team wanted to emphasize their new shiny feature and take a bet on another embedded technical community (dbt users). Who knows the exact rationale here? But if you consider the Lindy effect, it’s likely that people will still be using SQL in 30 years. Why stop now?
Adding a new customer is a fragile situation because you have a limited amount of time to deliver value, ask them to adopt new concepts, and map their current knowledge into something new. If this doesn’t happen quickly, it’s highly likely those users will go back to something they know. Instead of only teaching prospects brand new concepts, why not map their existing knowledge to something new and help them cross a bridge to a new world where they can learn new skills?
Product managers asking existing users to make a break with the past are telling those users they don’t matter as much as new users. Be careful when you remove backward compatibility without delivering a clear improvement in time to value and experience. (Think delivering a 10x improvement.)
An alternate way to support a standard
Another way to think about this problem is to acknowledge the standard and move the use of that skill to a different area of your product where people can contribute and find good use cases. If you squint at Fivetran, this is exactly what they did: moved the SQL use case to a place where the responsibility for supporting SQL was no longer in their core product. However, they also added a burden at the same time to support dbt: another adjacent technology that users might not want to adopt.
Don’t forget the user when this happens. The response from Fivetran users who mapped their SQL skills to the jobs they needed to do in Fivetran was to be disappointed rather than excited. Clearly some of those users felt like this was a big deal.
Here’s another example of changing the behavior of prospects who have an existing preference for SQL. MongoDB is an example of a database company that changed the way of interacting with data from SQL to another standard (using a document-based approach). MongoDB has been on the market for several years now and has started to make space for SQL developers. They now allow SQL queries of data in the Mongo data store.
Using SQL to access data after the fact is not the identical use case to using SQL as the core use case of the product, but in either solution it makes it easier for developers with existing skills to adopt those skills when using a new product that has a slightly different view of the world.
What’s the takeaway? When building new features, don’t forget about the expectations of existing customers. Changing the perceived contract customers feel they have with your product can create some angry feelings, especially when the changes are unexpected. On the flip side, remember that trading on existing expectations might enable you to get outsized adoption from people who already have those skills.
Links for Reading and Sharing
These are links that caught my 👀
1/ Heroic effort, or a better process? - the way your product process works tends to drive the perceived culture around your product. Are you a feature factory or are you building the next step in a careful product roadmap? The system should reinforce the outcomes you want to get from the product process.
2/ What are data operations, anyway? - Omar Khawaja has written an excellent overview of the overlap between the different competencies that make up data operations. Data Ops refers to a number of different use cases that started from different goals and are now converging.
3/ More people are using electronic money - the COVID pandemic has sped up the tendency of Americans to use alternatives to cash. Over 40% more people (41% in 2022 vs 29% in 2018) now make all of their purchases electronically.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon