This is part 4 in a series on startup lessons learned.

People are very, very good at smelling authenticity. Without this ingredient you will fail to create a self-sustaining community, be it online or in the real world.

I think we did well on the authenticity front with 5 Blocks Out. Our community members added real tips and real photos of real places they really cared about. Many business owners added their own content too, which was great, save for the few times someone was not up front about their identity.

We encouraged folks to use their real names on the site, and almost everyone did. We also gave everyone a publicly visible profile page, which helped a lot in terms of accountability. (There was no ability to comment anonymously.) I think we could have gone even further down this track by using mobile phone numbers or physical addresses as more weighty means of confirming identity.

We suffered a spate of spambot user account registrations for a while, and fought that back to a standstill. Painful. Days wasted.

The real test would have been our ability to maintain a high degree of authenticity at the scale of millions of members. That’s a really hard problem, and I don’t envy search engines and sites like Yelp and CraigsList in having to fight that fight every day. I wish a white knight would come along and provide a better authentication solution so that little sites wouldn’t struggle to reinvent the wheel on user identity and authentication (poorly) every single time. I’d pay for that!

This is part 2 in a series of posts on startup lessons learned.

This article is about the importance of investing in design before writing code.

If the design of your product is flawed from an end user perspective then all the shiny implementation technology in the world won’t help you succeed. So get the design right first.

Step away from the keyboard. I’m talking to you, programmer-type person.

It makes more sense to go as far as you can in proving your product concept (and hopefully disproving some parts of it) cheaply, with pen-and-paper sketches, mockups, slide shows, surveys, face-to-face discussions, and the like. Only when you hit diminishing returns on this AND you’re fairly certain you’ve found a market for your product design should you get heavily into designing software architecture and writing code.

I am not just parroting shit I read in the latest book on how to build products. I’ve learned this the hard way, having done the opposite for too long.

Why design first? Because exploring in code costs way more than exploring on paper. In a given unit of time you can explore easily 10x more ideas via pen-and-paper sketches than code. What’s more, your willingness to try new things will be higer. Your latest napkin sketch idea doesn’t pan out? Throw it away, sketch another, no big deal. Your latest code idea doesn’t pan out? Well… it took longer to create… perhaps we should refactor it instead of casting it aside?

I am not saying that exploring a product idea with code is bad. Just that it is more efficient to do once you’ve explored in other, cheaper ways first.

It’s harder to walk away from code. The sunk cost is higher. And so code tends to have far more inertia than a paper sketch. People will usually fight  much harder to keep a line of code than to keep a pen-stroke on a piece of paper.

We created literally thousands of paper sketches of design concepts for 5 Blocks Out, and I’m thankful we did. But we also committed the error of writing code in parallel with that design exploration, right from the outset. I justified it as “infrastructure we will surely need”. I was wrong; it turned out we didn’t need a lot of the code I wrote at that early stage. Most of my time at that stage would have been better spent helping on the design and validating our thinking with customers. Yes, really, most.

Using Ruby on Rails as our main technology made it even cheaper (and more tempting, and fun) to explore in code. I would have been much less of a cowboy if I was still coding in C!

Thinking back, several teams I worked on at Microsoft did the exact same thing. The circumstances were totally different, of course. In any case, we were unable to resist the urge to write code prior to figuring out a solid direction for the next product version. And this urge is much harder to resist in a big team…

the clock is ticking, money is burning, we have all these typists here, shouldn’t they be typing?

(The Microsoft in me says, “Don’t be ridiculous, we had awesome devs on our team ready to move mountains. Did you honestly want them to sit on their hands and do nothing until we had a design in hand, or worse, move to another team?” It’s hard to answer yes to that, especially as a manager. But the answer really ought to be yes. Work on design instead. Figure out what the product should be. Then get into architecture, which is a more detailed and expensive type of design. I wish we had done that instead of writing so much code that, in the end, we wanted to throw away. And sometimes did, but often couldn’t bring ourselves to.)

Unlike a paper sketch, code in a product has an ongoing cost. You need to test it, deploy it, support it, and integrate it with all the new code you write from then on. So if it’s code you should not have written in the first place, well congratulations, you’ve just created a perpetual inheritance tax.

I also realize now that the mere existence of working code short-circuited our design process. We could and should have explored further on paper but stopped because we had working code already. Code anchors design thinking.

So design first. And if you don’t have a great deal of design skill then try to partner up with people who do. And then listen to them!