Peter's guide to ease

Let’s see:

• New blog at blog.petervandijck.com (and WordPress.com’s image import is just magical btw). This was the biggest deal.
• ITTT for cross-posting to Twitter from blog. This is meant to encourage me to blog as opposed to posting on Twitter.
• Turned off bunch of apps on Facebook. No more cross-posting from Twitter to Facebook. Twitter is work-world, Facebook is friends/family who don’t care about my geeky rants.
• Still using Path as my private little Facebook for a few select people.
• Next: set up phone apps for everything.

Perhaps this will inspire me to blog? The problem I’m trying to solve is that of audience.

I moved my blog to blog.petervandijck.com. I expect this to be a long-lived URL, wouldn’t be surprised if it lasts 30 years. Which means my feed has also changed, those of you who still use Google Reader or something similar, subscribe to blog.petervandijck.com/feed/

To a new domain (with redirects), blog.petervandijck.com. I put it on WordPress.com. And may I just say: the moving and importing of content was ridiculously easy. WordPress even copies images from your old site into your new site. Automatically – nothing you have to do. That’s impressive.

There is 1 feature in your current product that you could take out today, without any negative consequence at all.

Taking it out will make maintenance and software evolution, technical debt, support, and probably even the user experience better. It will make your codebase more maintainable. It will make everyone happier. You added that feature because you thought it would make a difference, but it doesn’t.

In evolutionary terms, taking this feature out will increase fitness (or keep it fixed) while decreasing complexity.

That’s feature debt.

No product is so perfect, so optimized that all of its features are in perfect balance, all necessary, all required.

No digital product anyway. Here’s one that’s pretty close. But note:

1. It’s very simple.
2. It’s been optimized for centuries.

So let’s assume that there is 1 feature in your product that you could take out, with positive effects. Once we agree on that, it’s quite likely that there are more than 1 features that you could and should take out. There are features you should not take out, too. The more complex the product, the more features you should take out. Facebook surely has dozens of features that they could take out today, and the net effect would be positive. Google probably has hundreds. Windows has thousands.

There’s not a lot written about the art of taking things out once they’re launched. Taking things out during the “design process”, sure, but not after it’s launched.

Apple is famous for removing features from live products. They’re also famous for launching products with very few features, but that’s for a different post.

There are 2 kinds of features that you can take out: features that nobody uses, and features that some people like but that aren’t helping *you*.

Features that nobody uses are easy to take out. The hard part is to define “nobody”. Early on (first year or two), I like to go with 10% of my active users. If not even 10% of my active users are using this feature, we should probably kill it. You could do 20%.

It’s easy to know when nobody uses your feature. Track it. Once you use metrics to inform (not drive) your product decisions like this, you’ll never go back. But that’s another post as well.

Features that a significant amount of your users actually use and like are harder to take out. But if they’re not helping *you*, perhaps you should. These are often features that are attracting the wrong kinds of users, or encouraging the wrong kind of activity, or perhaps they just don’t fit with the direction you want to take the product in.

If you’ve never considered taking features out of a live product, try it. It engenders a whole different mindset. You’ll start asking, before even developing a feature: do we really need this? It will make you want to measure things. It will make you think more deeply about your product. It will be good for your team. That’s probably a rule for a good product team: takes features out of live products.

Notes:

• The debt metaphor comes from WardCunningham
• See also: You Aren’t Gonna Need It
• Decreasing complexity is good, because it speeds you up.
• Andrew Chen calls it product design debt.
• Architects call design debt “work that remains unfinished after a deadline”, which isn’t exactly the same concept.

I suddenly understood: the new blogging is BETTER than the old blogging.

Twitter, Facebook etc., that’s for links and quickies. Blogging is for deep thinking, well written essays etc. (And for news blogs etc.) That’s what I enjoy reading, and I think that’s what I’ll try to be blogging then.

Firing up LiveWriter!