Is this thing on?
How and why to use the default adoption trick
Jaryd here! Welcome to another edition of From The Garden—the column of this newsletter where I share short essays on one useful idea, often expanding on topics uncovered during company deep dives that can help you build and grow your product.
Hey guys!
I’ve been enjoying mixing in these short letters focused on a single idea. It’s a nice balance of the regular deep dives that cover multiple ideas. I’d like to keep doing this more. And not just because I get a lot of energy writing them, but because the feedback from you has been great.
Going forward I’ll aim to publish one From The Garden piece every two-ish weeks. Most of the time, I’ll use this column to expand on something I’ve learned during my research for the deep dives—thus driving home what I think is one valuable lesson that can help you build and grow your product.
Often founders or operators are dropping an insane wealth of information on me when I interview them for our pieces, and I just can’t cover all of it. So think of this series as the outfielder that makes sure nothing worth catching gets past us.
Today we’re talking about something that will squeeze far more juice out of the features you build and launch. If you want your next release to have greater adoption, usage, and impact for next to no effort, keep reading…
This paid post was made free for everyone thanks to…CommandBar.
The only platform for non-annoying user assistance, helping us product folks unleash our users*
CommandBar helps you help your users with the best onboarding layer, period. Their product suite comes with a stack of PLG powerups to help you grow, like:
Copilot: Not just an always-learning chatbot; an embedded AI support agent.
Spotlight The Cmd+K shortcut that helps your users teleport anywhere.
HelpHub: A gorgeous and personalized in-product help center.
Announcements: Nudge with modals; use air traffic controls to never annoy.
Questlists: Send users on fun, self-guided, interactive quests.
Surveys: In-product feedback, from NPS to 😍🤮 and everything in between.
We’re busy buying CommandBar ourselves right now at my company. There’s no code required for any of it which is great, it integrates with all our tools, and there’s a 2-week trial period to feel the CommandBar difference.
Let’s try this thing together and make all our users happier.
*Sponsored
The default adoption trick
Have you ever poured your heart and soul into building a feature only to check the charts every day and see a sad adoption curve?
I have.
*Queue the words smallest violin 🎻
I’ve been in post-release meetings where we talk about underwhelming incremental gains in a feature’s usage, each time feeling a little more frustrated that more people aren’t discovering what we built.
Then comes the (usually annoying unless you’re using CommandBar) popups, banners, emails, and modals—doing what we can from a growth perspective to just push people to start using something.
Having polished and useful features that are mostly ignored isn’t all that uncommon. We build features we believe in, but there’s always the uphill battle of getting users to actually try them.
But that’s the problem…
As product builders, we so often fall into the trap of creating features that require users to discover and adopt them actively.
So, here’s the idea: 👇
Build products like a microphone at a concert or comedy show.
When performers step on stage, they just grab the mic and start their thing. Unless ironically, they’re not tapping their mic saying, “Is this thing on?”. Of course it’s on, and it’s not something they even think about because they’re on stage to get something else done. However, if the mic wasn’t on or stopped working—they’d instantly know and not be able to get their job done.
Why don’t we build more products like that? Things that solve real problems and become essential to a workflow, but are default On for everyone.
That’s how to have your adoption metrics start at 100% vs 0%.
The Problem with Opt-In Features
Launching features that users need to find and enable comes with inherent challenges:
Discovery hurdles: When things get added to and buried in the UI, the chances increase that people may never stumble upon your new functionality. This is amplified in complex products.
Adoption friction: Even when discovered, the extra steps needed to activate can limit usage.
Impact lag: The time between launch and decent adoption will delay realizing your expected customer and business value.
Learning lag: When you have a slow adoption curve, you have a slow learning cycle.
Resource drain: Marketing and growth teams end up spending time trying to drive awareness and adoption. Also, morale sometimes gets shot when early numbers aren’t that hot.
The Power of Default On
I didn’t break my back validating this number, but it feels right enough: 95% of users keep their default settings.
That could be the end of this essay. 🤣
But to go deeper, defaulting new features to "On" clearly has a lot of potential.
You get immediate widespread impact (since your reach is 100% on day 1).
You save yourself the need for adoption campaigns.
There’s a far higher likelihood that your users experience value.
Your ROI timeline shortens significantly (assuming the feature works)
Your feedback loops for iteration are orders of magnitude faster.
There’s a higher potential for viral growth if the feature enhances sharing or some network effect.
But good doesn’t come without some considerations…
There’s the risk of surprising or confusing users.
There’s the potential for performance impacts if not carefully implemented.
Your new default may conflict with your user’s expectations or preferences.
Implementing the Default Adoption Trick
So what’s the best way to approach smart defaults?
Validate!: You want to spend more time in discovery to make sure you’re right that the feature adds value for most users. This is an emphasis on assumption testing before building. The extra time spent here is fine because you’re accelerating your time to impact on the other side of the release.
Design for discoverability: Even if on by default, make the feature's presence and benefits clear to users. The selfish benefit is that you still want users to know you’re shipping valuable stuff for them.
Provide easy opt-out: Always give users control with a simple way to disable the feature. I’ll show you an example of this in a second.
Monitor closely: This should go without saying, but it’s almost more important to track usage, performance metrics, and feedback immediately post-launch when you have 100% adoption from the get-go. For one, because the risk is higher of something going wrong or having a negative impact. And two, because you can validate if your impact hypothesis was right much faster. So whether the data brings you good or bad news, you want to be extra on top of it when using smart defaults.
Iterate quickly: You’ll be learning a lot faster, so have resources at the ready to make any changes based on early data and user reactions.
If you have a basic checklist or process that you use for product development and planning, consider adding a new line item there to remind yourself to ask: “Is there a smart default opportunity here?”
And if the answer is Yes, there is!; then be sure to ask yourself these 5 questions before defaulting anything to On.
Are we sure this being automatically On would help users?
How might this affect different user segments? Does everyone need/benefit from it being On, or just some people?
Can our infrastructure handle widespread and rapid adoption?
Are there any legal or privacy concerns? Especially for data-related features.
Is there a phased rollout approach we can follow with a subset of users to test our hypothesis before reaching everyone?
Real-World Examples
Smart defaults are on all around us. Here are a few that come to mind:
Gmail's Smart Compose ✍️
Default on: Predictive text suggestions appear as users type.
Impact: Increased email composition speed for billions of users.
Spotify's Autoplay 🎶
Default on: Automatically plays similar songs when a playlist or album ends.
Impact: Increased listening time and discovery of new music without any effort.
FB/IG/TikTok’s Feed Algorithm 📰
Default on: Automatically curates content based on user behavior.
Impact: Increased engagement and discovery of relevant content.
Google Maps' Live Traffic Updates 🗺️
Default on: Provides real-time traffic information.
Impact: Improved route planning and reduced travel times for billions of users.
Cars’ Automatic Headlights 🚘
Default on: Lights that turn on automatically when it gets dark.
Impact: Safer roads since nobody forgets lights when they need them the most.
Substack’s Pricing and Boosts 💱
Default on: Localized pricing and local payment methods at checkout.
Impact: Paid writers drive more subscription revenue with no extra effort.
Substack is actually one of my favorite examples. Obviously, I may be biased as someone who writes on Substack and gets to benefit from this. But truly, bias aside, they are nailing the default On strategy. When I spoke to
who used to run growth at Substack, he told me Substack’s philosophy was always to build things that were default On. And when I explore the Substack settings page, I can see all the features just working behind the scenes for me—all toggled to On.Just like a microphone, I now expect these things to be working and would be annoyed and impacted if they were taken away. A very smooth layering of value to their core product. 👏
This leads us to the final point…
The Takeaway
While defaulting features to "On" can drive rapid adoption, the real magic lies in designing features so seamlessly integrated that users don't perceive them as separate entities to be turned on or off. You want to build things that feel like natural extensions of your product's core functionality, enhancing the user experience without disrupting it.
By leaning into the default adoption trick and considering very early in the prioritization process what features could be automatically On, we’re ultimately shifting our focus from driving feature adoption to creating features that drive themselves. It’s an approach that not only maximizes impact but also aligns what we build more closely with genuine user needs, because if we focus on building (mostly) what we deem everyone wants On, we’re innately probably choosing the most important things for our customers.
In the end, the best features are those that users didn't even realize they were missing—until they suddenly can't imagine using the product without them.
Before we say goodbye…
Here’s what I use to grow 🛠️
I use Attio as my go-to CRM to manage all my newsletter sponsorships deal flow and learn more about my email network. (Learn more)
I use Sidebar as a leadership program to accelerate my growth as a product leader. An excellent community for founders and senior leaders. (Learn more)
I use Dovetail as our team’s customer insight hub, helping us spot patterns in feedback across channels. (Learn more)
How I can help you 🤝
Are you a founder looking to grow your business without breaking the bank? If so, I’ve invested in a company (Athyna) that can help you find incredible talent and build out your global team in less than 5 days. Their product, service, and worldwide talent pool are just amazing (and so affordable). Learn more here ↗
And that’s everything for today’s letter.
If you found this idea useful, feel free to forward it to someone. Or you can hit the heart button on this post so more people can discover it on Substack.
Until next time.
—Jaryd
Great essay! Specifically loved the examples (Gmail etc). I experience it myself too haha