What Is The Opposite Of A Vacuum and Should You Develop Software In It?

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:


Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

What Is The Opposite Of A Vacuum and Should You Develop Software In It?


Chances are, that if you've been involved in the creation of software or any kind of product, you've probably heard the advice: "Don't develop in a vacuum".

A vacuum is a space that is essentially empty of matter (according to Wikipedia). It's a philosophical concept because practically it is not possible to have a space that is completely "empty". But, I like to deal in abstractions anyway, so that's good enough for me. "Don't develop in a vacuum" generally means not to go off and write code in the absence of customer feedback. This should not be particularly controversial advice. Developing software without knowing whether users will like it, based purely on speculation and conjecture doesn't seem particularly smart. I've never met a single person that has said: "You should go build your product in a vacuum!"

So, I think it's good to not develop in a vacuum and ask users what they think as early as possible and as often as possible. But, it's great to actually be users of the product yourself. This advice has been widely circulated too. If you build something you would use yourself, your chances of success go way up. The reason is not particularly complicated. It's more efficient to have conversations with yourself than it is to try and go find users. There's a lot less lost in translation as well. Rumor has it, the most successful products at Google (like GMail) are the ones that Google employees actually use.

So, if developing without user feedback is developing in a vacuum, then what's the opposite? Developing under infinite pressure? I'm not sure, and I'm not smart enough to stretch this analogy along this particular dimension. But what I do know is that "developing for yourself as a user" starts to present risks at a certain point.

Let me give you a real world example. My startup, HubSpot, develops inbound marketing software. For purposes of this article, it's not necessary for you to know what that means. Lets just say that many businesses need it as it helps find more paying customers and increase sales. We originally started building the product because we had the problem ourselves, and couldn't find a reasonably good solution. So, we built something we thought we'd use ourselves. And we do. We don't just casually use it either. We're extreme users. We run our blog on it. We get sales leads from it. We track marketing analytics on it. We live inside our product. We could not imagine life without it. Most of the time, this is a really good thing -- except when it's not.

Here's when it's not: At a point, you have to stop and ask yourself how representative you are of your potential market. If you're a lot like them, then you can get away with having conversations with yourself pretty often and not lose sight of the customer too much. If you're not like them at all, conversations with yourself are not productive. My startup is somewhere in between. Although we resemble our target customers a lot (we're a small business with 25 employees, we sell to other businesses, and we have real marketing people on staff), we're not a perfect fit. Most of our customers are not as technical as we are, don't read SEO blogs all the time and actually have lives . But, the biggest difference is that we know too much. Not that we're smarter, but we're just around the problem too much. We live it too much. We have people that think about nothing else all day. Hence, it's easy to over-complicate the product because it seems "obvious" to our internal users. They fly right through the new features. The solution? Go get good, honest feedback from real customers/users whenever you can. There's no substitute.

Summary: Don't develop your product in a vacuum. If you can, be your own customer. But remember that conversations with yourself can only go so far because you know too much and it's unwise to try and pretend that you don't.

What do you think? Are you your own customer? Have you hit the limit of how much feedback you (as a company) can give yourself? Would love to hear your thoughts in the comments.

Posted by Dharmesh Shah on Mon, Feb 04, 2008


its essential to keep customer feedback tightly in the dev-cycle. Making snapshots and UI tours of what could be on the table, gives users a fair enough idea.
I am dealing with an even tougher situation from user feedback pov. We are making Residential locality admin-cum-social application for the Indian market. Making snap-shots has really helped us understand what users think and want.

posted on Monday, February 04, 2008 at 1:53 AM by Lalit

Yes, I'd say "be creative" is the opposite. Also, a feedback, always tells you what the real problem is but the suggested solution is not necessarily the real solution.

posted on Monday, February 04, 2008 at 6:03 AM by alex

Most people never develop their ideas into products. So, despite it being good advice, better advice might be "develop something" and focus on the "in a vacuum" part, not the "don't develop" part.

posted on Monday, February 04, 2008 at 7:00 AM by Dan Howard

User feedback is a key step in development. But remember to get feedback from a large group of users...i've seen many times where some user's suggestions were not the best move to make

posted on Monday, February 04, 2008 at 8:25 AM by nyte3k

Just wanted to clarify my last comment. Building in a vacuum is cool but you should still keep your eyes and ears open. Arrogantly assuming that you know everything (and ignoring feedback) is a recipe for disaster.

posted on Monday, February 04, 2008 at 1:31 PM by Raza Imam

A quote from someone much smarter than myself...
"Users must be treated as co-developers, in a reflection of open
source development practices . .The open source dictum,
"release early and release often" in fact has morphed into an
even more radical position, "the perpetual beta," in which the
product is developed in the open, with new features slipstreamed
in on a monthly, weekly, or even daily basis. It's no accident that
services such as Gmail, Google Maps, Flickr, del.icio.us, and the
like may be expected to bear a "Beta" logo for years at a time.” -
Tim O’Reilly

posted on Tuesday, February 05, 2008 at 10:50 PM by Raza Imam

Comments have been closed for this article.