Manual Automation — How to build software with no code

We don’t know how to code, yet we built and sold online businesses.

Originally published at hackingrevenue.com

We’re a business person and a product person who always wanted to learn how to program, but just never gave it enough effort (that’s what we like to think).

We can put together a WordPress website and we have some fancy badges in CodeAcademy, but no CTO in his right mind will let either of us touch their production environment and/or keyboard.

But we do know how online businesses work. We know the tools, we know the methods and we know how to hire and manage people.

We spent years studying the ins and outs of online business models and growth techniques.

Most of them we tried on our own while building 2 full scale startups and god knows how many more small online businesses.

We succeeded in some and failed in most, but we learned one thing that is always true:

It’s always faster to start with Manual Automation.

Paul Graham would call it “do things that don’t scale”, but we’ll stick to Manual Automation.

Manual Automation simply means that you’re building the product you have in mind using manual methods at first. For the end user, it will work exactly the same as if it was fully automatic and developed in the traditional way. However, the process behind the scenes is extremely faster.

Today we’re going to share with you our guide for how to start using Manual Automation with your online business or product.

Here are a few examples of manual Automation systems we built or helped build recently:

• A system that sends personalised emails to clients at specific times, based on their actions
• A system that manages the billing process of users
• Prospecting tool for generating new leads
• Crawling and comparison engine for our previous startup TapDog (which we sold)

The takeaway here is that without writing a single line of code, we were able to achieve what usually requires coding hands, AKA developers.

Why is that better, you ask?
Because developers have a habit of raising too many issues about end cases you didn’t think of, and they don’t seem to appreciate it when you answer them with hand gestures instead of written requirements. They also tend to frown upon you requesting them to change parts (or all) of the code they already wrote, whether it’s a bug, or a bug disguised as a feature.

Now don’t get us wrong, some of our best friends are developers (sorry David). It’s just that when building a product, many times it’s easier and faster to start with as little code as possible.

The tools in our toolbox are the same as in everyone else’s. But the process is different.

If we have an idea, it automatically (but manually) goes into a mental framework of “how can we do it manually”. This may be the result of our own handicap, but it proved itself to often be the quickest ways to get results, even if coding resources are available.

Rapid prototyping, MVP, MMF — call it whatever you want. The goal is always the same — make your vision come true as soon as possible to validate one of two options-

1. You’re a fool who should go back and sit next to their 9-to-5 desk.
2. You’re on to something and can now look forward to years of depression, anxiety, excessive travel and sleep deprivation working on your business. Don’t worry about it. There are worse addictions.

Back to the point.

Automatic → Manual

Transforming an automatic process into a manual one is not complicated, but requires a shift in mindset. You are no longer in “innovation” mode. You shouldn’t focus on “cutting edge technology”. You just care about getting your idea out there. Take this piece of data from point A to point B and make it nicer with tool C.

Examples for traditionally automatic processes that can be manualized (we’re making it a thing. Deal with it):

• Scraping and Crawling
• Comparing
• Testing
• Dispatching
• Recommending
• Thinking (this is where the magic happens)

As long as the volume of tasks is reasonable (we’ll define what is “reasonable” soon enough, little grasshopper) there aren’t that many things that can’t be handled manually. Even full products, not just proof of concepts, can and sometimes should be built manually.

If you can define an accurate business logic and the core product functionality, which we refer to as “the flow”, you can build by yourself almost anything you would usually build with developers.

In case you missed it so far — we can’t code. Which makes us, in some circles, useless mofos.

Us, just staring at the screen.

But that’s not why we start by doing things manually. We believe in this system because it allows us to vet our ideas with a minimal investment of time, effort and money.

“Wait wait wait” said the smartass developer. “Nothing is new here. Every line of code is basically the automation of something that can be done manually. Computers can’t think, they just execute really specific orders really fast”.

“Yeah, so?”, we said.

The empowering, liberating feeling, that you have when you take your ideas and make them a reality in a week, is astonishing. It’s a feeling that belongs to the world’s most efficient and experienced makers — artists, developers, builders. It’s not a feeling you get to enjoy if the only thing you can build is another pitch deck.

But it’s achievable, using Manual Automation.

There are 2 concepts you need to master if you want to apply Manual Automation to your ideas:

• Tactical Planning: How to break your idea’s product flow and logic to the micro task and articulate it using the simplest human language.
• Labour Arbitrage: How to find, sort, train and manage the people who will execute on your micro tasks accurately, quickly and cost efficiently.

Each of them takes time to learn and to be really good at, but with patience and with enough guidance — anyone can do it.

“Mechanical Turk” screamed the smartass developer. “What’s the difference?”.

“Developer, please”, we said.

