What Furnishing an Empty Apartment Teaches Us About Feature Requests
I’ve had the privilege for two years of being part of an AlphaLab alumni panel that takes questions from the newly selected class. One of the questions I hear over and over again is about product features. First-time entrepreneurs and “I can build basically anything” hackers both struggle with identifying and prioritizing features in order to deliver something substantial within the small pocket of time between now and Demo Day. The answer has always been the same: Listen to your users. But entrepreneurs often cite Henry Ford as saying, “If I had asked my customers what they wanted, they would have said a faster horse.”
Well, let’s come back to Earth and realize that we’re building online software and not the future of transportation. Most of us have a practical problem we are trying to solve, full of just enough innovation to potentially be a success (a lucky few are creating something truly amazing). Innovation does come from individual thinking (the “aha” moment), but listening to customers is the only way you can understand what they need in the first place. We’ll never know, but perhaps if Ford never heard someone complain about the inefficiency of buying horses, watching them get old and slow, and then dying, we’d be trotting to the grocery store today.
While I’ve written about this subject in the past, the focus of that article was more on prioritizing features, and not how to use customer feedback to drive early product development. This article focuses on uncovering essential product features by leveraging the intelligence of your customers. So, when you have no product, and just a dream of the solution, how do you pull back from that dream and leverage your early users to help you identify what’s essential?
My answer is you treat early feature requests as if you’re furnishing an empty apartment.
Step 1: Cover the Essentials
Let’s say I just got the keys to my first apartment—ever. I have $3,000 to furnish the living room—no more—and I have no idea what I should buy first. So I invite you to my brand new apartment and take you into the living room, which is just four bare walls. (So far this sounds like a trashy romance novel.)
Help me out. I have $3k and I need to prioritize what to buy with the cash to furnish the room. Again, assume I have no clue what to buy—absolutely no clue. In your head, name 2 things I should buy first. Got them? Now I bet two of these match what you were thinking:
- couches
- TV
- TV stand
- end tables
- lamps
- coffee table
- DVD
- stereo
- plants
If I was completely off, you do not need to read the rest of this article and my metaphor sucks (and tell me what you were thinking in the comments!). But if I nailed one or both of your items, that’s because you drew upon your experience and needs to help “ignorant me” understand what is essential to furnishing a living room in order for it to be useful. And you’re no genius because you could do this.
This is exactly what your early users will do for you. In a featureless application, the first things people will notice are often the “duh” features that are missing. Without them your product is useless. Why think about a ceiling fan if you have no couch? Why think about “video conferencing for interviews” when The Resumator doesn’t handle “manual resume uploads”? People need to be able to get their existing resumes into The Resumator before it’s the slightest bit useful! Video conferencing is not just icing on the cake—it’s an extra layer of icing!
While all feature requests should be considered carefully, those requests from early adopters should be seriously considered for implementation, especially when they seem obvious and are easy to implement. You need somewhere to sit—get a couch! No one is going to come to your apartment one year from now and say, “Why the hell is there a couch in the living room?” Early feature requests can of course dip into the user-specific, but often they are just obvious—just not to you. You’re not winning any medals for innovation here—implement early requests that are simple and visible to the end user with confidence they will not bite you later on.
Step 2: Add Character and Uniqueness
Once you nail the essentials in your Web app (or apartment), it’s time to try and take what is a functional skeleton and turn it into something that is engaging and noteworthy. This is not easy, but luckily I think there are few strategies for adding unique character to your Web app:
Strategy 1: Paint, Pillows, Plants and Potpourri
So now my living room has all the essentials and is functional, but things still look a little bare. I don‘t have a lot of money, but I want to decorate so that when people come by, they have a pleasant experience. With just a can of paint, a few pillows, some plants and (for the ladies) some sweet smells, I can create a well-designed living space that masks my room’s shortcomings. Heck, painting one wall in a dingy apartment makes any space look better.
I believe in something I call “the façade of great design”. Great design can get you very far. In its early days, I heard many stories about people being drawn in to Mint.com by its beautiful interface design and ease of use, and then panic a week later when they realized they were sharing their bank account information with a brand new company (even though Mint uses the same security as your bank). Mint has many more features today than it did when it launched, but I believe great design was key to early adopters sticking with the product even though it was asking for some serious personal information.
If you work hard on creating a wonderful user experience through great interface and interaction design, you can get by with less features for a longer period of time. If your application feels cutting edge and progressive, users will want to stick around and see what’s next. Their experience using your app is pleasant, so they will come back again. There are many web apps that are successful because of good design and usability, not features. 37signals thrives on this concept. Web 2.0 was all about decentralizing the Web into a series of interconnected and easy-to-use online experiences. If you focus on usability with the few features you have, and create a fantastic brand, you’ll get an early start on creating a loyal customer base. (BTW – this was my strategy with The Resumator.)
Strategy 2: The Tricked-out Entertainment Center
Now let’s suppose I don’t have a sense of good design (or at least I don’t want to tap into it) to add paint, pillows and potpourri. Instead, I want to be the guy on the block with the wall-mounted, 55-inch Samsung TV connected to an Xbox, Blue Ray disc player, digital media center and Dobly surround system. I want people to say, “Did you see Don’s setup?!!!” and ignore the fact that I have no kitchen table and I reuse disposable plastic cups. I feel as if I can have one incredible area in my apartment, I can be the talk of the town.
What if you focused on one part of your web app, and blew it out into infinity awesomeness? What if you chose one mission-critical feature that, when fully functional, would blow a VC away? This is a strategy for building an app. Focus on one important feature and make it as incredibly useful (or awesome) as possible. I would argue the online document viewing company Scribd did this. By focusing on developing a very attractive and user-friendly document viewer, along with an incredibly reliable document processing queue, Scribd proved to many that despite our pains with reading documents in Acrobat Reader, there was something awesome about instantly embedding any document into any Web page with its exact original formatting—reliably. A few years and nearly $13 million VC dollars later, Scribd is expanding into mobile document viewing, securing key partnerships and publishing deals primarily (in my opinion) because that tricked-out Scribd Reader just seems to be so easy to use. And by focusing on it early, they are simply tweaking it to make it even more awesome. (Note: I have no clue how I ended up with awesome and infinity in this paragraph. I never use those words in real life!)
Strategy 3: The Bull Riding Machine
If you’re the type of person that really wants to make a splash when you lease an apartment, you know you need to have some off-the-wall “thing” in there. Something that people come over just to see. Something that everyone in the building talks about (good and bad). You risk being branded a weirdo or crazy, but you also have the chance to be known as the only person or business within 500 square miles that actually has a bull riding machine. That’s something the neighborhood will talk about, and the fact that it’s the only thing you have in your apartment makes in even more intriguing.
Perhaps the most risky (and rewarding) strategy for early product development is to try and do something that sounds so ridiculous that if it works, you’ll look like a genius. Try to build something completely off the wall into your application and learn from the reaction. LOL Cats is exactly this. Putting text on pictures of cats makes no sense as a business, but that business is doing pretty well. They learned that ordinary people can be extremely creative, and that creativity is viral and can be monetized. Foursquare is simply mobile-based check-ins at locations, but the odd popularity of “checking in” is giving everyone a glimpse of the future of hyper-local marketing. Remember FuckedCompany? That guy is now a EIR at a prestigious VC firm. The guy who from I Wear Your Shirt sells virtually every day to a sponsor. He just wears shirts.
If you’re going to go for innovative, there just simply can’t be any clear rationale for why you’re building what you’re building. Your idea needs the strong smell of innovation with an odor blast of failure. No one is going to tell you to buy a bull-riding machine for your apartment. You need to develop something that exists no where else.
Conclusion
Don’t waste time learning what users need. Build something minimal and get it out there. This is just my two cents for how to plan your first apartment, or Web app. You can always return the mechanical bull if you have the receipt.
Very intelligent article. It truly lends itself to the idea of working smarter, not harder. Apps and program development should follow the same premise.