Some VC Insights

This recent episode, 20VC Roundtable: Is the Venture Model Broken? was one of the best I’ve heard in close to ten years of listening.

I found myself jotting down a few notes. Listen to the whole thing, but here are some of the highlights:

• VCs tend to jump to the “next big thing” (Crypto, AI, etc.) because that’s how you get markups on your investments. But, by definition, the “next big thing” isn’t contrarian and, in theory, wouldn’t be where the outsized returns are. There is an interesting conflict for VCs between showing a good markup and getting actual returns.

• In venture, patience is an arbitrage.

• The true outlier investments, in theory, are the cheap investments. That’s because they’re truly contrarian, and nobody wants to invest in them.

• Pre-product-market-fit, stay as lean as possible. If you get ahead of the market, the team will have built things that aren’t perfectly aligned to the market, and they’ll develop opinions about what the market needs based on what you have and what’s been built. Slow that down and make sure the market is pulling and you’re not pushing.

• When you have product-market fit, your next customer should be marginally more attractive than the last one. e.g., you shouldn’t have to be straining your offering to get more customers. At some point, everyone should want it.

• Often, a company’s go-to-market is better than its product-market fit, and you can fool yourself into thinking you’ve found it.

Tech Company Layoffs

There’s been quite a bit of news over the last several weeks of tech companies freezing hiring and laying off employees. Perhaps most notably, Meta (formerly Facebook) recently laid off 11,000 employees or 13% of its workforce. I thought I'd write a post about what tech companies are thinking about and the factors that are contributing to these unfortunate announcements. First, some history:

Until about a year ago, the stock market had been on a bull run for about 13 years. There are several reasons for this, but the primary reason was that, during this time, we had zero or near-zero interest rates. When interest rates are near zero, companies can borrow money almost for free, allowing them to invest heavily and grow, grow, grow. In addition, when interest rates are so low, money flows out of fixed-income investments and into riskier equity investments (the stock market). More money in equities means higher stock prices for public companies. Public company stock prices are a proxy for private company valuations, so private companies have experienced the same dynamics. This enabled companies to raise enormous amounts of money with little dilution for founders and shareholders. Due to classic supply and demand forces, more money in equities means that the same company with the same financial profile could be valued at 2 or 5, or 10 times what it would be worth in a less bullish market.

It was a great ride until COVID hit, and the economy stalled because people couldn't leave their homes and go to work and buy the goods and services they had been buying in the past. To get us through the crisis, the federal government rightly provided a massive economic stimulus to businesses and consumers by pushing more than $6 trillion into the economy. Again, more money in the system means higher prices for everything (including stocks). Due to COVID, we also saw major global supply chain issues and price spikes across nearly every category (again, the effects of supply and demand; reduced supply of products drives higher prices). Thankfully, the economy quickly recovered and Americans had surpluses of cash that they were anxious to go out and spend. And they did. As a result, we're now seeing historical levels of inflation. The inflation rate for the period ending in September was 8.2%; the average is closer to 3%.

This level of inflation is very dangerous. If prices increase faster than wages, it can literally topple the economy. And there have been lots of examples of this happening in the past. Luckily, the federal government can contract the money supply to slow inflation (less money in the system leads to lower prices). This has the effect of raising interest rates. And that's exactly what has happened; the federal funds rate sits at around 4%, the highest since 2008.

As a result, money has poured out of equities, particularly tech equities. The broader S&P 500 index is down about 15%, and the tech-focused NASDAQ is down about 30%. Tech companies get hit much harder in these cycles because they're investing in future growth and often carry a lot of debt. Because the profits from these investments won't be realized until further out in the future, increased interest rates discount the values of these future cash flows by an excessive amount (more on this soon).

An additional challenge is that as the Federal Reserve contracts the money supply and interest rates rise, it's not very predictable how quickly that will temper price inflation, so there's no way to know how long this drop in the markets and company valuations will persist. And there are reasons to believe it could get worse before it gets better. 

For companies trying to navigate all of these changing conditions, their worlds have become much more difficult. Valuations are way down. As recently as 10 days ago, Facebook’s stock price hit $88, down from a peak of $378. Stock options granted to Facebook employees over the last 6 or 7 years are likely worthless.

Further, the cost of capital (both debt and equity) for companies has significantly increased. This hits technology companies, which, as I mentioned above, typically have higher levels of debt because they're investing in new growth, particularly hard. The cost of running these businesses becomes much more expensive because the cost of debt increases (increased interest expense). In addition, some of these debt covenants have requirements around growth and profitability that companies need to meet. 

Moreover, and this is probably the most important part of what's going on that should be well understood, is that because tech companies are investing heavily in new growth, the profits from those investments won't be realized for several periods. And higher interest rates hit growth-oriented companies very hard because of the discount rate of future cash flows (more on that here). This is a very important economic concept that many in the tech ecosystem don't understand well enough. Said simply, a company is valued on its ability to generate future cash flows. And increased interest rates lead to a discount in the current value of these future cash flows far more than for companies that are profitable now. When interest rates are zero, there's no discount applied to future cash flows, so the market seeks high-growth companies that are making big, bold bets. When interest rates rise, investors look for companies that have profits now. Again, this is simply because of the discount applied to future cash flows.

Finally, and more broadly, businesses are seeing what's happening and are concerned that jobs will be lost, spending will slow, demand for their products will decrease, and a recession (two consecutive quarters of negative GDP growth) might be on the horizon and bookings and revenue may decrease.

That's the situation tech companies find themselves in today. So how are they responding?

Well, it's important to remember that a company's primary purpose is to maximize shareholder value (for external investors and employees holding stock options). Management has a legal duty to its shareholders to operate in a way that maximizes the value of the company, regardless of the changing markets and the lack of predictability around when things will get better or worse. So in a market where near-term profits and cash flows are very highly valued, companies must pare back longer-term growth investments and find ways to cut costs to realize profits more quickly. And, because, typically, the vast majority of expenses of a tech company come from human capital (employees), the only material way to do this is to slow hiring or decrease headcount.

And this is exactly why we're seeing all of the news reports of tech companies freezing hiring and laying off employees.

