Slack Connect & The Future Of Business Software

 
slack logo .png
 

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:

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.

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

LinkedIn-Chart 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.