Winning the Muggles: Designing for the Mainstream

image Chris Dixon wrote a blog post last week titled, “Techies and Normals” in which he defined “Techies” as people who are not just “early adopters” but also have more of a geeky, technical, product bent.  Normals (or “Muggles” as Catarina Fake called them) are people who, unlike Techies, don’t just use products simply because they’re infatuated with them and with showing the world how cool it is that they’re using the latest tech product.  They use products because the products solve a need they have.

If you don’t already read Chris’s blog you should – it’s very well written, often takes a strong POV and speaks from an entrepreneur’s perspective but with a huge knowledge of the technology investors as well.  He is both.

Anyway, Chris’s blog got me thinking about Techies and Normals.  I think this is a perfect way to think about the world when you’re designing your product / company.  Quite honestly I see way too many company pitches that are designed for Techies but I only want to invest in products designed for Normals.  Here’s my take on the topic:

1. Start by defining the problem you’re solving.

I see way too many early-stage entrepreneurs who start their companies with a product definition rather than a market problem.  You can always tell these companies because they come in talking product, product, product.  ”And here’s how we integrate with Gmail, Flickr and Freshbooks.  Here’s how a user exports all of their data to a CSV file.  Here’s how we use oAuth to integrate the user’s social graph.  Here’s how users can show their friends what products they want to buy – let’s call that social shopping.”

Blah, blah, blah.  Now remind me, why TF would a person use your product in the first place?  It’s hard to get users to your website.  It’s even harder to get them to use your product.  As per Chris’s article, Techies will use your product.  Sometimes it’s to play around with new technology.  Sometimes it’s to brag to everybody else that they got the private invitation code.  I call the latter the “Emperor Has no Clothes” syndrome.

But either of these scenarios is part of the “TechCrunch bump” and it will come and go.  You will only build a sustainable company of you’re solving a real problem that people have.  I covered this a bit in my post about the market definition slide in fund raising

2. Explain how you’ll solve the problem.

image Kind of the obvious next step.  Once you’ve defined a problem that exists in the market you need to talk specifically about how you plan to build a product that addresses the perceived problem.  ”Problem: People don’t trust Craigslist anymore but still want to buy / sell goods to local people.  We solve that trust issue by A, B, C.  Problem: People using Service Magic are only given three potential vendors to do business with and each vendor has to pay whether they’re selected or not.  Our solution allows you to see many vendors and each vendor only pays if they are selected for business.  I talk more about this in my post about solving the problem in fund raising.

3. Assess your market size.

Most investors care about the size of the market you’ll serve.  You should, too.  The tech world is obsessed with cool features, the investor world is concerned with how big of a return they’ll make if your company is successful.  For you it may not be all about the money.  But whatever reason you’re doing this crazy startup thing make sure you do basic market segmentation and know the size of the market you plan to serve.  I cover market sizing in this post entitled, “It’s the size of the wave, not the motion of the ocean.”

4. Show me the money.

image I think many companies naively think that financial modeling is no longer necessary.  It seems to be the meme of Silicon Valley these days.  Launch a product, iterate, fail fast.  Bollocks.  That’s called laziness.  If you haven’t thought about how you might make money some day with your product you’re being exactly that: lazy.  I’m not saying that you need a 30-tab Excel spreadsheet modeling out 5 year’s of detailed profit & loss accounts with gross and net margins that would be realistic for year 5.

But you do need to give some thought to economics.  It’s a very important part of explaining to yourself (and your investors) what features are commoditized and should be free, what features you believe could be monetizable and whether you believe the money will come from primary sources (e.g. the user) or secondary sources (marketeers, data analytics companies, etc.)  Zero thought = flying blind.  I cover the topic of financial modeling in this post.  I think so many Silicon Valley firms skip this step because when you’re a developer your core competence is building product and not thinking about markets.  Or as I like to say, “when you’re a hammer, everything looks like a nail.”

5. Make sure you know whom you serve.

It’s one thing to define a market problem.  It’s another to understand the actual users who you will be serving.  This is an exercise savvy companies will go through in creating something designers call a “product persona.”  If you aren’t already familiar with this term please click and read the link I provided. It’s a very important concept in user created designs and too few companies do this.  You need to understand the mind of your potential user.  How they operate, what their needs are, what they do everyday.  You need to understand what other tech products they use and their technical competence.

If your product solves a big problem but is designed to be used by a small segment of users, that’s OK.  It means you won’t likely build a company for mass adoption, but not everybody has this as their goal.  My perfect example is delicio.us (which now apparently also has the domain delicious.com).  I first played with this product many years ago and immediately understood the value.  But I thought, “there is NFW that anybody other than a tech geek is going to use this product as designed.”  It was too opaque.  It wasn’t easy to figure out how you were supposed to use it and how to find other peoples’ lists.  I still wonder why nobody has solved this important problem for the masses.

6. Solve the problem, don’t “keep up with the Joneses.”

First time entrepreneur’s often get swept up in the “keep up with the Joneses” mentality.  They read the press releases of competitors or see them at a trade show and race to keep up with their feature sets.  Or even more common they notice that everybody is implementing (insert: posting results out to Twitter, integrating social graph with Facebook Connect, an iPhone App, augmented reality features) and they feel compelled to do so also.  Don’t build features that will wow tech journalists, raise eyebrows on stage at a conference or make your competitors envious.  Build features that will delight your customers.  Obvious, I know.  But you’d be surprised just how many companies fall into this trap.

7. Design for the novice, configure for the power user.

image This is the last point and one that I’m going to cover in more detail in a future post.  This is one of my favorite topics on good product design.  It’s my view and not necessarily accepted wisdom.  But I shout it from mountain tops.  Technology products that want mass adoption should be designed for novice users.  ”Normals” as Chris calls them.  Products need to be blindingly simple.  You take your User Persona and try to see the product through their eyes, not yours.

You then invite people who match this User Persona and watch them use prototype of your product.  There is only one way to really know whether you’ve achieved product nirvana: film users playing with your product and watch them interact with it.  I’ve seen this many times first hand and even your best attempts at designing “simple” products will surprise you when you see Normals trying to use them.

But my other point is that power users can always figure out how to configure your product to super charge it.  That’s what “Techies” do. So if you want to have lots of really cool product features that solve the problems of Techies make sure that they initialized using a tab or another configuration method.  Let them have the complexity they crave and are capable of using.  But then your core product isn’t bent to the needs of Techies at the exclusion of Normals.

Normals vastly outnumber Techies.  If you want mass adoption of your product you must serve Normals.