Of course, some will criticize these companies for hiring too fast and overextending themselves, and voluntarily getting themselves into this situation by investing too heavily too fast. In many cases, this criticism is fair. But it's worth noting that, while cost reduction has rapidly become very important, in a bull market, growth is inversely and equally important. Facebook, as an example, is taking a lot of heat for overhiring engineers, but should they? I’m no expert on Facebook, but it’s an interesting thought exercise to think through for any company. Again, the job of a company is to maximize shareholder value. And when capital is cheap or free, the companies that invest heavily in growth will receive the highest valuations (again, refer back to the discount rate applied to future cash flows). At scale, had Facebook and the other tech giants chose not to make those hires, those individuals would've been unemployed during that period or would've received lower wages from other companies during that period, possibly displacing less talented engineers. If a company has viable ideas and areas to grow, and capital to invest in that growth is freely available, it must pursue that growth. It must maximize shareholder value. Companies with high growth potential have to play the game on the field. They have to pursue growth if they believe it's there. This is an unavoidable cycle that innovative companies are subject to. And individuals that work in the tech ecosystem will inevitably be the beneficiaries – and the victims – of these realities. Other industries experience far less dramatic highs and lows.

Of course, it should be noted that these highs and lows seriously impact people's lives. And I've been glad to see many companies (though not all) executing these cost reductions with humility, empathy, and generous severance packages.

With all of this said, inevitably, at some point, inflation will slow, interest rates will decrease, companies will invest in growth, companies will start hiring again, we'll be back in a bull market, and everything will seem great. In the meantime, it's important that all stakeholders that have chosen to work in and around tech understand and plan accordingly around the macroeconomic cycles that have a disproportionate effect on this industry.

DoorDash’s Empathy Policy

I read the other day that DoorDash is requiring all of their employees (including their CEO) to make at least one food delivery per month. A lot of engineers were less than thrilled with the idea.

I love this idea. One of the challenges in building b2b software is that your product/engineering team is often very disconnected from the user and the user's problems. DoorDash is lucky that many of its employees likely use the product from the consumer side. That's a massive advantage because they have built-in empathy for the user.

But they're also building for the business user (the Dasher), and many/most employees at DoorDash likely have little to no experience delivering food to a customer. Forcing them to do it once a month drives business user empathy and, likely, a much, much more delightfully built business-facing product.

Throughout most of my career, I've worked with companies that build software products for business users. So I've experienced this challenge first hand. If you're building software for, say, police departments, it's highly likely that most of your engineers will never have worked at a police department. There's nothing wrong with this. Their job is to build software. You want people that are great at building software, not great at enforcing the law. But that means that there is an inherent lack of empathy for the user that has to be dealt with proactively. That's why I love DoorDash's decision to get product managers and engineers out in the field to really feel what their Dashers feel. There's no doubt this will result in a better product.

One exercise I'd challenge b2b software companies to work through is to take stock of how many employees they have that truly have been in the user's shoes. Using the example above, it's worth asking how many employees inside the company have worked for a police department or have had a job where they "could've" used the product they're building? Lots of companies wouldn't have a great answer to that question. And that's ok. But those companies have to make proactive moves to drive empathetic product development.

DoorDash's policy is an excellent step in that direction.

The Operator Shortage

Howard Lindzon described the current state of startups really well the other day on the Animal Spirits podcast. I’m paraphrasing, but he said something like:

There are lots of good ideas. There are lots of founders that want to pursue those ideas. There’s lots of cheap capital for founders to raise and build companies around those ideas. But there’s an extreme shortage of qualified operators to go and execute on those ideas.

There aren’t enough high-quality operators that have actually built companies from the ground up. As a result, we’re seeing significant wage inflation across almost every function inside of startups. The ability to recruit and retain top talent is more important than it has ever been in tech (Apple just offered $180k bonuses to engineers to get them not to leave and go work on the metaverse or crypto). Good companies won’t have a problem raising capital, but almost all of them will struggle to hire the best people.

Build a brand that attracts both customers and potential employees. Hire managers with high levels of followership.

Be a company that people want to work at with leaders that people want to work for. Nothing is more important in this market.

Measuring ROI In Enterprise Software

One of the main topics I talk to founders about is how to measure the ROI of their product and how to communicate that ROI to a prospect. This topic almost always comes up in sales conversations, and it’s important to be able to lead this conversation with clarity and authority.

I like to use a simple framework for how to think about a product's ROI, using three broad categories of measurement:

1/ Product usage and engagement. Registered users, monthly active users, transactions, data delivered, etc. Depending on the product, this can be more or less impactful. This is a useful way to think about ROI for a product that doesn't need to be used by a user (like an employee discount program or coaching software). This is not a very effective way to measure ROI for things like expense reporting or benefits management where users are required to use the product to accomplish something.

2/ User satisfaction. This is a bit of a step up over usage metrics in that it measures not just whether or not users use a product, but whether or not they like it. This can be an effective way to measure the ROI of an enablement tool where usage is not optional and financial gain is difficult to measure. NPS is a good measurement for this but I love the way Superhuman tracks this using this question: 1. How would you feel if you could no longer use Superhuman? A) Very disappointed B) Somewhat disappointed C) Not disappointed. There’s a great First Round article on this topic that’s worth reading.

3/ Revenue/Cost savings. This is of course the most impactful way to talk about ROI. It’s especially effective when a company is trying to create a category. In the early days of selling Zocdoc (an online appointment booking software for healthcare clinicians) revenue generated from the service was a crucial part of the ROI conversation. Most doctors didn't feel like they had to put their schedules online, so the only way they'd buy is if they were comfortable that they'd make money. While this was always important, it became less so over time. Online appointment booking became a standard. They had to do it. So other metrics and measurements became more important (e.g. does the staff like using it?).

Depending on the stage of category creation for your product as well as its competitive dominance, it’s important to understand where your product sits in the framework above. Some products need a hard financial ROI, others don’t.

The canonical example of the latter is Salesforce.com. A few years ago, I asked a Salesforce sales rep how they talk about ROI with their customers and he looked at me like I was crazy. The CRM category has been created and it’s now quite mature. Almost all companies of a certain size need a CRM. It’s sort of like calling Verizon and asking them about the ROI on your cell phone. At some point, you just need it. So Salesforce doesn't need to convince you that your sales teams will make more sales because you're using Salesforce, they just need to convince you that everyone uses it or uses something like it and that you need it too. They can validate their ROI by showing usage stats (the bottom of the stack). And if your team isn't using it, that's likely your own fault because you haven't done enough training or promotion to get employees to use it. And of course, they'll be happy to sell you a service that will do that for you.

