Start early
Creating and running a tech startup is no mean feat. In addition to coming up with the idea, fundraising, recruiting and selling, it involves lots of… well… tech. You’re likely going to need to set up hosting services, code repositories, analytics, CRMs, CMSs, VPNs, CDNs and a host of other three letter acronyms. You’re looking at weeks of work just to create your infrastructural table stakes (the bare minimum) and that’s before you start working on the stuff differentiates you. Your system architecture is unlikely to be your UVP (Unique Value Proposition) but it’s necessary.
But what if you didn’t have to do it all (yet)? What if there was a way to delay the time spent on coding—never mind fundraising or recruiting prematurely—to focus on refining what makes you special. What if there was a way to prove that you are on your way to finding the proverbial product/market fit before spending all of your time and resources on something the market doesn’t really want? I’m here to tell you that there is — you should fake it before you (have to) make it!
Fitting in
“Product/market fit is being in a good market with a product that can satisfy that market.” -Mark Andreesen, VC at Andreesen Horowitz (2007)
Zappos’ founder, Nick Swinmurn’s early-day hustle is probably the best example of proving out a hypothesis before spending resources on building. In 1998, five percent of shoes were sold through mail-order catalogues and Swinmurn believed that he could beat those numbers with an online version. As he told Business Insider (2011), he “went to a couple of stores, took some pictures of the shoes, made a website, put them up and told the shoe store, if I sell anything, I’ll come here and pay full price.” By faking it, he confirmed that people would be willing to order shoes online without trying them on.
Swinmurn had proven product/market fit before setting up a warehouse, buying thousands of shoes or building out a complex inventory management systems to handle the supply chain.
If you are struggling to find an analogue in your business idea, consider this, what could you do manually (by hand) or personally (by yourself) that you envisioned coding or hiring for in order to fulfill a customer need today? Could you manually respond to text queries while building your NLP chat bot to see which queries surface most frequently? Could you deliver the order yourself before hiring drivers? Could you manually create travel policies before coding up an algorithm (that’s what yours truly is doing) to do it automatically? Just because you’re the one making the cold call or hitting “send” the on-boarding email doesn’t mean that that is how you’ll run your business for life. As Paul Graham, founder of Y-Combinator is famous for saying, “Do things that don’t scale.”
Graham’s point is larger than mine — he applies this principle to early stage attention-to-detail, sales, customer support and more.
But also addressing manual processes he says, “This lets you launch faster, and when you do finally automate yourself out of the loop, you’ll know exactly what to build because you’ll have muscle memory from doing it yourself.”
Expectations meet reality
Without the insights gained during the personal pain/inconvenience of faking non-scalable things, you very well could be building the wrong thing first. You may assume a linear development roadmap to match the expected customer journey through the product (Sign-up, Onboard, Collect Payment, Reporting Dashboards etc.) but by manually doing things, you can work out where you get the largest return on your time and cash investment and achieve the greatest efficiencies. It is possible that manually on-boarding users directly through SQL or Postman only takes you two minutes whereas copying and pasting stats from a database into a reporting table or email takes you an hour.
Although sequentially on-boarding comes before reporting, you should logically remove yourself from the larger bottleneck by automating reports before automating on-boarding. Not only will you have gotten to market faster by manually doing as much as you can, you have also encountered all of the possible permutations that your reports need to accommodate and can build a better product.
Another benefit of manual processes is that they force you into the world to experience your market first hand.
When you’re starting out you often have a good idea but a bad grasp of the market you are entering and in order to reach that mythical-but-neccessary product/market fit, you have to get to know your customer deeply. You can’t isolate yourself “building” if you’re the one responsible for responding to that customer support chat, delivering that sandwich or writing up that policy.
Instead of blindly building what you think is a good idea for an unsuspecting market, you are becoming intimately familiar with the people you think are going to be paying you.
This approach lines up well with the concepts of building an MVP (minimal viable product) and lean startup methodologies as you are building just enough to get by, and interacting continuously with your customers as you manually fake processes until you have to make them. Then, when you need these manual processes to scale, you know what’s most urgent based on your available resources and what’s most important based on the deep insights gained from interacting with your customer, making Dwight D. Eisenhower very happy, “What is important is seldom urgent and what is urgent is seldom important.”
If you fake it till you (have) to make it, your development, recruiting, sales and even fundraising will flow much more naturally as you’ll be armed with newly-gained:
• Intimate market knowledge So go out and do things that don’t scale and fake it until you (have to) make it!
Part 4: The only thing that matters
• Initial customer traction
• Prioritized roadmap
• Product/market fit
• Answers to questions you wouldn’t have thought about beforehand
Sources:
