Weave.ai postmortem
I have been a VC for more than a year now and during this period I have invested in dozens of startups, mentored many more, and spoken with hundreds of entrepreneurs. I would like to think that I am pretty good at grasping the core idea behind a company (as long as it’s in a market that I understand and using a technology that I am familiar with) and then disassemble it in its atomic components and review the ones that are at risk, and suggest changes to improve the chances of success. I’m sure there are better VCs than me, but so far I am happy with what I do and the CEOs I helped seems happy as well.
Therefore it really bugged me that I have an inability to self-analyze my own startup process to diagnose what didn’t work.
Over the past few years I’ve been wondering why Weave.ai, which I co-founded in 2015 with four other entrepreneurial individuals, failed and what could I have done to avoid it.
Luckily Dropbox released a product (which Daring Fireball welcomed with a “The new Dropbox sucks”) that gave me clarity.
What Weave.ai tried to do
In short the vision was to create a new operating system that was built on AI. Instead of an OS based on files or apps, it was something that at the core was capable to understand the data it was manipulating. It was a paradigm shift that we believe was going to happen in stages as iOS/Android were going to add more and more AI APIs and we wanted to leapfrog the current tech without having to worry about backward compatibility or existing developers.
Some of the design ideas were explored in “AI and the Future of Operating Systems”.
Because of the magnitude of the scope, for which we had neither money nor expertise to accomplish, we started with the basics and wanted to have a semantic file system that could index your work data like emails and documents, and then a file explorer based on a graph database that could not just see the documents, but also the metadata associated with them while also extracting entities from those documents and manipulated them, both structured (like an address) and unstructured (like a statement from someone). We wanted to start as an app, move then onto a wrapper (like a reskinning of an UI, but had decided against an Android UI as they were cumbersome to install and previous attempts were poorly received) and then replace everything and possibly build some custom hardware with a partner.
Ultimately the product had no use case, and that was the end of it. It still took almost two years to die.
What assumptions we had that turned out wrong
We had made certain assumptions about the future, which in hindsight are obvious but also show that we were (I was?) blinded by optimism.
“People want to work on their mobile device if they could”
What we thought: It was 2015, enterprise apps were finally on the phone, alternative to incumbents that had started with a mobile-first strategy were hot. Our assumption was that people wanted to work on their phones but they could not. When we did customer interviews and analysis of workflows it was clear that a lot of actions were not done on mobile, and instead people were postponing executing those until they were back at their desktop. So we wanted to make it possible to have those actions and to move from a keyboard+mouse using 10 fingers paradigm, to one where they would use one finger and two thumbs + AI, where the AI would infer the intention and context and do all the heavy lifting for the user.
What went wrong: what turned out was that a lot of the operations people needed to perform required some interaction that simply was too cumbersome to perform on mobile, AI or not AI, and could not be application-specific but was baked in the OS. Things like taking data from one app from another: glacially slow, dreadful UX, and also failed most of the time as apps were not designed to talk to one another. Cutting and pasting. Context switching. Looking at two apps at the same time. And this is just on top of my head.
“The future is mobile”
What we thought: I had made a judgement call that installing a new program on a computer was impossible in a large corporate environment, but bc of BYOD you could have people add an icon, as well as the fact that desktop shipments had peaked a year prior for the first time in history while mobile was growing like crazy. And that iPads were without a clear use case and it would not have grown as a market in the long term.
What went wrong: ultimately adoption is driven by utility and we were trying to optimize the wrong function. And there was confusion on the size of customers we were going after. Should have ignored the very large customers with 10k or more users because to this day they are discussing whether to adopt Slack or not.
Mobile is *awesome* for short form messaging, great for social media, good for some notifications, and (so far) lousy for the rest compared to desktop.
What I should have done instead
I think if I could redo it all again I would:
- Build for desktop. that’s where people do their work. and that’s where we did most of our work, so building something for us would have been a priority and also measuring its effectiveness would have been easier
- Ignore companies and focus on the professional. Team features can always come later. but because the core of the product was about your own data there were no clear and immediate scale economies (e.g. unlike Slack)
- Build it on top of Dropbox. The use case would be that my Dropbox folder is several years and several startups old, so it is wild an unmanageable. I have no idea what’s inside it, nested directories within nested directories. So an addon UI to sell to those with an overflowing dropbox. also easier to take over the UI from a desktop than a mobile OS.
- Focus initially on a specific vertical, microtargeting a specific workflow rather than a catchall solution. Great companies have been built on one specific problem, like having two parties sign electronically a document, without having to make life too complex for the user — at least not initially. Related, this is why I think the new Dropbox product fails, as it’s too generic and you don’t look at it and have this magic moment where you realize it creates a shortcut in your professional life.
Why M&A failed
In the end we tried to sell the company, we talked to everyone, I mean *everyone* and usually the calls went like this:
- Hi I am Head of Machine Learning at $300bn company. Much ML. Very AI. Wow. Do you do machine learning?
- We don’t do machine learning
- So what do you do?
- We built a graph with your work data that uses a grammar to communicate with the user so they can manipulate context
- <silence> uh …so what’s it for?
- We don’t know. But we think it’s awesome
- Ok. How many of you are there anyway
- 4
- Where are you located?
- UK, Denmark, France
- Thank you <click>
So yeah too small as an engineering team, risk of not getting the visa and having to wait 6 months for it, so losing one member would have killed the team, no focus on the one area (machine learning) where everyone was hiring like crazy.
I’m not sure who is the audience for all this beyond the Weave founders and our investors, but finally got some clarity and wanted to write it down. Thanks for reading.
PS. Ben, co-founder and CTO at Weave.ai had this to add:
“We did have Dropbox indexing, but we weren’t analysing the file content at the time I was still working on it. I vaguely recall us putting that on the back-burner because a lot of the files would have been harder to read compared to the plain text that other services were giving us.
I was always fairly negative on mobile (and tablets) but what can you do when everyone else was still in the Peak of Inflated Expectations? Maybe a desktop app simply couldn’t have worked 3 or 4 years ago. And the startup ecosystem is always pretty strange. I used to find it funny watching the pitches in Warner Yard when there would be 30 people with Macbooks and 1 with a Windows laptop, then I’d come back to Nottingham and see the people in the coffee shops with 30 Windows laptops and 1 Macbook. How do you sell a desktop app to people who were thinking that Apple Watch was going to be the most important piece of hardware in the future?
Anyway… on my current project one of the big problems is that the team creates tons of Google Documents/Sheets/etc and then the information gets lost. Being able to effectively search through all that has value. But (admittedly without using the software) I don’t see any evidence that the new Dropbox is doing anything more useful than surface-level indexing of documents, whereas we were able to give people a semantic view of their information.
But I also think that the act of going to a search bar is admitting defeat on some level — you know there’s some information somewhere and you can’t remember how you categorised it, so you throw in some keywords hoping they match and that some index will have picked it up. Once (if) you find what you want, you click the link and you’re back in a file silo, isolated from any context. By comparison I liked the way we could browse through related documents via semantic links — as a user it felt like I was more in control, even if the underlying mechanism was much the same. I think the “Navigation > Transaction” aspect was something we were doing right, and which still isn’t being exploited enough. Pair that with mechanisms to deep-link into and across documents, and that’s a powerful system.”