When taking a product to market, it's important to recognize where your product sits on this stack. Are you selling something that will only be purchased if there’s a crystal clear ROI, or are you selling something that is required to keep the lights on?

___________________________________

Footnote: If you’re interested in learning more about category creation, I highly recommend the book Play Bigger by Al Ramadan.

Footnote 2: Generally, when talking about ROI you have the buyer and not the user in mind. However, it’s important to understand how both are thinking about assessing the ROI of your product.

Footnote 3: Eventually, all ROIs come down to dollars and cents. As an example, user satisfaction might lead to better employee retention which saves your customer money. But don’t go there if you don’t have to. ROIs generally have lots of assumptions that are easy to disagree on and challenge. Striving to show a financial ROI when it’s not needed can complicate/undermine the story you’re trying to tell.

LTV, CAC, & B2C

Whenever I consider investing in a B2C startup, I immediately ask about the company's LTV/CAC ratio. From the Corporate Finance Institute:

”LTV stands for "lifetime value" per customer and CAC stands for "customer acquisition cost." The LTV/CAC ratio compares the value of a customer over their lifetime, compared to the cost of acquiring them. This metric compares the value of a new customer over its lifetime relative to the cost of acquiring that customer. If the LTV/CAC ratio is less than 1.0 the company is destroying value, and if the ratio is greater than 1.0, it may be creating value, but more analysis is required. Generally speaking, a ratio greater than 3.0 is considered "good."

I’m less interested in the actual numbers than I’m interested in how the company is thinking about improving the numbers over time.

You could argue that a startup shouldn't be overly concerned with this metric in the early stages because they're still building the initial product or trying to find product/market fit and get the company off the ground. I disagree. B2B startups can get away with deprioritizing this metric in the early days because a good sales team can reliably acquire large amounts of users and revenue in large batches. And because of the way decisions are made within an enterprise, churn is typically significantly lower.

For B2C companies, LTV/CAC should be a part of the story from the beginning. Acquiring individual users is difficult and expensive. And since Facebook and Google, there haven't been that many widespread and effective ways of acquiring new users. Most of the high-quality channels are saturated. 

Ideally, B2C startups can bake user acquisition into their fundamental product offering; e.g. a supplier in a marketplace might bring their customers to the platform at no cost to the platform. AirBnB is a good example where landlords will often ask renters to book rentals through AirBnB.

Obviously, this won't be possible for every company. But the point remains: user acquisition and churn mitigation are critical considerations for any B2C startup right from the start.

Superhuman & Enterprise Software

I was thrilled to see Superhuman announce a $75 million Series C last week. Superhuman is a $30 per month email application that sits on top of Gmail that promises to get you to inbox zero in half the time. Paying for email sounds like a crazy idea these days, but this product is worth it. Superhuman is easily the best software product I've ever used. They've created keyboard shortcuts that effectively "gamify" getting to inbox zero. The product makes it easy to get into a flow state and plow through emails in a flash. I'd talk about the features I like here, but there are too many to list.

With the funding, Superhuman plans to build a version for Outlook and other email applications, build calendaring functionality, and build integrations into apps like Grammarly and Salesforce. I'd also expect that they begin to go deep into B2B, which will be great for the larger enterprise software industry.

I've written at length about the broken, top-down incentives that exist in enterprise software procurement that allow bad products to get widespread distribution. Superhuman has taken the opposite approach. It's a consumer app that costs $30 per month and competes with many other high-quality, free email applications. The only way that works is if the software is of extremely high quality. That's what Superhuman is. They overinvest in design and user experience and have a hard ROI around time savings.

Increasingly, employees are demanding that the software they use at work be of the same quality as the software they use in their personal lives. Superhuman's expansion into the enterprise will only help accelerate that trend.

Leverage

Over the weekend I read the Almanack of Naval Ravikant. Naval is an investor and entrepreneur and the founder of AngelList. The book gives his unique perspective on building wealth and enjoying life.

I flew through this book. I literally couldn’t put it down. The part I enjoyed the most was his perspective on leverage. He believes that leverage is the thing that leads to wealth. You can get leverage from people working for you. You can get leverage from investing your money. But the highest form of leverage — the new form of leverage — is to spend time selling or building products with no marginal cost of replication. This is easy to do in the digital age. You can write some code that can create infinite value, well beyond the time you put into writing the code. You can create a podcast that millions of people can listen to. These are things where the output is disconnected from the input. This blog post is a form of this leverage. It only took me a few minutes to write, but it can be read by millions of people for years to come.

As Naval points out in the book:

A general contractor has more leverage than the person that repairs the house.

A real estate developer has more leverage than the general contractor.

A money manager of a real estate investment fund has more leverage than the real estate developer.

Zillow has more leverage than all of them.

You see that as you climb the ladder, the value created gets more and more disconnected from the input. Zillow, in addition to having labor-based leverage (employees) and money-based leverage (venture capital), also has code-based leverage (leverage that can scale infinitely with near-zero marginal cost). Whereas the person repairing the house has none of that. That person is paid an hourly wage that is tied perfectly to the amount of time he or she puts in.

I really like this way of thinking about modern-day wealth creation. Spend your time on high leverage activities and projects, particularly those that are digitally-oriented. This is one thing I think people miss when they point to tech stocks being overvalued. These companies can get really big really quickly. That can be hard to wrap your head around.

The full excerpt on leverage can be found here. I highly recommend giving it a read.

Slack Connect & The Future Of Business Software

Slack recently announced Slack Connect, a product that allows disparate companies to collaborate inside of a Slack channel. They now have more than 40,000 customers using the product.

For those interested in business software, I think there's reason to believe that products like Slack Connect — software that allows users across different companies to collaborate inside the same instance of that software — will lead to a trend that's even more impactful than the shift to the cloud.

Slack Connect users can have a shared Slack channel with their customers, vendors, partners, and prospects. I haven't used the product yet, but I recently collaborated in real-time with a customer to build a presentation using the same instance of Google Slides. It was so much more efficient. Imagine finance teams collaborating on complex invoicing issues inside the same instance of Netsuite. Or project managers at separate companies collaborating inside of SmartSheet. Or a salesperson collaborating with on a customer's buying process inside the same instance of Salesforce.

Moving core, cross-company business activities into a shared workspace will be enormously valuable to the users inside of each company. And even more impactful is the impact on distribution and go-to-market. Suddenly, Netsuite, SmartSheet and Salesforce have native network effects (e.g. their software is more valuable to each user when more users use it). This is why Slack Connect is so interesting. Slack already had network effects inside of a company, but growth was limited to the size of each individual company. Slack Connect enables unlimited network effects.

