Why services should offer marginal features (with apologies to 37signals)

37signals is the gadfly of the startup world. They’ve built a hugely successful company that is not (1) venture funded, (2) in Silicon Valley, or (3) looking for an exit.

Many of their ideas are spelled out in detail in a great little book called Getting Real. If you haven’t read it, you should. Not because they’re right about everything, but because they’re opinionated and will make you think. And they’re right about a lot of things.

One of their recurring themes is: build a minimal feature set. “Build half a product, not a half-ass product.” “Make features work hard to be implemented.” “Expose the price of new features.”

This is all good advice. Take it to heart. Especially if you’re building a web-based tool like Basecamp.

But if you’re building infrastructure, think differently.

How cloud computing changes things

One of the biggest shifts in technology today is the proliferation of API-driven services. Five years ago, if you wanted to store files (S3), host a web application (Heroku), send email (Sendgrid), process video (Zencoder), or interface with telephony (Twilio) or geolocation (SimpleGeo), you bought expensive hardware or spent months building software. Today, you sign up for an inexpensive service, and you’re up and running in an afternoon.

This is exciting. It parallels the proliferation of open-source software after the first dot-com boom; in 1996, a startup needed expensive software and hardware (Oracle and Solaris), but by 2006, you had comparable (better) tooling for free with MySQL and Linux. This changes the rules for startups. Cloud Computing, Software/Platform/Infrastructure/Application-As-A-Service – also known as XaaS – is just the next step in this process.

This is like Moore’s Law for functionality. Every 18 months, you can do twice as much at half the cost. This trend lets us build and deploy a powerful, full-featured application in, say, two days, and we’ll be able to do more in a few years. We can do things now in an afternoon that would have taken months in the past.

In praise of marginal features

Conventional wisdom, 37signals style, is that you should do as little as possible. Not just as a way of getting out the door quickly, but as a benefit. Less is more. Better to do 20 core features than to do 20 core features + 20 marginal features.

This advice might be good for user-facing web applications. But if you’re building XaaS, marginal features are awesome. That’s because when you’re a service, what’s marginal to one user might be core to another.

We built Zencoder initially with a minimal feature set: encode anything to high-quality MP4, and do it quickly. Today, MP4 is still the majority of our encoding (85%). But we’ve gone well beyond this initial core; we’ve added support for Ogg, WebM, WMV, VP6, and 3GP; powerful options for thumbnailing and watermarking; and advanced video processing options.

This week, we’re releasing a bunch of advanced audio processing features. These features let you normalize audio levels, fade in/out, control gain, apply a highpass/lowpass filter, apply a expand/compress effect, and apply basic equalization. We’re even adding a karaoke effect option.

We don’t have a dozen customers demanding that we add control over audio gain. Audio EQ options might not matter at all to 99% of our customers. No one may ever use the lowpass filter. But we don’t know, and it’s not up to us to know. The lowpass filter was trivial to add (about 15 minutes of marginal time, all things considered). Our job is to provide powerful tools and let our users decide what options matter.

An API is not a UI

This is where an API is different from a UI. Adding extra features to a UI increases complexity linearly – O(n), let’s say. Double the features and you double the complexity. If features in a UI interact with each other, this might actually be O(n-squared) – double the features, and get exponentially increasing complexity. It’s much harder to deal with 60 options in a web-based form than 20 options.

But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. You should be able to safely forget about features you aren’t using, and just use the features that matter to you. Done well, incremental features in an API only increase complexity by O(log-n) or even O(1) – virtually no complexity increase at all.

Of course, not every marginal feature is a good feature.

Avoid marginal features that are confusing. Generally, this involves features that interact with other features, or that users have to manage even if they don’t want to. If a marginal feature makes it harder to use core features, it might not be worth having. But if you can successfully ignore a feature that you don’t need – if you can happily use Zencoder for years without ever looking at audio_compression_ratio – then the feature probably isn’t confusing.

Avoid marginal features with no benefit. This is obvious, but is worth stating. If there is both a high-quality and a low-quality version of a feature, and there is no advantage to the low-quality version (e.g. speed, price, or compatibility), stick with the high-quality version only.

Avoid marginal features that are expensive to develop. Don’t spend months of time working on something no one is going to use. Build marginal features when they’re easy to implement, or you think they’ll be especially beneficial to some of your users.

Someone out there will be able to do something really amazing with our advanced audio processing features – something that I would never guess. I’m amazed by the wide range of creative things people use Zencoder for, and I’m sure the same is true of any API-based service. Running a XaaS business, it would be a disaster if we tried to anticipate – or control – how our users use us. We can make recommendations, of course; we can tell our users when they’re making an obvious error. But at the end of the day, if we can power creative and unexpected uses of our platform, everyone wins.

So please, build an awesome app using karaoke mode, and come tell us about it.

  • Guest

    Right on. This one should really go without saying, but based on experiences with an unnamed enterprise vendor(s):

    Avoid marginal features that you implemented because one client asked for it, but then didn't find time to properly document for everyone else, which has complex side-effects and interactions with other features, and which requires such specialised knowledge to configure in combination with everything else that you end up having to send in one of your 'solutions architects' to figure out 'best practise' for configuring the f***ing service, but then even the solution architect can't remember all the side-effects and interactions between all the bolted-on features implemented for different client-specific purposes… :)

  • Guest
blog comments powered by Disqus