We really hope this is some sort of sick joke on Mini’s part. In fact, we half-expect it is. But I would like to take this opportunity to discuss an important part of developing useful applications: Don’t waste time and resources developing something for which you have not yet solicited feedback. The trade-offs between openly sharing, and being “stealthy” can be quite one-sided. But first…

Background: Mini’s Mission Control

Typically, I am very pro-Mini. They are amazingly fun to drive and to auto-cross, and I came very close to owning one in the recent past. However, their latest feature, available on the limited Mini 50 Camden Edition, has everyone scratching their heads.

The best way I can describe Mission Control is that it’s what your car would sound like if it were a spaceship, and it had a crew of 3 people in addition to you, the pilot. It is 10% useful information read aloud to you (current fuel level, adverse weather warnings, etc) and 90% inane dialog between those 3 other crew members. And by 3 other crew members, I mean that the car talks to itself in different voices while you listen. In that respect, perhaps it’s more akin to what your car would sound like if it had multiple-personality disorder, and you were stuck in the middle.

But enough description, check out the video Oh, and this “feature” costs $5000.

Be sure to check out AutoBlog’s reaction as well

Get Feedback Before Development

In order to make this post at least a little on-topic, let’s see if we can derive some sort of lesson from this faux pas. Let’s say we’re developing a web application (LeadNuke for example). If we follow Mini’s example, we would spend weeks (I’m assuming this “feature” took Mini some time to develop) developing this ground-breaking new feature called Mission Control.

Our Mission Control feature would be incessant dialog boxes that popup every time our server is doing something. These popups would let you know, in a cute British accent no less, what exactly our server is trying to do.

“HTTP Connection established, love!”

“Returning javascript to manipulate the DOM, Great Scott!”

Now, anyone could anticipate how annoying and counter-productive this would be. But in many scenarios, this is not quite so obvious from a developer’s point of view.

The Useful Feature That Wasn’t

In fact, I recall one such instance a couple years ago, when I was developing RateMyStudentRental. I had a “eureka!” moment. I decided that one of the problems with searching for rental housing was that, a rental that meets your criteria exactly is rarely available when you need it. So, I thought, what if I create a new feature called a Watch List. You can input your criteria, and the site will alert you when something becomes available. If you started your search early enough, this could make the entire process passive and automatic.

I receive minimal feedback, and everyone (like myself) thought it was a great idea. I spent a week developing it (I was still a full-time student at the time). And when I launched it in a wave of triumph… no one cared. To this day, I believe this feature has been used only a handful of times.

You could argue that it was presented properly, or maybe it wasn’t marketed just right. But the point is that I could have spent that week developing something much more useful. Perhaps I could have fulfilled a request ticket that someone actually submitted.

Get Feedback Before Wasting Time

The point I’m trying to make here is to get feedback before you waste your time with anything, whether it’s a new feature, or maybe a new startup idea entirely. No one will steal your idea. And if they do, who cares? You’ll execute it better anyway, because it was your idea, right? The trade-off between sharing your ideas, and keeping them in secret “stealth” mode have been very clear for us.

Don’t be Mini. Don’t waste resources. Don’t develop before soliciting feedback. Otherwise, you might just find yourself the punch-line of a very un-funny joke.