Don't get me wrong, like the move to the cloud, there are enormous challenges for software vendors that pursue this strategy. There's a reason I don't collaborate on Google Slides with the majority of customers. Most large companies aren't using Google's applications, and thus users don't have a log-in and aren’t authorized to use their personal one for work purposes. There are significant privacy and adoption challenges that need to be overcome.

Slack has an advantage here in that their core customer base is still startups, small businesses, and tech companies (though they’re rapidly moving upmarket). This core allowed Slack to get Connect into market much more quickly than Microsoft could've with its Teams product.

The irony of Microsoft being behind on this is that they own the one asset that could've accelerated the growth and adoption of cross-company messaging — LinkedIn.

LinkedIn already knows most professionals’ "professional social graph." These social graphs are the underlying infrastructure that enable a network to grow. Consider Whatsapp, who built a nice messaging app and then tapped into your phone's address book (your social graph) to seamlessly build out its network. They went from 0 to a billion users in just a few years. They never could’ve done that if they didn’t have access to people’s personal address book. LinkedIn is the world’s professional address book.

LinkedIn messaging could've been a far better and faster-growing version of Slack Connect. But LinkedIn underinvested in its messaging feature to the point that it's almost unusable. The spam is overwhelming, and the poor user experience makes it impossible to use productively.

This miss isn't really a surprise, and I'm not playing Monday morning quarterback. Microsoft hadn't built its initial software around connecting disparate companies. In fact, it was quite the opposite. And turning the tide isn't easy. Also, LinkedIn's core customers are recruiters and marketers; use cases where the value of cross-company collaboration isn't obvious.

So, all of this is to say that there's an enormous opportunity for emerging SaaS companies to build native cross-company collaboration tools into their code, use cases, and culture from the outset. It's hard to predict that any trend is business software will be as impactful as the shift to the cloud, but if there's one out there, this might be it.

Business Models & Tech

This somewhat dated (2015) but still highly relevant essay by Alex Danco offers an insightful overview of the state of software in healthcare. If you care about this sort of thing, I highly recommend reading it.

The most interesting aspect of the piece for me is the reminder that when tech impacts or “disrupts” an industry, the tech isn’t necessarily the interesting part. The interesting part is the business models that change or emerge as a result of the tech.

Here are a few examples of what I mean:

Spotify leveraged technology to change the business model of music from $10 per album to 40 million songs for $10 a month.

AirBnB leveraged technology to change the hospitality business model, listing 6 million rooms and homes while owning zero properties. 

Uber leveraged technology to change the taxi business model, doing 4 million rides per day, while owning zero vehicles or taxi medallions.

As we consider how much software has impacted (or not impacted) healthcare, we shouldn’t be looking for the flashy, healthcare-specific, transformational technologies. We should consider the new and emerging business models that are enabled or enhanced by technologies. Those aren’t hard to find.

Collaboration & Enterprise Software

Kevin Kwok wrote a must read piece a few weeks ago about how crucial it is for collaboration to be a fundamental, “first party” aspect of enterprise software.

People think of Slack as a collaboration tool. But Kevin makes the point that a major reason Slack is so necessary (and valuable) is that other applications and business processes are fundamentally broken. You need Slack to fill in the gaps. You switch out of a productivity app (Salesforce) and move to a collaboration app (Slack) because Salesforce doesn’t have collaboration as a primary aspect of the product.

As an example, a sales manager might be in Salesforce and notice that a revenue number on a particular deal is inaccurate. The manager will go to Slack and send a message to the rep. The rep will respond in Slack and go fix the number in Salesforce. If Salesforce was truly collaborative, all of this communication would’ve happened inside of Salesforce. But it’s not. And that’s where Slack picks up the slack for non-collaborative business applications (pun intended). From the piece:

“The dream of Slack is that they become the central nervous system for all of a company’s employees and apps. This is the view of a clean *separation* of productivity and collaboration. Have all your apps for productivity and then have a single app for coordinating everyone, with your apps also feeding notifications into this system.

But productivity *isn’t* separate from collaboration.

.…

It’s not that Slack is too distracting and killing individual productivity. It’s that your company’s processes are so dysfunctional you need Slack to be distracting and killing individual productivity.”

For the first 10 to 15 years of my career, I used Microsoft Office applications. I didn’t consider anything else. They had a total monopoly. In the last five or so years that has completely changed. I never use Word or PowerPoint (I still use Excel frequently). For word processing and presentations I almost exclusively use Google Docs and Google Slides. I’ve made this change for one reason and one reason only: collaboration. G Suite (Google’s suite of productivity applications) is fundamentally built on collaboration. It works really well. Collaboration in Microsoft Office applications is clunky and was clearly an afterthought. It’s very difficult to start with productivity only, run that playbook for several years and then back into collaboration. Collaboration from the outset makes things a lot easier.

Healthcare software is suffering greatly from the fact that the software clinicians use didn’t have collaboration as a fundamental part of the code. Most medical software was rushed to market in response to government incentives and collaboration across different organizations wasn’t important. Now, like Microsoft Office tried to do, many of these applications are trying to back into collaboration as a fundamental feature and it’s not working.

This is one of many reasons that PatientPing exists and is growing so quickly. Our software puts collaboration first. Our entire platform is built around collaboration and allowing disparate healthcare organizations to collaborate on shared patients. We’ve tapped into a desperate need because of the way healthcare software was developed. If collaboration had been build into healthcare software from the beginning, our product wouldn’t be in such demand.

Similarly, Slack is widely touted as the fastest growing business application in history. Not to take anything away from their success, but much of the reason for their success is that Slack picks up the slack of so many other widely distributed productivity applications across nearly every industry. The lack of fundamental collaboration in productivity apps created the conditions for Slack’s massive success.

Some Thoughts On Enterprise Software: Increasing Consumerization, A SaaS Bubble & Cross-Company Network Effects

Here are some thoughts related to enterprise software that have been rolling around in my head for the last few weeks.

’Consumerization’ Of Enterprise Is Accelerating

Aaron Levie (founder of Box) tweeted this the other day following the Zoom IPO:

The tectonic shift causing a new era of enterprise software is that product development, distribution, adoption, customer service, and design look vastly more like a consumer company than a traditional enterprise company.