Mechanical Turk is one of the ways to achieve Manual Automation goals, but most things you’d want to build would be too complicated for the Turks. You can use Mechanical Turk to perform HIT — Human Intelligence Task, which is a single, self-contained task, like “Identify the color of the car in the photo.” But that’s probably the most complicated it could get. Also, fair warning- using Mechanical Turk might sometimes be even more complicated than coding the damn thing.

So let’s make a deal.

We’re going to share with you one of the biggest secrets we ever kept (other than that one incident in Vegas. Sorry David). The know-how to validating ideas with as little time and lines of code as necessary. Manual Automation.

All you need to do is keep reading.

Tapdog — the poster boy for Manual Automation

The story of how we used Manual Automation in the early days of our startup, TapDog, is perhaps our favorite example.

Manual Automation made it possible for us to have a product up and running in the hands of actual users, only 2 weeks after the idea came to be.

Here’s how it worked-

On April 2013, 5 Friends, who happened to also be co-founders of a startup, get on a plane from Tel Aviv to San Francisco, to join the startup accelerator Upwest Labs.

A couple of weeks into the program, we decide to pivot. We move to a field we are more passionate about. Our first love, competitive intelligence.

We want to build a tool that would aggregate tens of different data sources, to offer companies a high-level analysis of their competitors’ online presence.

We’re in love with the idea.

The thing is, we’re in the middle of a 3-month long program, expected to present a working product with actual clients in about a month.

Desperate times call for Manual Automation.

Our 10 steps for TapDog’s Manual Automation:

1.List all the data sources we ideally want to have connected to our platform, once it’s fully built.

2. Design the main page of our future web app- the analysis page of a company.

3. With only a design in hand, we approach potential clients. We tell them our vision, offer them to be in our Beta program and ask for feedback about the product which we’re in the process of building.

4. We gather the first user feedback, tweak our design, and get to work.

5. We write MANUAL instructions of how to collect the data we need. For example, we want to present the # of employees a company has, so the instructions say something like:
a. Go to crunchbase.com
b. Search for the company name
c. Find the # of employees written
d. List it in an Excel file

6. With the full BOOK of instructions, we get busy hiring. We go to online hiring platforms, list a job for manual data entry, and with the help of 8 people from around the world, we’re ready to go.

7. We announce to our Beta clients that our platform is almost ready to go, and ask them to send us a list of the competitors they would like to analyze.

8. We forward those lists to our people overseas, who start sending us the data.

9. FIRST LINE OF CODE is written!
We build a very basic website, with basically 3 pages-
a. Homepage for marketing purposes
b. Sign-up/Log-in page
c. The main company analysis page- it basically works like a building in a western movie set. We only build the front side of the building with nothing behind. A nice design that’s only connected to a basic database table on the backend. No elaborate brains, no API connections. UI + table.

10. With that, we have a WORKING PRODUCT. It’s something clients are happy with, we begin getting traction and interest, and by the wonders of word of mouth we find ourselves with a waiting list with hundreds of potential clients. That gives us the needed boost and time to build the full product behind the design and grow our business at the same time.

These steps seem quite specific to our then product and needs, but the important takeaway here is the MINDSET. That’s something we believe should be cross-products. For your own good.

TapDog continued to grow and eventually became part of SimilarWeb, the company we currently work at.

Was a great ride.

Costs:

We ended up hiring 8 people who worked 6 hours a day for an an average hourly price of $5. Each one of them worked for about 14 days.

8 people * 14 days * 6 hours a day * $5 per hour = $3,360

Only $3,360 and 2 weeks of our time were invested in the course of building our proof of concept, which let us fast-forward 2 months of development, of 2 developers, to get the ball rolling. Not bad.

Wait, what about the Manual Automation guide?

Today we will show you exactly, step by step, how you can also build software and tech products without knowing how to code. It’s not a simple process, but it is doable.

The guide we’re sharing with you today is one of our biggest secrets and assets. Product of years of experience, mistakes and successes. It took us a long time to feel comfortable sharing it. Until today we only shared it with a handful of friends, investors and startup CEOs.

So if you’re willing to work hard and invest in yourself, we will do our best to show you how to reach Manual Automation.

Download the Manual Automation guide right here-

So what’s next?

What you have here is a great start, but there’s more to know. This is just the tip of this manual iceberg.

We’ve yet to answer questions like-

• How to find, hire and train the best people to help you with Manual Automation?
• How to design a mockup that will look just like a live product?
• How to get objective customer feedback on paper, to make sure you’ll build the right thing?
• What are the tools and resources you’ll need in the process?
• How to create accurate and efficient product plans?

There’s a lot more we’ll be sharing with you over the course of the coming months about the means to achieve Manual Automation.

You’re welcome to join the HackingRevenue community and get our weekly newsletter with everything that’s Manual Automation (and much more).

Subscribe right here - hackingrevenue.com

Originally published at hackingrevenue.com