Be Honest With Your Customers

Sometimes your product falls behind the curve. Or you’re forced to release a version that makes some compromises. It happens. And it’s not the end of the world.

Recently I’ve seen two examples of companies that have done an exemplary job releasing a product without a feature they were working on or admitting their product may have fallen behind another product’s feature set.

Last week Sparrow released Sparrow Mail App for iOS which, by just about any review, is an EXCELLENT Gmail-centric mail application. The user interface is stellar and it introduces some new and interesting ways to review threaded messages. I’ve been using it for a few days now and I’m very pleased with how nicely it has supplanted Apple’s Mail app. It IS missing one feature, however. Push. Sparrow had been beta testing push notifications but in the end, they decided to pull the feature because, in their best estimation, they couldn’t guarantee the security of users’ credentials.

On our side: if Sparrow was to do Push today, we would have to store your credentials (login/password) on our servers to frequently poll your accounts, and send you notifications.

This is a responsibility we’re not ready to take. As a startup focused on iOS/OS X development, we do not have the skills to secure your data on our servers and we do not want to put sensitive information at risk. That’s why Sparrow iPhone 1.0 doesn’t do push.

It’s very refreshing to read a post like that. Sparrow made a special effort to explain why they decided NOT to include a feature they didn’t feel was ready for production. They didn’t spin a PR yarn about why push isn’t needed or why removing push is better for users. It wasn’t ready. Apple won’t let them use the API they need. Here’s what’s going on.

Another recent example was Marco Arment‘s mea culpa regarding fonts (type-faces) in his excellent Instapaper iOS application. Readability, another very good “read later” app, introduced a competitive advantage by letting the user choose from a couple excellent font choices. At first Marco didn’t consider this feature much of an advantage but he eventually recognized that yes, in fact users may benefit greatly from being able to choose an agreeable type face.

I could have interpreted this defensively and complacently: “Georgia and Verdana are great, versatile, highly screen-readable fonts! I don’t need to do what competitors do! Newer isn’t always better! My crusty old fonts have some technical advantage that you don’t care about!” And so on.

Yesterday Instapaper 4.1 was released with some exceptionally nice-looking type-faces. Marco worked  hard to quickly bring a feature he felt he had fallen down on to his customers and the results are outstanding.

The lesson here is, if your product has fallen behind a competitor a bit, or was released without a feature you know your customers may been looking forward to, be honest with them. Most of them are your customers because they like you and your product. They’ll appreciate the transparency and, more often than not, will gladly be willing to stand by while you add the feature or polish you think your product needs.

Run Your Project Like You’d Run a Business

Last Thursday and Friday I attended the Philly Emerging Technologies conference in Conshohocken, PA. I’m not going to rehash or summarize all of the talks I went to but I DO want to focus on one particular talk and that is John Resig’s “How to Run a Successful Open Source Project: The jQuery success story”.

For those who don’t already know, John Resig is the author, and primary maintainer of jQuery, one of the leading Javascript frameworks. Comparatively speaking, jQuery is newer than some of the other frameworks like script.aculo.us, but has picked up enormous adoption in a fairly short amount of time. There is a reason for this. And it’s not JUST because jQuery is good.

As you might have guessed from the title of his session, John did not talk about how to use jQuery. This wasn’t a “kickstart” class. His talk was about how to treat your open source project, for lack of a better phrase, like a business.

Make it SUPER easy to get started.

One of the rules John went over was about making your project/product extremely easy to get started with. That means:

  1. Complete (and up to date) documentation.
  2. Easy to read documentation.
  3. Clear cut examples that actually WORK in practice.
  4. Make it easy to download!

If these all sound like no-brainers, it’s because they are. And you wouldn’t believe how many projects don’t follow any of these tenets.

Treat your users like you’d treat your customers.

Being available to their users for help and advice is something that some, but sadly not all, product-based businesses understand. For open source project owners, this means being active on your wiki, your forums, and your email lists. John had a great anecdote about a help request he received to his personal email account. Instead of ignoring the user or reeling off a terse “RTFM” response, he exchanged a few messages with them and eventually got them sorted. It turns out this user was a head architect at Amazon.com. You never know who your users are – treat them all like customers. Satisfaction guaranteed.

Track your trends!

The jQuery project makes HEAVY use of Google Analytics to track their adoption, usage, and attrition. Between the end of 2007 and beginning of 2008, the team saw a sharp drop in jQuery adoption and then a very gradual climb. Eventually they surmised that, for whatever reason, users and developers “forgot” what they were doing over their holiday break and came back to work in the new year with new priorities. To combat this anomaly, the team timed the most recent release of jQuery for the beginning of January 2009. The results showed that they still saw the usual post-holiday attrition but it was followed by a SHARP adoption which brought jQuery usage up to higher levels than before the holiday season. Some BUSINESSES don’t track usage trends this well! If this sounds a lot more like marketing, that’s because it is. People won’t come, and more importantly stay, just because you built it.

Build a team.

It may be surprising to learn that jQuery only has around 4 full time maintainers at any given time but the total team is comprised of about 25 people. The other 20 people complete the team and are what elevates the jQuery project to a level most open source projects don’t reach. There are dedicated documentation team members, evangelism folks, and example writers. There are people who monitor the forums, update the wiki, and keep the message of the benefits of jQuery fresh. One person can’t do it all. But a few dedicated people can make a HUGE difference in the “completeness” of your project.

Everyone has to start their project somewhere. However, if you are serious about improving the lives of your users, then treat your project like a product. Treat your organization like a business. Make it easy to adopt. Make the documentation and examples stellar. And above all, treat your users [customers] with respect and show them patience. It will pay dividends.