Here’s an internal brainstorm we did on how we’re approaching growing the company. If you like this approach and want to know more–just drop us a line!

It’s canonical startup wisdom that we need to go fast, fast, fast to succeed: the market changes, you need to make money to pay the bills before the money runs out, there are competitors running fast and you need to go faster than they do–yes, yes.

But there is another reason to go super fast, in one particular aspect of going fast, and in one way. This is what we can call, creating a fast “learning-to-launch iterative loop” (for a phrase I think I just invented now. Actually I should remove the word “iterative” and then it is just “LLL,” “learning-to-launch loop” haha!)

The short version is: we need to get stuff LIVE–into the real world and user’s hands fast, learn from their responses (subjective and objective), and then incorporate their feedback into our software and marketing/user acquisition. Then, once that’s done, make that live again to get another round of feedback on the software, then incorporate that into the software/marketing. Then once that is live, get another round of feedback, and then incorporate that into the software/marketing. etc!

Getting what we do live (so we can get feedback and data) falls into two categories: the software itself, and the user acquisition strategies / marketing / branding / etc. Both are deeply related to each other, but they’re the two halves of it.

Yes, we know that already: we know you need to launch, get feedback, and learn, incorporate what you learned–then go back and get more feedback, learn from it, incorporate what you learned, then launch again, etc.

This is nothing new! We all know we need to launch and learn, and then make changes based on what we learn. “Morgan, why are you just saying what everyone knows!”

I know, I know. But here’s the key part I’m adding to that: the length of that loop is THE MOST IMPORTANT FACTOR in determining our success or failure. The other things that matter (like Team! Culture! Technology! Processes! etc!) are all just INPUTS into that one factor. And by “the length of that loop,” I mean: the shorter each iteration of that loop (one round of “build, then learn” before the next round), the much closer we get to succeeding.

Look at it this way:

Imagine I launched a new product, “The Morgan ecommerce store” where you can buy lightbulbs. Okay.

Imagine this: I create the store and that takes me one year. And then I have one year of users using it. At the end of that second year, I know what users like and don’t like–so I can then go back and spend a year rebuilding / changing the site based on the feedback, and then another year seeing how people respond, etc. So my tech->learning loop is two years. Here’s the thing: you need to do 100 of these loops in order to discover the version of the product and the version of the user acquisition methods and what version of the branding works profitably. So, in this case, it would take 200 years in order to discover (since each loop is 1  year of building, and one year of testing it live.) So, you have to spend 200 years doing this, to succeed. (Note: yes, this is simplified, since in real life, there is some overlap etc.)

But now, imagine… instead of spending 2 years in each loop (1 year building, 1 year testing), instead I spent 6 months building then 6 months testing. So then my loop would be 1 year. So I would only need 100 years to learn.

Then, imagine… instead of spending 1 year in each interaction, imagine we spent 1 quarter in each iteration: then, it would be 100 quarters or 25 years.

Then imagine, one month on each iteration–then it would be 8 years.

And–oh my goodness, hold your breath!–if we had 2 week iterations, then we would only need 4 years!

Now, imagine we’re soooo good that, instead of needing 100 such iterations, we only need 50 such iterations. Now, with a 2‑week learning-to-launch loop and only needing 50, then the 4 years becomes 2 years. (Do you see how the Silicon Valley startup game is played?)

If we can shorten the loop of “build tech -> get it live -> learn -> make changes to the tech” (and the marketing version of the same “prepare some marketing / user acquisition -> get it live -> learn -> make changes to the user acquisition / marketing” then that is the difference between whether it takes us 200 years to learn what we need to learn or 2 years to learn what we need to learn what we need to learn.

Here’s an “open secret”: 100% of successful dot-coms have a really, really, really, really fast learning-to-launch loop time. They learn, incorporate their learnings, and relaunch with changes every week or two or three. Working in a way so that we learn fast is essential.

A few important notes:

  • Yes, a faster learning-to-launch loop entails trade-offs; there’s no such thing as a free lunch. Maybe you test simple versions of features. Maybe we don’t do huge design overhauls but tweak the current design. Maybe we test out things not fully ready but just “ready enough.” Maybe we use a less-than-ideal platform. Everything has a cost; I’m just arguing here that a super-fast learning-to-launch loop is so critical it’s worth doing a lot of real trade-off‑s to achieve it. A “janky,” far-from-ideal platform that really lets us see what the real-world market says about our software and user acquisition goes a long, long way.
  • Learning compounds quickly like interest. You want your interest to compound daily, not annually. 1% interest that compounds (ie, you learn to be 1% better than you were!), if it learning-or-financial interest compounds annually, after one year, your 100 learning-units is 101 learning-units. But if it compounds daily, after one year, your 100 learning-units are 3,778 learning units! The time-scale and speed matter enormously.
  • This is one one reason why I LOVE the WordPress angle because, on the marketing side, it allows us to learn, tweak, change, go really, really, really fast. I can make changes and tweaks on the live WP site at light-speed, launch landing pages, post blog posts, change footers, change texts, etc, to go go go and optimize for sales, branding, SEO, etc.
  • This also implies that, for our core software that it’s only good to use a “let’s do 2 week sprints, resulting in a push to production every other Friday” approach.