— Aaron Levie (@levie) June 23, 2019

I’m not sure we’re fully there yet, but the tectonic shift Aaron refers to is absolutely happening faster than I had thought.

Back in 2011, Chris Dixon wrote a blog post discussing why consumer tech is so much better than enterprise tech. I posted this comment:

“In a [B2B] transaction, one good salesperson (the “seller”) only has to sell one person (the “buyer”) on the value of the technology. Once the product is sold, the buyer forces their 50,000 employees to use that technology whether they like it or not. A good salesperson with a good deck can do this fairly reliably.

And a good account manager can typically retain the client for a while; employees usually get used to the product and rarely complain enough for the buyer to cancel the contract and force the seller to improve the product. As a result, an enterprise product can suck and still flourish.

With a B2C product, this is much, much more difficult. The seller has to sell 50,000 individual “users”, one by one, on the value of the product without the luxury of a face to face meeting or 18 holes on the golf course. The B2C model forces the seller’s product to “sell itself”. As a result, a consumer product can’t suck if it wants to flourish. It has be good. Much better than the enterprise product needs to be.”

In light of the Slack and Box IPOs, things are looking a lot different than they did back in 2011. There are a few trends causing enterprise software to look more like consumer software.

1/ Bottoms-up enterprise distribution is expanding. This is where an employee within an organization signs up for a service and tells a few colleagues. Soon, when enough employees are using the product, a sales call is triggered and the salesperson tries to sell the product into the organization top-down. Unlike the old days, this strategy only works if the product is really solid.

2/ Micro use cases are increasing the number of buyers inside an organization. The purchase of a CRM or ERP system will likely always be a complicated, top-down decision. But because of the emergence of SaaS products with narrow use cases that require relatively small budgets, the purchase of a SaaS product that, say, improves the efficiency of making sales commission payments to salespeople, will lie with a middle manager in the sales operations or finance function. When buying responsibilities are spread more widely and the decision maker is closer to the user (or is the user), the quality of the product has to improve.

3/ Buyers are getting smarter and products are getting more transparent. The internet has enabled thousands of micro trade groups and private communities to form, allowing professionals to share insights and best practices and advocate for one another. I recently joined a collective of revenue leaders from all over the world. We have a Slack account that we use to share information, ask one another questions, etc. There’s a #techstack channel where we discuss different SaaS products focused on sales and marketing organizations and our experiences with them — Outreach, Gong, Troops, Docusign, etc. I’ll never buy another sales-oriented SaaS product without consulting this Slack channel. At some point, nearly every buyer within a company will be a member of one of these groups (if they aren’t already). This only accelerates the transparency of information for buyers and makes product quality and delivery equally important — and in many cases, more important — than distribution.

There are still a lot of old school industries where top-down purchasing is a requirement because of outdated buying practices, the need for legacy system integration, security concerns, etc. But in the coming months and years enterprise software will continue to look a lot more like consumer software.

A SaaS Bubble?

I’ve heard many people refer to the explosion of SaaS as “the unbundling of Microsoft Excel”. That is, Excel used to do everything for us but now a bunch of companies have peeled off use cases and have built SaaS products around those use cases. This is really true in many ways. Fifteen years ago the companies I worked with did just fine without many of the SaaS applications we have today. We just did all of it in Excel. Sales pipelines, expense reports, commission payments, time tracking for consultants, project management, OKR management, etc. Now all of these things are managed by products like Salesforce, Expensify, Exactly, Harvest, SmartSheet and 7Geese. Companies today use so many SaaS products that Parker Conrad, the founder of Zenefits, raised $60MM to start Rippling, a new SaaS company that helps organizations set up and manage access to all of these applications. Largely due to bottoms-up distribution, the number of applications being used inside today’s companies has gotten way ahead of many system administrators.

Related to all of this, we’re due for an economic slowdown. Recessions seem to come around every ten years; we had the oil price shock recession that started in 1990, the tech bubble recession that started in 2000 and the mortgage crisis recession of 2008. We’re just about due for another one as we head towards 2020. When economic growth slows, it’ll be interesting to see the impact on many of these SaaS products. Many of them seem like ‘nice to haves’ rather than ‘must haves’. If that’s true, you have to wonder how many CFOs will cut back on some of these products and force their teams to go back to using tools like Excel. ‘Bubble’ is a strong word. And those that are bullish on SaaS will tell you that the market share of enterprise software that sits on the cloud is still a small fraction of total enterprise software spend. But it does seem logical that the boom is SaaS is supported by the bull market we’ve been in.

Enterprise Network Effects

Perhaps the most exciting thing happening in SaaS these days is network effects across companies. Network effects happen when you have a product that gets more valuable to each user as more users use it. Facebook is a classic example — the more friends you have on Facebook the better your experience is on Facebook. But now we’re seeing cross-company network effects all over the place. Box.com allows companies to share files with their customers. Companies can invite their customers to Slack channels. My company, PatientPing, is a classic example of how this happening in healthcare. It will be interesting to see how far this goes. Competitive and privacy concerns cause companies to be hesitant to share and open up their data troves to competitors and even vendors in many cases. If a company like Salesforce could find a way to get their customers to open up their data it would change the world of enterprise software. The use cases would be infinite. A fun trend to watch in the coming years.

It used to be that employees would sit around the water cooler chatting about systems and processes that don’t work as well as they could or complaining that they’re spending too much time doing low-value work that could be automated with software. This is still true. But now that it’s so easy and inexpensive to launch a software company, many of those same employees are realizing that other companies have the same set of problems and they’re building companies around solutions to those problems. As we’ve seen with Slack, Zoom, and others, some of these solutions can be multi-billion dollar companies.

Enterprise software used to be considered the boring part of tech. It doesn’t seem so boring anymore.

How Silicon Valley Became Silicon Valley (And Why Boston Came In Second)

When I was a kid growing up in central Massachusetts, I remember that a bunch of my friends' parents worked for super high growth tech companies like Digital Equipment Corporation (DEC), Data General, and Prime. While some people reading this may not have heard these names, these companies were behemoths. In the late eighties DEC alone was one of the largest companies in the world and employed more than 120,000 people. These companies were booming at the time in an area known as the “Route 128 Corridor”. Route 128 is a highway that runs south to north about 10 miles to the west of Boston. The area was a hub for technology companies — mostly focused on semiconductors, microprocessors, and minicomputers. It seemed like almost all my friends' parents worked at one of these companies or a company that provided support to these companies.

