Designing a new product? The two most important features are…

Its been a few years since I’ve been in start-up mode: dissecting great products to learn, generating lists of ideas, and meeting lots of new people. In undergoing this process I’m reminded of my fundamental approach to developing a new product and how unusual it seems to be among other entrepreneurs. (This is actually not a new insight, I’m reposting this from a blog post a few years ago.)

When I have a new idea that I’m intrigued by that I want to bring into the world, the two most important first features I stay focused on are: (1) simplicity, and (2) community.

Let me explain. 1) Simplicity. Too many people create too many features way too soon. The most important feature in the first version of your product is that its simple. In one sense this is the absence of features, but in a very real sense simple is a feature in and of itself. Simple is achieved by distilling your concept down to its essence, by including only those features which are absolute core to your idea. Achieving simple is a very selective cutting of features: you don’t necessarily leave the easy features and cut the hard ones, you leave the essential/core features and cut the peripheral ones. Why? Because the most important goal at this stage of product development is that when a potential customer sees your product, they get what it does. You want them to almost instantly recognize the problem and understand how this product can potentially solve it. This first version of the product is a conversation starter.

When you’re trying to teach kids what a mammal is, you don’t start with the egg-laying platypus as the example. Likewise, you want your first product centered firmly around a quintessential use case. Lots of features you’ll add down the road will be added to address edge cases, real-world scenarios, but they’re a distraction at this first phase where clear understanding is the first goal. Its not so important that the first version of your product actually solve the problem, it doesn’t have to be ready for someone to dive in and start inputting real data and using it on a daily basis, the purpose of the first version of your product is that you can show it to actual customers and they get it and get excited about it.

This leads directly into feature #2, Community. There are lots of different forms that community can take at this stage: a forum, a regular conference call, group sessions; but the essential is that you create a regular on-going interaction between an early group of customers that you get to eavesdrop on and participate in. Note that this is not a bunch of people talking only to you, you want a small group of real customers talking about your product among themselves, brainstorming ideas, hearing what each other think and disagreeing.

Your goal at this stage is to build an early version of your product that is distilled down to its essence and then get a group of vocal passionate real customers using it, and then, only then, do you start really building the product with them. You start listening and responding and iterating. This distilled essentialized first version of your product is situated at crossroads. There are a lot of subtly different but significant ways you can take this product, but you don’t want to add the small features that push it down one of these paths. You want its essentialized form to stand on its own feet, and then you want this early group of customers to push it in a particular direction.

What happens if you dont achieve this? What happens if you build a first version of the product and no one really gets excited about it? Well, this means one of a few things. Either: 1) this is the wrong group of test customers, 2) this is the right group of customers but youre wrong about their being a real underlying problem, 3) theyre not understanding how this particular solution solves their problem.

Youre allowed to try again with a slightly tweaked and modified version of a distilled product, but dont make the mistake of thinking my customers need more real working features and start building, building, building. Youll know that youre making this mistake if, as you build more, your group of engaged passionate beta customers gets smaller and smaller. Youll know youre doing things correctly when youre group of engaged passionate beta customers starts getting bigger and bigger, both because some of the initial people who werent quite clear on it start to really get it and get excited, and because those who are excited want to start showing it to their friends.

Some tips to increase your chance of achieving this:

• Keep your product ugly, don’t get slick graphics involved at this stage. You’ll actually get better, more honest feedback if your product looks and feels a little rough. Implicitly this communicates that its a work in progress and they’re helping to shape it. If you show them a really slick product and they don’t quite like it, they feel worse about criticizing it so they wont, or you’ll start to hear feedback like, I can see how some people might like this which is code for I don’t like it, but a lot of effort went into this so I hope someone out there does!
• If essential features are hard to program, use lots of screen shots, mock-ups, and fake data. Real customers generally have bad imaginations, so even though you tell them, XYZ will happen when you click here, and the customer says oh yea, I get it they’re either being nice and have no clue what you mean, or they’re imagining something but its very different than what you’re imagining. You don’t want an illusion of understanding. Create a mock-up with fake or static data, put the most weight on feedback to stuff they’ve actually seen and clicked on, not on stuff you hypothesized about with them.