A little while ago, we had a great guest post here by Jason Cohen titled “Why
Your Startup Shouldn’t Copy 37Signals or Fog Creek”. In it, Jason makes
some great arguments on why you shouldn’t copy successful startups like 37signals. I (mostly) agree with Cohen. Blind
copying just doesn’t work for reasons Jason Fried (CEO of 37signals) outlines in
a follow-up article.

Here’s what Fried had to say:

“Here’s the problem with copying: Copying skips understanding. Understanding
is how you grow. You have to understand why something works or why something is
how it is. When you copy it, you miss that. You just repurpose the last layer
instead of understanding all the layers underneath.”

I (mostly) agree with Jason Fried too. When you copy, you do miss a lot of
what made what you are copying successful. But, although copying specific
things is ill-advised, drawing inspiration from and copying certain
practices can often work quite well.

Here are the things I think you should copy from 37signals:

1. Share your expertise. Whatever it is you are passionate
about or an expert in — share your information. Contribute to the community.
Help others learn. Blog, podcast, speak — whatever works for you. Jason and
the 37signals team are phenomenally good at this. They blog, they speak, they
wrote a fantastically practical
book.

2. Be your own customer. Try (if you can) to eat your own
cooking. A product works out much better when you use it yourself. Solve your
own problems. Fix the things that annoy you the most. Beyond just 37signals,
there are lots of examples where people built software that succeeded in part
because they use it themselves. GMail comes to mind.

3. Minimize unused inventory. Don’t write a bunch of code
that not a lot of people are going to care about and you don’t need
today. We have a tendency to “design for the future” and add features
or architectural elements with the expectation that they’ll be useful someday.
Wait for that day. You might “overpay” if/when you do get around to needing it
(because it’s more expensive to add things later), but on average, you’ll be
better off not writing that code that you don’t need just yet. This is not an
excuse for poorly designed software — it’s an argument for being selective as to
where you design in future expansion.

4. Take a stand. Have an opinion and take a stand.
37signals does a great job with their “less is more” stance. They have a
passionate position and are willing to defend and debate it. You don’t have to
take extreme positions on everything, but there should be something you feel
passionately about that you don’t just pick a happy, non-controversial
middle-ground. Ideally, it’s this particular idea that your startup is centered
around.

5. Charge early, charge often. There is no shame in
putting a price on your product. Doesn’t matter how early it is. Just give
customers an easy way out. Let them decide whether your product is
worth paying for. If not, keep cranking. Too many startups feel like they need
to have the “perfect” product before they can begin charging for it. That’s
almost always a mistake. Charge early. Once you start charging money, all
sorts of good things start to happen (for example, customer feedback starts to
happen, because you actually have customers). Then, try to charge as
often as possible. Instead of “big chunks” of money changing hands, try to move
to smaller, recurring chunks. Many SaaS businesses function this way (with some
sort of subscription or “pay by the drink” model). It works.

6. Contribute Some Bits Back: As you know, David Heinemeier Hansson, a
partner at 37signals is responsible for the phenomenally successful Ruby on
Rails. This benefits them more than the “positive karmic loop” thing. By
contributing to the open source community, they’re able to leverage the power of
that community and make the platform they use for their own stuff much better.
But, please don’t misunderstand me. I’m not suggesting you should go out and
try to build some platform/framework. In fact, please don’t try and go
do that (99.9% of us should not be obsessing over building platforms/frameworks
— particularly folks like you and me). Just find ways to contribute
back — even if they’re small ways. It’ll help in at least two ways: You’ll
develop better stuff and you’ll attract better people.

7. Build A Community: Software companies these days
are about more than just the product — they’re about the people around the
product. This includes both those that built the product’s users. Invest the
time and energy to foster a vibrant community that connects the people that care
about you, the company and the products. Allow customers to engage with each
other. This is useful not just from a “more value in the software” perspective
— but it also helps with respect to competition. If a big, 900–pound competitor
comes after you some day, it might be easy for them to build some of your
product features, but it will be much harder for them to steal your
community.

Are you a 37signals fan? Did you read “Getting Real”? If so, what other
practices or philosophies do you think they use that most other startups should
emulate?