I also remember the bust that came in the early nineties when many of these companies downsized and thousands of people lost their jobs. It was a rough time for many people in the area.

What I didn't know at the time was that there were a set of competitors based in Santa Clara County, California, in the area now known as Silicon Valley, viciously competing with the Route 128 companies. Companies like Hewlett Packard, Intel, and Apple.

Most people now know that the Silicon Valley companies came out on top and that the tech scene in the area outpaced eastern Massachusetts significantly. Massachusetts remains one of the top 3 tech hubs in the U.S., dominates biotechnology, and is well on its way to becoming the country’s Digital tech hub. But outside of healthcare, the Silicon Valley area is far ahead and sees about 3x the number of startups and venture funding than the entire state of Massachusetts.

That said, back in the mid-1980s, you would've had no idea which region was going to come out on top. It could’ve gone either way.

AnnaLee Saxenian wrote a phenomenal book about all of this titled, Regional Advantage: Culture and Competition in Silicon Valley and Route 128 that examines the differences between the two regions.

Having lived in and worked in both areas, here are some of the key differences between the regions that I think allowed Silicon Valley to outperform. Certainly some of the takeaways are isolated to these regions at that point in time. But as lots of cities across the country try to increase the number of tech startups launched in their communities, many of the lessons from the battle between Silicon Valley and Route 128 can be applied by policymakers and tech leaders today.

Cultural differences

Massachusetts had a much more traditional, risk-averse approach compared to the Valley. A big reason for this comes from the parochial and puritanical cultural history of Massachusetts. But, more practically, it also comes from the fact that most people that worked in Silicon Valley weren’t from California. They were from the east coast or the midwest. You can’t underestimate the impact this has on a region. People aren’t spending time with their high school friends or church friends or summer camp friends. They’re spending time with the people they work with. And what do they talk and think about during that social time? Work. They’re bound together by their work. And they're much less worried about trying something new and failing at it because their friends and family back home may not even know about it. An executive that worked on both coasts described it this way in the book:

“On the East Coast, everybody’s family goes back generations. Roots and stability are far more important out here. If you fail in Silicon Valley, your family won’t know and your neighbors won’t care. Out here, everybody would be worried. It’s hard to face your grandparents after you’ve failed.” —William Foster, Stratus Computer

This meant that people in the Valley were much more willing to take risks, start companies and jump from job to job. As they jumped from job to job and made friends with people at work, they created networks centered around their work across several companies in the region. It was common for an engineer to quit their job on a Thursday and show up at another startup on Monday. These new experiences led to more friendships and led to a ton of collaboration between companies and an openness to sharing with one another for the greater good. It was common for Silicon Valley competitors to call one another for help with technical problems. This kind of collaboration created a rising tide for everyone in the area. The power of this kind of environment is enormous.

By contrast, in Massachusetts, most of the people working in tech were from New England. From the book:

”The social world of most New England engineers, by contrast, centered on the extended family, the church, local schools, tennis clubs, and other civic and neighborhood institutions. Their experiences did little to cultivate the strong regional or industry-based loyalties that unified the members of Silicon Valley’s technical community. Most were from New England, many had attended local educational institutions, and their identities were already defined by familial and ethnic ties.”

There was a separation between work and social life for Route 128 workers. For workers in the Valley, it was much more of a grey area. Workers in Route 128 tech often went right home after work and immersed themselves in their local towns, where they had ties that went back generations. Workers in the Valley didn’t have these ties. Instead of driving several miles back to their town, they were more likely to go out to dinner or to a bar in the area to talk about technologies and markets.

Job hopping

As mentioned above, workers in the Valley would jump from job to job growing their network and gaining new experiences. Route 128 had a much different culture where loyalty was highly valued and if you left you could never come back. Workers often stayed at their jobs for 10+ years. This was unheard of in the Valley. Workers felt that they were working for the Valley — the community — rather than for an individual firm. If they decided they wanted to come back they were often welcomed with open arms. As I've written in the past, this impact is felt today as California has banned the use of employee non-compete agreements while Massachusetts has allowed them to persist.

Collaboration with universities

Stanford actively promoted startups by offering professors up to help with product development and created several funding mechanisms for new ideas. MIT took a far more conservative approach and was very reluctant to invest dollars or time into things that were too risky. This created artificial walls between the best tech companies and the best technical research. Many of the east coast companies claimed they had better working relationships with Stanford and Berkeley than they did with MIT and Harvard.

Dependence on government contracts

Because of its proximity to Washington, Route 128 companies had lots of reliance on government contracts that had long term obligations that restricted innovation. It also (appropriately) led to a secretive culture that stalled collaboration with associations, competitors, partners, and other organizations in the local ecosystem. By contrast, by the early seventies, Silicon Valley companies were receiving far more financing from venture capital investors than they were from government contracts. The east coast's dependence on government contracts made widespread collaboration nearly impossible.

Geography

Silicon Valley companies started around Stanford and expanded to cities like Mountain View and Santa Clara but couldn’t go too far as they were locked in by the Santa Cruz mountains to the west and the San Francisco Bay to the east. This led to a very dense community of tech companies. By contrast, the Route 128 companies were spread far and wide. DEC, the largest of the companies in the eighties, was based in Maynard, with more than 20 miles of forest separating them from the hub of Route 128.

Organizational structure

Related to the dependency on defense contracts and its proximity to established political and financial institutions, Massachusetts companies were more formal and created organizational structures that had a strong resemblance to the military. This kind of organizational design can slow innovation as the lower rungs of the ladder are less reluctant to offer new ideas and there's far less cross-functional learning. Executives had their own parking spaces and executive dining rooms. Stock options were only offered to those at the highest levels of the organization. This even applied to work attire — the uniform for 128 companies was a jacket and a tie, in the Valley it was jeans and a t-shirt.

Today, something like 75% of all venture capital funding goes to three states -- Massachusetts, California and New York. As governments and entrepreneurs across the country try to expand the number of tech companies that emerge and grow in their communities, it’s important to remember that ecosystems create a lot more jobs than companies. The key is less about funding and micro-incentives and more about creating the complicated environment that allows an entire ecosystem to thrive.

The Apps > Infrastructure > Apps > Infrastructure Cycle In Health Tech

Union Square Ventures had a great blog post the other day on The Myth of the infrastructure Phase. 

