The big news in the machine learning/deep learning world this week is Google’s release of TensorFlow, their deep learning toolkit. This has prompted some to ask: why would they give away “crown jewels” for such a strategic technology? The question is best answered with a machine learning joke (paraphrased): “the winners usually have the most data, not the best algorithms”.

Neural networks have been around for a while, but it’s only been within the past 10 yrs that researchers have figured out how to train networks with many, many layers (the “deep” in “deep learning”). That research has been greatly accelerated by using GPUs as very high-performance, general purpose, vector processors. If a researcher can turn around an algorithm experiment in a day (vs 3 months), a lot more research gets done.

But as the joke suggests, it’s all about that data: you need lots and lots and LOTS of data to train a high-performance deep learning network. And Google has more data than anyone else —so they don’t worry so much about giving away algorithms.

(Also, Google, Baidu, Twitter, Facebook, etc. are investing in GPU compute clusters that can only be described as the new “mainframe supercomputers”. Sure, you can rent GPU instances on Amazon, but there’s nothing like having the latest Nvidia board with lots of RAM and very high-performance interconnect).

What does this all mean for early stage startups? The situation creates several tough hurdles: first, freely available code and technology from Google (and Facebook) enables competitors and devalues whatever the startup might develop. Second, few startups have access to a large enough proprietary data source to compete at scale. And third, GPU compute clusters need real capital.

What’s left for startups? I see at least two interesting patterns:

• Using deep learning as a key feature to enhance another app.  Use freely available technology to add magic.  Google Photos is a great example of this, and I think every photo and video app will soon be able to recognize stuff, people, people, items, etc. to enhance the functionality.
• “Man-teaches-machine”.  Start out with a lot of humans doing some task and capture their work to train a network.  Over time, have the network handle the common cases, with the exceptions / ambiguous cases routed to humans for resolution.  Build a large, proprietary training set, enjoy compounded interest, and profit.

Occasionally, I hear from a software entrepreneur with a “patented” or “patent pending” idea.  Many people view patents in a almost glamorous way:  “Get a patent, and you can control your idea“.  I’ve done a lot of patent work (15 issued, including two of the most cited patents in US history), and it’s never that simple.  Patents are very tricky.

For startups, patents make the most sense in industries with (a) relatively long development times and (b) significant R&D budgets.  The PTO doesn’t move quickly:  for some art units, it can take 2-3 years (or more) to get a patent issued.  That’s fine for a biotech company bringing a new drug to market, but is much too long for a software company launching a product in six months.

Also, patents can be very expensive.  For a $750,000 seed round, it may not make sense to spend ~5% of that (or more) on getting US patents filed.  International?  Budget six figures.

Finally, fundraising entrepreneurs frequently overplay the value of patents, missing the other elements needed to make a successful business and making themselves look naïve.  For example, “provisional patents” don’t exist:  it’s a provisional application that gives an option to file for a utility patent later (and it’s just that, an application).  “Patented” means patent issued and in force, “patent pending” means a patent filed but not issued.

If you don’t have an issued patent, it’s a long and expensive journey:  claims are often rejected entirely or issued very narrowly.  It’s nearly impossible to know what a patent is worth until it issues.

You have to be living under a rock to miss the shift in Web usage from “traditional” devices (desktop and laptop) to mobile devices (phones and tablets).  For example, in India, mobile phones now account for nearly 50% of consumer Internet usage, and mobile usage is growing rapidly world-wide.

As Web site operators watch mobile usage grow, the next thought is usually:  “let’s build a mobile app!”  It’s a good instinct, but I think it’s also a great way to waste a lot of time and money.  Leaping in without any insight on mobile usage is a good way to build the wrong app.  Also, it’s easy to end up with something that only partially replicates Web site functionality, frustrating users and creating two different UIs to maintain in parallel. A mobile app is also a great way to market your product. Geneca can help you develop the perfect app to enrich the experience of your customers while also attracting new ones! Visit https://www.geneca.com/mobile-application-development/ for more info.

For a better strategy, Facebook is a good example to study.  They took way too long to focus on mobile, but their sequencing is a good place to start.  (Note:  this advice is really for existing Web sites).

Following their example, here’s a “starter” mobile plan:

Step #1:  Mobile-enable your Web site.  Remember m.facebook.com?  You can get pretty far these days with just HTML5.  Use your mobile usage data to figure out what areas to prioritize (Google Analytics will break out mobile usage).  Consider both tablet and phone cases:  depending on your application, you may want to deal with them separately.

Step #2:  Develop a native app, with generous use of embedded browser widgets.  Consider which app elements must to be native for the best experience, and do the rest using embedded browser widgets (e.g. WebKit).  Most of your app will actually be HTML5 served from your servers, and you can change content on the fly without having to do an approval cycle with Apple (which can take weeks).

You should be able to leverage the HTML5 work you did in step 1.  Use your existing mobile usage data to prioritize Android vs iPhone and phone vs tablet.

Step #3:  Go 100% native.  (If needed)  At this point, you should have a good sense of the most important use cases, platforms, and form factors.

Edit to taste!