I'd been asked to talk about innovation, and I'd been at it for a while by then: Fieldglass, which I helped build from its first days in 2000 into the company SAP bought in 2014, and Catalytic, which had just closed an $11 million Series A led by NEA.
Three trends, six patterns
I wanted to talk about innovation through three technology trends and my experience with each at Fieldglass and Catalytic:
- SaaS, which had moved well beyond the trend stage and was simply business as usual.
- Mobile, which was universally accepted but still not done well in the business world.
- Artificial intelligence and bots, which were still very much to be determined.
For each, I'd do a teardown: what business problem we were tackling, what the technology context was at the time, what the first shape of our solution was and what we got right, and what we got wrong.
While putting my experiences down, I noticed six patterns. They're worth stating up front, so the teardowns can be read with them in mind.
- We never knew the name of the trend we were innovating. Only in retrospect could we see where we'd picked up on one.
- We always focused on the business problem, going back and forth between top-down and bottom-up: studying the problem space itself, and studying the customer's perspective.
- Our solutions tended to be greenfield (what people now call first principles), informed by the technology context and by demographics.
- Studying what was already popular usually led us down the same path as everyone else, to a solution that looked like everyone else's. Where we really innovated was when we studied what was failing.
- Our first pass was almost always overly simple, sometimes embarrassingly so. But by starting with the simplest positive path, we could find the best experience and add complexity only as we needed it.
- Trends were an organic blend of enabling technologies and related ones that got absorbed as the trend strengthened. They also tended to splinter into more specialized variants, which in turn fed yet another trend.
SaaS
We were born SaaS, but we backed into it
Fieldglass got going in January 2000, and our first real production release came in late 2000 or early 2001. It was delivered over the web, multi-tenant, and managed entirely by us: exactly how software as a service would be defined years later, and still is. But we didn't build it that way because we anticipated SaaS or had some visionary insight. We honestly backed into the architecture.
The problem: a supply chain, and the consortiums
We thought of our problem space as fundamentally a supply chain problem, so our software had to incorporate many different processes involving different people in different companies. There was also a wave of newly formed industry consortiums, like Covisint, and we wanted to power their contingent labor functionality. That meant handling complex many-to-many relationships.
The common approach at the time was to emulate Ariba, which had gone public the year before. We didn't.
The ASP industry was failing, but it had great ideas
Instead we were drawn to the application service providers, companies like Corio. Few people remember the ASP industry now. It was already cracking in 2000 and on life support within a year or two. But we liked parts of its story:
- Where Ariba still sold client-server software, ASPs promoted delivery over the internet.
- The idea of a turnkey solution.
- Keeping everyone on a single version. We'd seen the massive support organizations that come with many versions of code, and wanted to keep our operations slim.
- Economic alignment. We'd only make money as long as we delivered value. After years of failed packaged implementations that left the customer holding the bag, that was very well received.
We also saw what was wrong with the ASPs:
- Most of the software they sold wasn't really web-based, so it took VPNs and other kludges to run it over the internet.
- That software was designed to run in standalone stacks, so every customer needed its own equipment, and there were no economies of scale in the infrastructure.
- They fed two margins, their own and the software maker's. Worse, they paid their software vendors up front but were paid by their customers over years.
We got software as a service right
We fixed those problems by writing our own software that ran every customer on a single system, which gave us economies of scale. Using our own software meant our only costs were our own development, which we kept lean with a single version that customers never customized. And because it was all web-based, distribution cost almost nothing.
We saw a business problem whose best solution matched many of the ideas of a failing industry. We fixed that industry's flaws and ended up with what would later be called SaaS.
We did get the timing wrong
I count this among our great successes, but we still got things wrong, mainly timing. Because we came out with a SaaS platform years before the market accepted it, we spent a lot of time evangelizing. Evangelism is painful, and it makes for long sales cycles.
IT was also not our friend, and it took us a long time to see it. We were essentially displacing them. But everyone was so used to IT buying software that for years they were one of our main buyers. It was a confusing time for everyone, as the market adjusted to a new kind of vendor that could bypass IT and sell directly to business leaders.
And we ended up on a mountain of data
One more outcome surprised us. We ended up on top of a huge amount of data that we could use more effectively than even the largest companies could. As a small startup, in many ways we knew more about the contingent labor market than even our largest customers. That's an amazing statement, and it changes the way you think about and treat data.
Mobile
Our mobile story is more nuanced. We backed into one of its major offshoots, and missed the main trend.
A long-standing problem for our users
By 2009 we were tackling a problem we'd known about for a while and had only put bandages on. We had a lot of infrequent users who:
- hated our system because it was too complex for their needs, which were mostly approvals;
- were often on the road and couldn't approve anything until they were back at a computer;
- were often senior executives whom no one could force to do anything.
Our thesis was that we could, and should, move this group out of our increasingly complex web application into a much simpler interface. They'd be happier, and we'd cut a lot of time out of the cycle.
We backed into the conversational interface
When we studied how they used the system, we noticed many of them only ever reached it through the links in their email notifications. So we wondered whether we could move the whole approval into the inbox. Not a notification with a link to a web page: everything they needed would be in the email, and they could act on it right there, replying conversationally. We ended up with a compelling conversational interface.
We even stumbled on invisible apps
The early feedback was good, so we pushed further. Could we keep this group out of the application altogether, so they never had to think about there being an application at all? We called it the app-less app, or the invisible app. We moved scheduled reports into email, then dashboards. Before long we'd moved that whole population's primary workflow into their inbox.
But we missed the mobile revolution
Notice I haven't mentioned mobile devices. That's where we were wrong.
For context, the iPhone was announced in 2007. But in 2009 BlackBerry still outsold it two to one, with much higher adoption in business. We had a fair number of requests for BlackBerry and iPhone apps, but we felt our application was too complex to translate to a phone. So we built a mobile-friendly web page for approvals, and later a native iPhone app, again for approvals only. Every time we revisited it over the next few years, we decided the application was too complex.
We were completely wrong. We were in a new era and didn't see it. To paraphrase Dick Costolo, the former Twitter CEO: we had the internet in our pants. We should have been re-examining our application and challenging our assumptions. We were missing an important trend, fueled by mobile computing and a generation that grew up on the web: consumerization, the rise of user experience, and the dramatic simplification of interfaces.
From about 2012 to 2014 I had a nagging fear that a competitor or a newcomer would reinvent the whole requisitioning experience mobile-first and disrupt us. For a disruptor, that's a horrible feeling. Luckily our competitors missed the boat too, and I'd argue most incumbents still lack a truly compelling offering.
Mobile still is disruptive
I saw it in my own habits. About seven years earlier, a mobile app was a nice-to-have. About five years earlier, it was a must-have. About three years earlier, the paradigm flipped: I was using mobile apps first and looking for ones with decent desktop versions.
That brought another change, and I think a clear one: a shift of power from IT to employees, especially combined with SaaS. Employees were driving more technology decisions than ever, and IT was struggling to keep up.
AI and bots
The last teardown was artificial intelligence and what I thought of as its kid brother, bots. AI had picked up a lot of steam in the few years before, though it had lately been overtaken by more pragmatic variants like self-driving cars and bots.
I love talking about AI because the reactions are all over the map. Some people picture Skynet from Terminator, or HAL from 2001. Others picture Data from Star Trek, or Samantha from Her. Those are wildly different visions, and the truth will probably land somewhere in between. A few enabling technologies had made it feel much closer than it did a few decades earlier:
- Storage and processing were dirt cheap, and connectivity everywhere meant storage and processing everywhere.
- Decades of research in natural language processing, together with conversational interfaces and better user experience, with milestones like Eugene Goostman passing a Turing test in 2014, if by the skin of its teeth.
- SaaS and cloud companies sitting on mountains of data, big data in general, and advances in machine learning, with milestones like AlphaGo beating one of the world's top Go players that year.
Even so, we'd concluded once again that general-purpose AI that can think, learn and be self-aware is really, really hard. Microsoft had just announced it had 5,000 people working on AI. Then it released Tay, its Twitter AI, into the wild, and within a day Microsoft had to pull it for posting racist abuse.
So came bots: dramatically scoped down, with very limited comprehension and very limited abilities. If AI is the mastermind, bots are the minions. Because they're limited, they're easier to build, and they were popping up everywhere. VCs were hunting for bot companies, entire funds had been raised for them, and plenty of people asked us at Catalytic about our bot.
We hadn't set out to build a bot company, and I still didn't think of us as one. But it was interesting how we ended up in the middle of the space.
The problem
We started Catalytic to build a solution for operations and recurring business processes. It isn't a new problem, and there were many players in and around the space: BPM, ITSM, WFM, to name a few acronyms.
But I'd been trying to solve this problem for a long time, and when I talked with other executives, most were in the same boat. A few had solutions they were happy with. Most had settled on one of three: spreadsheets, email chains, or human babysitters. Those with more robust solutions mostly fell into two camps. One disliked their solution because it was cumbersome and horrible to use. The other found that it worked, but it was fragile, needed lots of IT resources, and only made sense for the really important processes.
That seemed like a problem that deserved a modern solution.
A modern solution for recurring processes
Thinking about it greenfield, it needed to:
- be proactive. Most solutions were passive, and we wanted something that drove processes to completion;
- have low friction of adoption, easy to implement and easy for a new user to pick up, so user experience was key;
- give the people in the process clear value, rather than being yet another management reporting tool;
- and, more conclusion than requirement, be purpose-built for recurring business processes. So many companies were repurposing software made for project management, document management or collaboration, and weren't happy with the results.
How we became a bot company
In a number of cases, the best technology for the business problem turned out to be AI and bots, though we didn't use those words. It was VCs who told us we were an interesting bot company because we focused on business value. And it was one of our large launch partners that told us we were their bot platform and their partner for robotic process automation.
Here's how the product, then called Pushbot, mapped onto those ideas.
We started simply. Users modeled a business process as a task checklist, and each time the process ran, Pushbot sent tasks to the right people and waited for them to mark them complete. A simple premise. But many people struggled with the idea of a proactive system. They were used to software like Asana or Basecamp, where you get an email and then log in to do things. It turned out to be much easier to describe Pushbot as a virtual project manager for a business process, and we found ourselves, suddenly and by accident, in the virtual assistant market.
The next problem was friction: getting people's attention. By 2016 people had their own ways of managing tasks, and it's very hard to get them to change. So we built a conversation engine that talked with users over email or chat platforms like Slack. That became our chatbot.
As Pushbot orchestrated tasks, it became clear it could do some of them itself. We started with simple tasks and planned to move to more complex ones. That became our robotic process automation.
The last example is about adoption too. Some users could spell out their processes, but many couldn't, and we wanted something for them. So we began exploring a very limited form of AI that could make its way through an organization and infer an implicit process. We hadn't cracked it yet, but I believed we would. It was a combination of natural language processing and machine learning, much closer to AI than our chatbot, and much, much harder.
What it adds up to
Innovation was never a specific activity for us. It was a focus on assembling the right solution for a business problem. The innovation happened while we thought that solution through: from a greenfield perspective, studying failures, poking holes in the current trends.
Just as important, we tested our theories. In the startup world that's called product-market fit, and it's what VCs pay early-stage entrepreneurs to do. We were paid to hypothesize, to make mistakes, and mostly to learn from them quickly. And we had an endless supply of people, called sales prospects, happy to tell us we were wrong.
The challenge for a group like the one in that room is that its structure is completely different. You can form theories, but how do you test them? Who tells you you're wrong? What happens when you make a mistake?
And the six patterns, once more:
- We never knew the name of the trend we were innovating.
- We always focused on the business problem.
- Our solutions tended to be greenfield.
- We innovated most when we studied what was failing.
- Our first pass was almost always overly simple.
- Trends were an organic blend of enabling and related technologies.