Great compilation Dharmesh. One thing that Jason has been advocating lately is the concept of making by-products, the often missed opportunities of leveraging your main work and selling it twice (or even more times). By the way, I´m anxious to see their new book...

My favorite 37Signals advice is that planning is actually just guessing. Start-up companies rely on their agility and by spending too much time planning, you're really just limiting your options in the future.

That's not to say you shouldn't be prepared for different scenarios, but it's normally a mistake to assume that you can predict how things will play out in the future.

def read "getting real" must read for stratup entreps. I don't remember the exact phrasing but essential lesson is "start small, launch early and often" I think many people sit on the sidelines with a good idea becuase they feel like everything has to be perfect, "market, team, funding etc., etc". which of course is rarely the case. Throwing up a less then perfect product teaches you so much about the actaul oppertunity and what needs to get done to make it sucessful.

I am a huge fan of 37Signals. Read the book and can hardly wait for the next one in March.

Building for yourself and solving your own problems is a real eye-opener. I had often thought about it, but never implemented anything. Once I built an app for myself, within the first week I knew what it needed and didn't need. Using it yourself will give you incredible insight.

As far as copying, I have been screaming foul about copying for awhile now. Mainly in the JavaScript world. IMO too many devs are grabbing plugins/frameworks when they are not needed. They are using them for everything. In return they do not understand what their code is doing. It's gets to be a mess real fast.

Copy the idea, but use your own implementation.

Rajat

In their book 'Getting Real' they have mentioned 'Less is More', but less doesnot mean less in form of all the features. That is to say if you were planning to build 10 features in your product, instead make 4 or 5 but build them well and launch early.In other words the most important feature or the feature that you think will make the product to sell, should be done in the best possible way, and other features can be thought of later

Is it just me, or is "Minimizing unused inventory" one of the hardest cards to play?

As an entrepreneur, your partners and investors constantly want to see what's down the road...and they expect your product to do the same.

What's the best way to get around that (other than simply ignoring them)?

James

My small company operates on a new but a highly competitive market. You would not believe what all the companies on this market do to get customers. Only be having a free version and offering outstanding support for free have we been been able to get a significant share. It is a huge gap between using something for free and having to find your credit card. Will see if we can ever monetize it.

I think its true, lots of people try to copy what they think they see happening, however, without a true understanding, they waste time and energy.

Dr. Letitia Wright The Wright Place TV Show http://wrightplacetv.com www.twitter.com/drwright1

Chris Neal

Great post Dharmesh.

I see these as "patterns" that can help you define and grow your proposition - but as you point out you first need to be very clear about what your product is about, what problems it solves and focus on delivering the core features that resolve those needs.

I read the 37signals book after seeing it referenced here. It's a good book and has nuggets of valuable information.

A good number of points mentioned in the book are pretty natural for a startup. You don't really have to read a book to watch out for it. If there is no funding, you are clearly constrained in time, features and functionality. I disagree with some of the points mentioned in the book from my experience so far. But, who cares? People want to hear from other people who are already successful. That's how humans are trained!

You don't get to hear from a pile of startups which more or less followed the similar approach as in book, but still failed.

At the end of the day, no matter how great the product is, you need to have lot of luck and a really good sales team. A good sales team can pretty much sell anything.

While I really enjoy much of this article, I have some issues with "#2 Be your own customer. Try (if you can) to eat your own cooking."

I think it is the default IS to build something you know, for whom you are the customer.

However, I also believe this can get in the way of good business.

When the owners/employees believe they are the target market, it is so easy to not do the work to listen to the actual target market or to agree with what the target market says when it disagrees with what you feel/want.

So while 'eating what you cook' allows you to make some intuitive and quick decisions that you otherwise might not be able to make, it also skews you towards believing how great the food tastes because you made it and how everyone else will love it because you love it.

Being your own customer also tends to keep your emotions involved at what can be an unhealthy level. For example, one rule of business is that sunk costs are irrelevant. If a cost is truly sunk then it has no impact on current decisions and should not be taken into account. But when the sunk cost is a feature that you want that is halfway implemented but testing poorly with the target market, it is hard to get out of your own way and you will tend to argue that the sunk cost part of the feature is a good reason to sink more costs into completing it.

So, sure, be your own customer, but make sure that you rigorously seek the target market's input and let them, not you, rule the product.