They argue that the narrative in tech that says there’s an orderly infrastructure phase followed by an application phase is a bit of a myth. Instead of orderly and distinct phases, they argue, it looks more like an ebb and flow. Apps, in many cases, drive infrastructure then that infrastructure enables new apps, and vice-versa. From the post:

“Planes (the app) were invented before there were airports (the infrastructure). You don’t need airports to have planes. But to have the broad consumer adoption of planes, you do need airports, so the breakout app that is an airplane came first in 1903, and inspired a phase where people built airlines in 1919, airports in 1928 and air traffic control in 1930 only after there were planes.

The same pattern follows with the internet. We start with the first apps: messaging (1970) and email (1972), which then inspire infrastructure that makes it easier to have broad consumer adoption of messaging and email: Ethernet (1973), TCP/IP (1973), and Internet Service Providers (1974). Then there is the next wave of apps, which are web portals (Prodigy in 1990, AOL in 1991), and web portals inspire us to build infrastructure (search engines and web browsers in the early 1990’s). Then there is the next wave of apps, which are early sites like Amazon.com in 1994, which leads to a phase where we build infrastructure like programming languages (PHP in 1994, Javascript and Java in 1995) that make it easier to build websites. Then there is the next wave of more complicated apps like Napster (1999), Pandora (2000), Gmail (2004) and Facebook (2004) which leads to infrastructure that makes it easier to build more complex apps (NGINX and Ruby on Rails in 2004, AWS in 2006). And the cycle continues.”

We’ve seen this trend in healthcare technology as well.

The first electronic medical record dates back to the 1960s when Dr. Larry Weed created the problem-oriented medical record that allowed his fellow providers to see notes, medical history, etc. in an electronic format (application). The first EMR as we know it that included additional functionality such as billing and scheduling was launched in 1972 by the Regestrief Institute, though adoption was extremely slow. In the 1980s, the need to transfer clinical information between providers led to the creation of Health Level 7 (HL7), a set of international standards for transfer of clinical data between different applications (infrastructure). By the late 1980s, low-cost personal computers (more infrastructure) allowed providers to do what Dr. Weed was doing at scale. The emergence of the internet in the 1990s (more infrastructure) allowed providers to use electronic medical records remotely, increasing adoption and leading to more use cases (more applications).

Today, thanks to meaningful use incentives enacted under President Obama, the vast majority of healthcare providers use electronic medical records and Dr. Weed’s initial application has become an infrastructure of its own. EMRs, originally just a collection of apps that sat on top of an infrastructure, have now become the infrastructure for a new wave of applications that can plug-in to the data stored within the EMR.

Now we’re seeing a new layer of infrastructure being built that will connect all of these EMRs to one another across the full continuum of care — acute to subacute to post acute to home care to ambulatory, etc. There are lots of organizations working on this (including my own) and there’s no doubt that success is on the horizon.

Once this “connective” infrastructure is built we’ll see a new wave of health tech applications that will be built on top and will bring enormous value to our healthcare system.

We don’t need airports to have planes, and we don’t need connectivity to have medical records. But pilots, patients, and providers are a lot better off when we do.

Some Thoughts On Apple And Personal Health Records

There was a lot of buzz going around this past week around Apple’s announcement that they're adding a personal health record to the iPhone. 

Of course, this has been tried before; Google, Microsoft, and many, many others have tried and failed. This time Apple has a better shot in that they 1.) have a device in people's hand and 2.) they've partnered with several large hospitals & health systems and electronic health record (EHR) vendors to pull data down to the device.

Bijan Salehizadeh asked the right question on Twitter: did past efforts at consumer-driven personal health records not work because of poor user experience or did they not work because people just don’t care enough about their health records?

I’m in the camp of people not caring enough. Put aside the importance of what Apple is trying to accomplish and the incredible impact it could have if it were successful and get back to the basics of consumer behavior and what makes an iPhone app work. 

In order for someone to choose to spend time on an app (when there are millions of them in the app store) the user needs to get something in return. And they need to get that return quickly. When I search for a restaurant on Foursquare I get a return (recommendations). When I use OpenTable I get a return (a dinner reservation). When I use WhatsApp I get a return (a conversation with a friend). When I use Spotify I get a return (music).

But what does the consumer get when they upload a bunch of health data into the Apple health record? Nothing. At least not immediately. At least not until they’re sick. Which they hope they never are. There's no clear return. This is the challenge with patient-driven health records.

This is part of the brilliance of Zocdoc (disclaimer: I worked there for almost 4 years). They are able to compile important health information from the consumer. Lots and lots of it. Every single day. They’re able to do it because the user gets something in return immediately for engaging and sharing their health information (a doctor’s appointment). 

In my view, the companies that have failed on personal health records have failed because they didn't fully appreciate the way consumers engage with their own healthcare and they ignored the core tenets of consumer behavior. People are busy and have been trained to ignore everything unless it makes them feel good or gives them some near instant utility. Unless Apple's personal health record app can find a way to deliver utility back to the user (quickly) I fear that it may share the same fate as those that have tried and failed.

Enterprise User Acquisition & Consumer User Retention

In thinking about a product's user acquisition, the nice thing about enterprise products is that when you get one customer you get a lot of users. You just need to sell one CIO on your product and you’ll quickly pick up thousands of users.

The not so nice thing about enterprise is that you’re going to lose about 20% of those users every year due to employee turnover. Your entire user base is going to turn over every five years. Acquisition scales in enterprise. Retention does not.

The not so nice about consumer products is that, unlike enterprise, you have to acquire users one by one. You don’t have the scalable distribution channel that you have with enterprise. In consumer, user acquisition is expensive and really difficult.

But the nice about consumer products is that once you get users you can keep them forever (you don’t have the turnover problem).

It’s interesting to note that some companies have figured out how to take the good from enterprise and the good from consumer.

One example is eShares, an enterprise product that digitizes paper stock certificates and options and warrants and rolls them up into an easy to use cap table to help startups and startup employees manage their equity. Employees generally sign up for the service just before their start date when they receive an option grant from their new company (to sign the option grant employees need an eShares account). If the employee leaves the company they keep their account open to manage their equity and they can add subsequent option grants from subsequent companies to keep all their documents in one place.

eShares is brilliant in that they have morphed an enterprise product into a consumer product and have reaped the benefits of both models. This is a super powerful way to quickly build a huge set of engaged users and is a great way to get ahead and build a platform rather than just a useful app. I’m sure eShares investors are taking note.

