Build, market, measure in parallel

By Elizabeth


Photo Credit: LabelMeHappy

First-time web entrepreneurs often tell me “Oh we’re moving really quickly…we’re launching in just 6 months.”  And, then these terrible flashbacks go past my eyes.  A couple years ago, I remember saying the exact same thing to myself.  Just 6 months.  The trouble is that product traction isn’t just about getting a product out the door.

Your biggest competitor isn’t any company or individual.  It’s time — the duration you have before you run out of money, morale, and the enthusiasm your significant other/family has for your endeavors.  The trouble with my last company was that our experience in software development came from large companies, where your job is just to ship code.  So we thought that a launch was just about writing the code.  And, we did that in 6 months.  But, what we didn’t account for was that in a startup, you don’t have a ready large group of users just waiting to use your product. So, your launch time must also include a cycle of user experience and marketing.

Since my failed company, I’ve learned there’s actually two kinds of time.  There’s work time, and there’s calendar time.  The former is in your control.  That’s the actual time it takes you to do work: code, write blog posts, write emails, etc.  But calendar time is much trickier to control. Calendar time is the total time it takes to get something done, inclusive of your work time but also inclusive of time it takes for other people to do things like use your application, give you feedback, take the time to talk with you, and respond to your emails.  So, if you need to build user experience and marketing into your launch time, calendar time can be really long and unpredictable.  You have no idea how long it will take for people to respond to your Craigslist post or get back to your emails.  You have no idea how long it will take for SEO to kick in.  Or, how long it will take before word of mouth will take hold.  And, worst of all, you have no idea if any of these things will even happen at all.

So, if you do everything in series in a drawn out way like we did: build, market, measure, it’s a cycle that can turn months into years.  Eric Ries suggests that shortening an iterative loop and going through such a loop multiple times quickly is the key to success.  I would take that a step further and suggest not only cutting activities to shorten that loop, but to do as much of this loop in parallel.  Our workflow looks like this: get your Unbounce or LaunchRock page up from Day 1 and start marketing before you have a product.  You can gauge interest and get signups from the very beginning until you’re done with the first iteration of the product.  Start getting the Craigslist posts out there on Day 1 to get feedback and potential customers immediately.  Once you have enough of an idea of what to build, start mocking up your idea.  Get those mocks back out to potential customers to make sure you’re on the right track.  Iterate as much as possible on paper before building, because it’s much faster to re-draw than to re-code.  ”Delete features” on your paper prototypes as well, reducing what you need to actually build in code.  Try to code as little as possible to shrink that build time to about 1-2 weeks.  By the time you’re done building your first prototype, you’ve already acquired users from doing marketing in parallel.  This puts you in a position to start measuring usage and gauging interest immediately before iterating through that loop again.

Build, market, measure should happen as much as possible in parallel to reduce your launch time and keep your money, morale, and support up.

For more tips and resources on starting a web business without coding, visit LaunchBit.


  1. OpLaunch says:

    You provided an insightful story to distinguish what you called ‘work time’ and ‘calendar time.’ Within this framework, serial and parallel are two common development models. I have found that a third option provides a better model. An development effort under this strategy minimizes the time from concept to abundant new product sales. It maximizes efficiency, effectiveness, cooperation, and collaboration. In this preferred culture, someone who may have traditionally considered themselves a coder (or any other domain specialist such as designer, marketer, or writer) shifts to a new product developer that specializes in a particular programming language. In this culture, there are a significant number of T-shaped individuals that seamlessly move between disciplines so that they have a holistic view and a system impact – which includes abundant sales and positive word-of-mouth.

    • Charl says:

      Ahahahah! Che polli, hanno corretto il titolo nella pagina dec’tarlilolo ma la prima pagina della sezione “Scienza e Tecnologia” ancora dice “ne paghi uno, ne prendi due”… e di questa ho uno screenshot >:-)–There’s no place like Ubuntu è una antica parola africana che vuol dire “Debian è troppo difficile da installare”

  2. obvio171 says:

    Love the T-shirt :) And good point about waiting on users for feedback. The question though is, after developing a version and while you’re waiting for the part of the learning cycle that depends on other people, do you spend your limited time and resources pushing that version to users to speed up the cycle or do you test other ideas in parallel? For the parallel thing to work you have to make sure there’s very little left you can do to speed up any of the tests you’re already running, and there’s always so much you can do!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>