The Mechanical Turk (The Love Test for Entrepreneurs)

For the last couple of years, I have spent a significant amount of time talking to innovators both independent (entrepreneurs) and inside of organizations (intrapreneurs?). The conversations generally focus on a variation of these familiar themes:

Uber for …

Ebay for …

Facebook for …

Computer vision to …

Artificial Intelligence / Machine Learning to …

There are others, but you get my point.

I’m not casting ANY sort of judgement on the quality of the ideas or the potential viability of anyone who has ever pitched an idea. I have long since given up on trying to guess what idea is good or not.

I mostly try to figure out:

• Is the person I’m talking to the right person to even try the idea?
• Does the idea fit the region? If not, is the person willing to take it on the road?
• Can we imagine a simple way to prove the viability of the idea?

It’s the third one that is most revealing to me.

“A simple way to prove an idea’s viability” translates into “I’m in love with solving this problem, not just my solution”.

If I don’t hear some version of a “Mechanical Turk” as a possibility in my conversations, I really question if the innovator will be successful.

The Mechanical Turk

If you already know what a Mechanical Turk is, skip this section. If not, here’s my high-level understanding.

In the late 1700s, the world marveled at a machine that could best most chess players. The machine was called “The Turk”. It turned out that the creator of this ingenious piece of hardware pulled a fast one. For nearly a century, the magical box toured the world and little did the amazed audiences know that inside the machine was a person with above average chess playing skill.

The Obvious Connection to Innovation Efforts

I won’t belabor this point too much. The idea of the Mechanical Turk or “The Wizard of Oz” (pay no attention to the man behind the curtain) has been employed by nearly every innovator.

The best uses of this approach aren’t the “fake it until you make it” type. The best case is the “fail fast then pivot”.

Failing fast and pivoting is the art of identifying the biggest and scariest unknowns in your idea and then hitting it head-on with the simplest way to test it. The biggest hurdles are not typically technical problems.

That’s not to say there aren’t ideas that are literally R&D technical where the R is a big technical unknown. The thing that’s likely to kill your idea is not the $15 million development of the amazing tech, but that nobody wants exactly the tech you are imagining. There are disruptive implementations of technology that can only be proven by creating the technology, but I’ll leave it to you to decide if you have one of those.

The obvious way to avoid spending money to develop the technology that wasn’t quite right is to find the intersection of where user expectations can be met and the least amount of investment. This often requires innovators to trade some of what I will call “non-functional” requirements.

Example trades include:

Trade Speed for Timeliness: Imagine a user instantaneously getting a response to some request. In reality, they may be satisfied with the response when they need an answer.

Example: I may want to build an app that, by analyzing a single photo, will tell me if the green thing in my garden is a weed or a tomato plant. For the sake of simplicity, let’s pretend that all gardens just have tomatoes or weeds. Answering that question instantly would be super cool.

You know what else would be super cool? Answering that question in a few minutes.

What if a bunch of horticulture experts (you and your gardening buddies) receive a photo notification every time somebody used the app, look at the photo, and give a “weed” or “tomato” response? Mechanical Turk, baby!

Trade Definitive Answers for Definitive Answer –or– Refer an Expert: Imagine being able to provide a range of answers to a question. In reality, you may be able to give a single answer along with a referral to an expert.

Example: Subscribers can monitor their social media feeds to let their friends know if they are arguing with a bot. I imagine using machine learning to watch for patterns while traversing my subscriber’s feeds, and then catalog and provide “bot warnings to my friends”. That would be awesome.

You know what else would be cool? If I have collected a database of bots over time so I can give a “bot warning to my friends” when I think they are fighting with a bot. I can click “ask an expert” to route the name of an expert to help me validate it. And once it’s validated, I add it to my database.

Use Your Imagination… There are absolutely other trade-offs you can make.

What Do You Love?

If you aren’t willing or able to find one of these types of trade-offs to solve your problem, you need to ask yourself if you are in love with solving the problem or just in love with your solution.

The answer may be that the solution requiring a big technical investment IS the only solution to the problem. In that case, go forth and build. More often than not, there is an opportunity to make some compromises and answer the big questions about your product without the big investment.

The willingness to explore the “Mechanical Turk” or “The Wizard of Oz” or “insert any other substitution for technology investment here” is proof that you love solving the problem more than your solution to the problem. The love of solving the problem will always lead to better solutions. EVERY TIME.

The Bonus Round

But wait, there’s more. It doesn’t take a huge mental leap to realize that the activities needed to create a Mechanical Turk are often very similar to the activities needed for machine learning.

Going back to our “Tomato vs Weed” example, if I can have my “expert user” trace a box in the part of the picture that is telling them “weed” or “tomato”, we’re now teaching the machine AND providing back a timely answer in exchange for future instant answers (assuming we learned that our “Weed vs. Tomato” app was actually useful to our audience with our initial Mechanical Turk test).