Sharing & The Next Generation of Enterprise Software

Salesforce.com runs the CRM system (Customer Relationship Management) for a huge number of companies — at last check more than 150,000. It’s interesting to think of the number of duplicate records that must exist in Salesforce. As an example, there are probably hundreds of vendors that, as we speak, are trying to sell their product into Microsoft. Each of these vendors has a record (or opportunity) titled, “Microsoft” in their instance of Salesforce. In many situations, such as sales to a large software company like Microsoft, this redundancy makes sense. Most of the vendors selling to Microsoft are selling very different products to very different stakeholders within the company. So it's logical to have a different record in Salesforce for each sales opportunity.

But for narrow industries like real estate, this redundancy makes no sense at all. As we speak, there are at least ten brokers trying to rent space on the 11th floor of 600 Park Avenue in New York. If all of these brokers use Salesforce.com as their CRM that means there are ten records for only one sales opportunity. Ten brokers would be entering information on the same opportunity in ten different places. This is silly. But this is the way traditional, silo'ed CRM works.

Real estate brokers would benefit immensely from shared records in Salesforce where they all could view the same profile for the same sales opportunity. The opportunity would include the most up to date information on availability, square footage, price per square foot, etc. This would bring 10x more value to Salesforce's customers.

Now consider what's happening in healthcare. The average Medicare patient sees seven providers per year; if the patient has a chronic condition it can be many more than that. These seven providers don’t work together. They’re employed by different organizations, work in different locations and likely use different medical record software. This means that there are seven separate records in seven different places containing seven separate sets of information for only one patient. This isn't just wasteful, it makes it impossible for providers to work together to optimize patient care.

Real estate, healthcare and many other industries need software that doesn't simply get the same job done seven or ten times across disparate organizations but instead brings all of the stakeholders together to use a single, shared record.

Of course there are a number of challenges associated with building this type of networked software -- not the least of which is getting disparate stakeholders to agree to share important information with one another. But I'd guess that a big segment of the next generation of multi-billion enterprise startups will build software around sharing and networks as opposed to silos and features.

Enterprise Network Effects & User Retention

A16z had a good podcast the other day talking about startups with network effects and it got me thinking about network effects in enterprise businesses. A product has network effects when the product becomes more valuable as more people use it. Your fax machine was more valuable when more people bought fax machines — you could fax more people. Facebook is more valuable when more of your friends use it -- you can view more photos of your friends.

Businesses with network effects scale exponentially. The reason is that their users effectively become extensions of their sales and marketing team. A Facebook user has an inherent incentive to get other people to use the product. This is a beautiful way to grow and scale a business.

In order to maintain growth, though, these businesses need to ensure that they're retaining the users they acquire -- which is an entirely different challenge. This is relatively easy in B2C because, in theory, the user can be part of the network forever. This is much harder in B2B because users — employees — turnover at the rate of ~20% per year (people get terminated and quit). So in theory, the entire network turns over every five years. And while it's true that often an employee that leaves is replaced by another this kind of churn is not a great way to scale.

That said, some B2B network effect businesses have found ways to retain some users after they change jobs. LinkedIn, Evernote, Wunderlist, Dropbox are a few that come to mind. Not only do these businesses retain their users as they move from job to job, these users also drive new customer acquisition by promoting the product within their new companies (what I refer to as B2E2B). These businesses are seeing network effects drive new users, retention of those users when they move to a new job, and new sales driven by those employees that evangelize the product in their new companies. This how an enterprise business can grow like WhatsApp.

But this isn't easy. Enterprises are concerned about their employees using the same software as they move from company to company -- e.g. they don't want an employee taking their Evernote notes on to their next company. And the product customizations and switching costs may be so high in some cases that the value of the product doesn't translate from one company to another.

The challenges are significant; but the businesses that build an enterprise product with 1.) inherent network effects to drive new users and 2.) the ability for those users to stay engaged with the product as they move from job to job will be the networks that win. 

A List Of Health Tech Startups

For a while now I've been keeping a running list of the health technology startups I come across sorted by the category they compete in. There are about 100 companies on the list.  I've moved the list over to an open Hackpad that you can find here. Hopefully this list will help people better understand what's happening in the industry, research competitors and even discover new investment and job opportunities.

I've left the Hackpad open so that anyone can add a company or category. Please add any that I've missed (I'm sure there are a lot).

As we move to the "Post-EHR" world where innovation is led by patient and provider needs as opposed to government mandates, I'm sure we'll see even more startups and categories emerge -- so I expect this list to get a lot longer.

The Next Big Thing In Healthcare Technology Will Start Out Looking Really Small

Fred Wilson had a great post last week titled, Bootstrap Your Network With A High Value Use Case. He points out how Waze's initial value proposition was to help drivers that like to speed identify speed traps. But it of course quickly expanded way beyond that and now provides lots more value to lots more drivers. It has become mainstream. Same thing with Snapchat -- it started out as a "sexting" app and has now expanded to more applications and is used by the mainstream. This is sometimes called the "bowling ball strategy" in new product development where you focus on knocking down the first pin by being very focused on one segment and one application and then you gradually knock down more pins (segments & applications) over time until your product works for the mainstream. The idea is to find a narrow niche that loves what you're doing, refine the product and expand from there.

Related to healthcare, this blog has talked a lot about centralizing patient data with the patient, as opposed to multiple medical records across multiple healthcare providers. Most would agree we need to get to this place but the path to getting there isn't terribly clear. Patients aren't clamoring for it yet and there will likely be some resistance from software vendors and healthcare providers as it flies in the face of the strategy of owning the data and, by extension, the patient.

My guess is the way that we're going to get there is similar to the way that Waze built a massive maps business and Snapchat built a massive photo sharing business -- it's going to start with a small niche.

I can see an application that has built a network of highly engaged users with a very specific and highly sensitive medical condition that shares important clinical information back and forth between provider and patient becoming the starting point for consumer-driven patient data. Big software vendors will likely ignore this application because it impacts a small niche and the patients will be highly engaged because their affliction is such an important part of their lives. Once the product is refined it can be extended to other patient segments with other medical conditions and it'll grow from there.

As Chris Dixon likes to say, "the next big thing will start out looking like a toy".

In this case, the next big thing in healthcare technology will start out looking really small: a simple tool that serves a very small, but highly engaged set of patients.