Magic vs Configuration

six years ago i ranted that features aren’t buttons, then down-spiraled into some drivel about marketing and specialization.

today we revisit the “build more features” anthem that plagues technology creators everywhere. we start with arguments and counter-arguments.

i want to grow my company, should i build more features?

• yes, because the competition has them
• no, it will make the product too complicated
• yes, because users are asking for it
• no, because users don’t know what they want

the problem with heuristical advice? all of it is true.

good judgment is not the memorization of heuristics, but the ability to pick and choose which ones to apply to a given situation.

here’s another lens with which to examine feature proposals.

magic

these are features that “just work.” users don’t even know they exist.

suppose you build a photo sharing app. by compressing image uploads, users will see images faster, and perhaps spend more time in the app because the experience is smooth.

the more time they spend in the app, the more advertisements they see, the more money you make. image compression is a magic feature.

configuration

these are features users can customize.

extending our photo sharing example, a studio tool with color filters, cropping, rotation, etc utilities is a configuration suite.

when a product lacks the expected configuration options, users bounce to something else.

how to build features

let’s ignore where feature ideas come from… users, dreams, abstractions, whiteboard sessions, ayahuasca.

feature spec in hand, you need to determine whether it should be magical or configurable. put another way, you need to decide if the feature should be visible or invisible.

here are a few ways to think about it.

user profile

if you build an API, your user is a developer. they probably prefer configurations, and will read documentation to learn how to use them.

if you build a camera, you should offer a button to snap photos and focus on hardware. Apple and Samsung have done this for years; their cameras are now 10x better but the user experience is the same.

job to be done

is the feature intended to increase signups? decrease churn? accelerate new user onboarding?

magical features and default configs help onboard new users, but hackable configurations and granular controls help keep them long-term.

i’ve signed up at least a dozen Google Ads accounts, and my PPC readers will nod that the simplified “express” onboarding is a 100% different interface from the regular campaign dashboard.

root cause or symptom

let us assume your feature solves a problem. but how close is it to the metal? does it fix a root problem, or address the symptoms?

at Fomo one of our biggest complaints is, “i made changes, but don’t see them on my site.” this is a caching issue. but should we build magical cache-purging functionality (root problem), or provide users a “purge my cache” button (symptoms)?

it’s easy to say, “always fix the root problem.” but there’s a reason hospitals give patients a morphine drip, even if clicking the button doesn’t do anything.

utility tradeoffs

when you launch a new app, the first 5 features will be adopted by every user. the next 10 will be adopted by most. the next 20 will be adopted by a smaller group. and so on.

at Fomo we’ve launched 200+ features, and we’re lucky if 5-10% of our customer base leverages any given new one.

sometimes building a feature “for the 1%” makes sense, because that 1% could fund 20% of your revenue. other times it’s not worth cluttering the the interface and usability for the other 99%.

in this case you can return to our magic vs configuration approach… build those killer features for the 1%, but make them invisible. everyone wins.

conclusions

i wrote this advice for myself. as a “product marketing” guy i prefer pleasing existing customers (who share us with friends) over bothering strangers on the internet.

that said, i do believe a product can be fully “baked,” and maturity is nothing to be ashamed of. look at Craigslist, reddit, et al.