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.


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

How Much Should A Startup Charge Its Early Customers?

Last week I had a conversation with a founder about how much they should charge their first few customers. Cost plus a fee? Slightly below the incumbent? The same as the incumbent? Some fraction of the estimated ROI? My answer to this question is pretty simple: charge as much as you can get, charge whatever the market will bear.

At an early stage, a founder's time and focus is the firm's number one asset. Any compromises made in getting less than the absolute maximum amount that a client will pay creates an unrecoverable opportunity cost. Early-stage companies can't afford to not charge what the market will bear.

Pushing for the max more has other benefits. It helps to determine the product's real worth and the real challenges the client is having in buying the product. When pricing makes buying too easy you don't get a good sense of the challenges you'll encounter down the road, you don't get the real story. It also generates a level of respect from the client (we've all heard the stories of people appreciating things more because they cost more regardless of the true value).

Finally, often a startup's instinct will be to charge less because it'll move the deal along faster. This is a myth. The opposite is true. The larger the deal the more attention it will get, the more senior people will need to be involved and it'll move faster as a result.

This post isn't meant to say that you shouldn't negotiate, do a pilot and be flexible where and when it makes sense. You should do all of that. But in lieu of a defined market price, charge a simple one -- the absolute most that you can get.

The Interface Layer & The New Economy

I've been thinking a lot about this notion of the "interface layer" in web services and how it's changing the economy and the way money flows. The concept of the "interface layer" is pretty simple. It says that the old economy was about building tangible infrastructure -- cars, buildings, stores, etc. And the new economy is about building really slick and beautiful and easy to use web services (interfaces) on top of that infrastructure;AirBnB for lodging, Uber for ride sharing, OpenTable for restaurants, Expedia for planes, etc. These companies don't own buildings, cars, restaurants or planes, but they make a lot of money by allowing consumers to easily access these things. It's no longer about building infrastructure, it's now about building beautiful, slick, mobile, easy to use 'layers'.

One of the big complaints about these layers (or interfaces) is that many believe that they commodotize the underlying asset. Uber users don't really care which cab company the driver is a part of, they just want the cheapest ride that gets them from point A to point B. This detachment from the brand drives down the cost of the ride and drives down the income that goes to the driver. Uber is commodotizing drivers. And drivers need to think really hard about how they're going to separate themselves from the pack if they want to continue to charge a premium.

Uber's layer is winning the taxi space.

But with the increasing use of mobile and the decreasing use of the desktop web, mobile is quickly becoming a platform on its own. And soon, instead of Uber being the 'commoditizer', Apple's iPhone or Google's Android could easily commodotize Uber.

Let me explain. Today, if I want a ride somewhere I go to Uber or Lyft or Sidecar or some other app to book a ride. This is a bit clunky in that it's hard to know which of the services has the best option for me based on the time of day and where I want to go.  I have to download all of the ride sharing apps and scroll through them to find the best deal.

Of course I'm not the only one that's annoyed by this. Very soon (if not already) we can expect that there will be services that will aggregate all of the top ride sharing apps into one so I can pick the best option for me (just like Kayak does for plane tickets).

This would be really bad for Uber. Now they're the one getting commoditized. 

But when mobile is a platform, it gets much worse.

Apple and Google could easily add their own layer on top of these aggregation layers. At some point soon, instead of going to the Uber or Lyft app, I could just open up Siri and say, "give me a ride to SoHo". And Apple will scan all of the ride sharing apps or ride sharing aggregators (even if I haven't downloaded them from the App Store) and deliver the best result. This is absolutely what Siri wants to become -- the entry point to the web.

In an extreme example, I could tell Siri, "take me to my friend's apartment and let's stop somewhere to pick up a bottle of wine that pairs well with Italian food." Siri then decides which ride sharing app, which business directory app, and which wine app to use to bring me the best experience.

Apple could easily cut a deal with a ride sharing aggregator, Yelp and HelloVino (a wine discovery app) and take a fee from each of them. In this case, not only is the Uber driver getting commodotized, so is Uber and so is the ride sharing aggregator.

This is an important issue for any web based service to think about. The new economy might be less about the battle for the most beautiful interface and more about the service that can get closest to the user. And it's beginning to look like platforms rather than interfaces might win the war.

How Mobile Is Impacting Facebook & Healthcare Strategy

Many people used to believe that Facebook was an extremely defensible business and that it would be almost impossible for another social network to compete. It has grown to an enormous scale with massive troves of data and more than 1.5 billion monthly users. The thinking around their defensibility was that because all of your friends and photos and updates are already stored on Facebook, it would be tedious and unnecessary to switch to another social network. Everything you need is there. Why go somewhere else?

Facebook did have quite a bit of defensibility back when the predominant access point to the service was the desktop web. Moving your data to a new social network was painful and impractical. But now that the main access point to social is our mobile phone (more than half of Facebook’s traffic comes through mobile) things have changed dramatically.

We now carry around all of the key elements of a social network on our cell phones. Our phones carry our location, our photos and our address book and allow us to message anyone at no cost from anywhere in the world. With the click of the touchscreen we can view and connect with all of our friends on a new social network and instantly recreate our social graph. We can take a photo and instantly send it to a multiple social networks. We can easily join different social networks with different groups of friends focused around different needs. The friction of leaving Facebook and joining a new network has disappeared. This wasn’t possible with the desktop web, or it was at least much more difficult.

As a result of the increasing use of mobile, we’ve seen lots of new social networks emerge (there are now dozens of social networking apps with 1 million+ downloads in Apple’s app store, including Kik, WhatsApp, Tumblr, Google+, Instagram, Snapchat and many others).

This increased use of mobile has reduced the friction of launching a new social network to near zero and as a result has shifted ownership of data away from the network and back to the individual. Trying to own the data and lock-in the consumer is no longer a viable strategy.

Facebook is well aware of this and has adjusted by rapidly buying up many of these new networks. We’ll likely see more acquisitions like these in the months to come.


Over the last several years, large healthcare provider organizations and healthcare software vendors have been employing a similar strategy to that of Facebook. Health systems have been growing by buying up ambulatory, community-based sites and employing doctors to build out giant systems that can offer clinical services across the entire continuum of care giving the patient no reason to go anywhere else. In parallel, providers and software vendors have been creating a single patient record (including blood tests, physician notes, imaging and other data) that flows across the entire provider organization and can be easily shared with providers across the system. This avoids all of the classic frustration associated with having to fax your x-rays from one provider to another. Everything exists on the web in one single record. Providers then roll out a patient-facing portal that lays across the patient record where the patient can access all of their data (mostly through the desktop web).

The strategy is simple. Providers are telling the patient to 1.) stay with us because we do everything and you don’t need to go anywhere else and 2.) you can’t go anywhere else because we have all of your data.

But as we saw with Facebook, now that a consumer’s primary entry point to the web is their mobile phone, this strategy has some flaws.

Not only do our phones enable messaging and carry our location and address book and photos, they can also carry data on our movement, our sleep, our heart-rate, the prescriptions we’re taking, our body temperature and, with the use of implanted devices, much, much more. This real-time data that we carry on our phones is arguably more valuable than the data stored in our clinician’s patient record that only gets refreshed while we’re sitting in the examination room.

Increasingly, providers will own some patient data but the patient will own more data and better data.

Like Facebook, healthcare providers are trying lock in their customer by owning the data. But the increasing use of mobile has changed the game. Just like social network users can effortlessly syndicate their own data out to multiple social networks, a patient will be able to syndicate their real-time clinically relevant data out to multiple providers, regardless of which system they’re associated with.

Mobile has put patients in the driver’s seat.

Meanwhile, with the emergence of home care and tele-health and urgent care clinics and apps and implants that manage more serious and chronic conditions, in many ways healthcare has actually become more fragmented. The traditional providers may be consolidating, but new players are creating new channels for care and causing more fragmentation across the industry. Where and when and how care is delivered is being completely reshaped.

But unlike Facebook, large healthcare providers can’t buy their way out of this conundrum. First, because they don’t have enough cash (most are non-profits with microscopic profit margins) and second because healthcare is local. Health systems are no longer just competing with the hospital across the street, they’re competing with web services that are available to the global market.

As a result, large provider organizations are going to have to consider new ways of providing value and will have to select which segments of patients they want to serve.

In short, they can’t own the patient because they can’t own the data.

The idea of locking the patient into one network of providers was always a bit flimsy. But the strategy was somewhat understandable. A lot of this was driven by the trend towards value-based payments and the convenience of 'owning' a patient under that model.

But the lessons of Facebook are clear. Locking up the data is not a path to success.

Social networks and healthcare providers must focus on what they do best and focus on serving the consumer they want to serve and abandon their attempts to win by owning data that isn't theirs to own.

The Death Of Enterprise Sales

A few weeks ago I was chatting with a guy that specializes in something called "disruption consulting". Basically he goes into mature companies and works with their management teams to help them think through how they would disrupt their own business. This is a healthy exercise for large, successful organizations and something individuals ought to think about with regard to their own company and -- more importantly -- their own role in their own company. This got me thinking about enterprise SaaS sales and the theory that salespeople have become less of a necessity in this new world. As I've written in the past I actually think the opposite is true. Sales is growing, not shrinking, in importance. That said, here are some of the trends that I've seen out there that are giving the skeptics some ammunition:

  1. Micro budgets. With the 'consumerization' of enterprise software, lots of companies are letting their employees directly buy and expense their own productivity tools circumventing the traditional buying process. 
  2. Pay-per-use contracts. Traditionally enterprise salespeople have sold large buckets of access to their software -- e.g. Salesforce has negotiable pricing tiers based on the number of licenses purchased. Companies like Slack and others are getting away from this model and are pricing based on who actually uses the system. At the end of a month, they look at how many people logged-in and then send an invoice accordingly. This pushes the revenue responsibility pendulum far away from sales and much closer to product.
  3. Freemium enterprise software. This is a model where software can be accessed for free by an individual employee and an enterprise deal gets triggered at some critical mass of employee usage (e.g. B2E2B).
  4. Standardized contracts. More enterprise software companies are creating click-through agreements that can't be negotiated by the buyer. And there does seem to be a very slow but steady move towards more consistency across companies in what they want a contract to look like. Corporate attorneys will make this really difficult, but the idea does seem to be gaining momentum. 
  5. Data in the cloud. The advent of the cloud has made the old-fashioned, big, CIO-based sale a bit less prominent. Cloud-based software programs require much less of an implementation burden and thus much less of the need to sell the bureaucratic IT department. That said, much of the work these teams do has moved towards integration into the cloud, which still requires a hefty sales process.

There's no doubt that the landscape in enterprise sales has changed. And all of these trends are worth watching. But what the skeptics miss is that this is nothing new. Buyers and sellers always been trying to minimize the cost of their transactions. These are just new variations of that process. It simply means that to stay relevant enterprise salespeople must continue to shift their energy towards larger, more complex deals and higher value sales activity.

When real estate listings became available to everyone on the web, real estate brokers didn't disappear (in fact, there are more of them now). They simply started focusing on higher value activity. Instead of their core asset being access to listings, their new asset is helping someone navigate the process of buying a home (over half of home buyers find their home online, but 90% still use a broker to make the purchase).

Similarly, when employees begin buying their own software, enterprise sales teams will just shift their activity towards more strategic, higher value deals. They'll focus on the things that can't be bought or implemented by a single employee.

In short, enterprise sales drives new and incremental growth. It's the hard stuff. The easy stuff gets automated. And diffusion of the greatest innovations and the highest value deals can't be automated.

Companies that aren't growing their enterprise sales teams are likely either very early-stage and don't have enough product to sell, or they're later stage and aren't trying hard enough.

Disruption & Access

I came across thIs chart the other day on Twitter showing camera production from 1933 through 2014. Camera Sales

This chart is great because it perfectly illustrates the good and bad parts of disruption. Better, more portable cameras destroyed the incumbents (Polaroid, etc.). But at the same time these innovations massively increased access to and use of cameras (this is the point that most people miss). It's estimated that there were more photos taken in the year 2014 than there were in all of the years prior to 2014. That's incredible.

The fact is that while disruption can cause some short term pain it almost always results in a greater good for those in the industry. More people travel because of Expedia. More people go out to dinner because of Open Table. More people listen to music because of Spotify. More people get a ride because of Uber. And on and on.

This is perfectly analogous to what needs to happen in healthcare and education. We need the incumbent analogs to go away and the innovators to take over and give access to a lot more people at a much lower cost. We just need the regulators to get out of the way and allow it to happen.

Some Thoughts On Apple & Software For Cars

The tech world is buzzing about the rumor that Apple's plans to build a car. They bought Beats a while back because they needed talent that knows how to make things that people will wear (e.g. a watch). And now they're hiring talent from Tesla that knows how to build cars and software for cars. Benedict Evans had a great post on this topic on Saturday where he offered lots of ideas on the risks and benefits of such a venture. Please go read it if you're interested in this kind of stuff.

I wanted to point out two key points he made in the post here.  From the post:

...can Apple create new value in the industry in the way that it did in phones?  With the iPhone, Apple created a new price segment and (with Android following) made the phone industry's revenue much bigger - the average price of a phone sold has more than doubled since 2007. But cars are, pretty obviously, more expensive than phones. Many people can find $400 for a better phone or, this year, a smart watch, if they're persuaded that they really want one, but rather fewer can find an extra $40,000 for a better car, or to replace their car every two years instead of every 4 or 8.  If you're in the market for a $20,000 car, there is very little that anyone can do to a car that will put you in the market for a $60,000 car. Cars do not come out of discretionary spending.

This is an important point. The iPhone was such a success largely because, in reality, they created a new (high-end) category that didn't exist before. The beauty of that high-end category is 1.) it's actually a mass market category because most people can afford a iPhone -- lots of people that make $50k a year have the exact same phone as people that make $30 million a year and 2.) people buy a new device every two years (that's a pretty nice recurring revenue stream for a hardware business).

Generally, neither of these factors have existed in the car business (most people can't afford high-end cars and the average driver replaces their car about every 10 years).

That said, these dynamics are changing a bit. Celebrities like Leonardo DiCaprio have been photographed driving around in a very affordable Prius (Frank Sinatra wouldn't have been caught dead in a low-end car). And while it's unlikely that the masses will start buying a new car every two years, it is becoming clear that fewer and fewer people are going to need to own their own car -- both because of the astounding growth of on-demand rides and the coming emergence of self-driving cars.

Benedict writes about this later in the post.

...self-driving cars might support both an on-demand model and an AirBnB model for cars - does your car drop you off at work and then roll off into the city to earn you some extra money driving other people around? Would people want to do that? Would that reduce the opportunity for 'dedicated' on-demand vehicles? Who knows. Of course, it's also possible that self-driving technology, said to be a decade away now, will remain a decade away indefinitely, as so many other AI projects have done.

In short, on-demand rides, shared self-driving cars and artificial intelligence are going to lead to massive changes in the way we get around and the way we manage our own personal transportation and the things that we do while we're travelling. And all of it -- I mean all of it -- is going to be driven by software that will become a large part of our day-to-day routine. Apple has to be in the middle of that. Apple has to make a car.

Healthcare Technology: Who Owns The Data?

A couple weeks ago I was listening to a panel discussion with a bunch of venture capitalists and someone (I can't remember who) made the point that the value of so many of today's web services comes down to one question: "who owns the data?" For example, while Uber has some nice UI/UX, the real reason they're so valuable is that they own the data. For them, the data is knowing where all the cars are located. I go to Uber because I can quickly locate and communicate with the drivers in my area. I like the app, but the real value is the location data. Same thing with AirBnB. It's not the app, it's the data they have on all the properties that I'd like to rent.

With this in mind, last week I read that Stanford Healthcare announced that they built the first patient facing app that integrates data from devices such as Fitbits and Withings scales into Apple's Healthkit app. Apple can than transmit that data to the patient's provider through the provider's patient portal app (in this case, MyChart, which is built by Epic Systems, a huge health IT vendor that builds software for hospitals and health systems).

This is an enormous step forward for the integration of patient captured health data with provider captured health data. It's awesome news.

But as all of this finally starts to come together, it begs the question: who owns the data?

Or, at scale, which company benefits the most from all of this data floating around?

Stanford? Withings? Fitbit? Apple? Epic?

Well, Stanford is very local, and isn't terribly focused on data collection, so it's probably not them.

Withings, Fitbit and other device makers contribute a relatively small part of human health data so at least for now they're not going to own a large piece of the data pie.

Apple still only owns well under half of U.S. smart phone market share -- and that number is expected to shrink. And they own even less of the market share of the chronically ill patient segment that can really benefit from this kind of data exchange.

So that leaves Epic, the 30-year-old health IT vendor that currently owns a medical record on well over half of the U.S. population. They have long-term contracts with large providers and (presumably) a long-term contract with Apple and will likely cut deals with Android and other smartphone operating systems in the near future.

In short, more than anyone else, Epic will own the data.

But this raises all sorts of new and interesting questions and conflicts. Will Stanford allow Epic to share its patient records with other Epic providers? Will Stanford allow Epic to share its patient records with other health IT companies? Will Epic allow Stanford patient records to be shared with other health IT companies? Will Apple allow Epic to share data captured from an Apple device with data captured from an Android device?

As I've written before, it seems to me that in the long-term, the answer is a for Healthcare, where the patient truly owns the data. But in the meantime, the question of "who owns the data?" will be watched closely by investors, app makers, providers, health IT companies and patients. It's going to be fascinating to watch this play out. For Healthcare

Vince Kuraltis, a healthcare IT consultant, tweeted this the other day: Vince Tweet

He’s referring to the fact that each of his healthcare providers has a different patient portal run by a different IT vendor with a separate log-in and separate data and functionality. Providers are launching patient portals to allow patients to view clinical records, refill prescriptions, email their providers, etc. The point is to better engage patients in their health. It's a very important effort. But as Vince points out, the disconnected and fragmented experience can be really frustrating for patients.

This challenge is quite similar to the challenge that banking faced years ago as they took their customer experience online. Personally, I have accounts with Bank of America, Fidelity, eTrade, American Express and a few others. All of these accounts have separate web “portals” with separate log-ins. That's frustrating. But not really. Because I spend very little time on any of them. Most of my time is spent on, where I’ve integrated all of these accounts into one place. From there, I can view all of my transactions and balances, track expenses and create budgets. It's great. It's has award-winning UI/UX and everything is one place.

Mint has taken the bottom-up approach. They started by building a platform for the consumer. And the consumer allows data from multiple vendors to be integrated into their account.

Healthcare needs a similar bottom-up approach.

We need a portal that allows us to integrate all of the data collected on us from our dentist that runs Dentrix software, our primary care doctor that runs eClinicalWorks, our gastroenterologist that runs Epic, our wife’s OBGYN that runs Cerner and our child’s pediatrician that runs Allscripps. All of that data could be neatly compiled into a really user-friendly website (and app), similar to Mint. If I move to a new area and select a new primary care provider, she could simply tap into my account and view all of my scans, test results, prescriptions, etc.

As we consider all of the controversy around forcing EMR vendors to become more interoperable and share patient data with one another, in some ways, you can argue that this isn’t their role.

Why should Bank of America freely pass data they’ve captured about me to Fidelity (a competitor)? They don’t want to do this because they want me to stay with them, not make it easy to use other vendors. Why is that any different than asking UCLA Medical Center to pass my data to USC Medical Center? It would be nice if they did, but I'm not sure it's the government's role to force them to do something that might not be aligned with their competitive interests.

The bottom-up, consumer led approach circumvents this entire conflict. We need a patient portal that starts with the patient, that allows providers (and their EMR vendors) to plug-in (if they'd like). Not the other way around.

Real World Healthcare vs. Venture Capital

Fred Wilson, the well-known venture capitalist, wrote a blog post last week with some technology predictions for 2015.  He touched briefly on healthcare:

the health care sector will start to feel the pressure of real patient centered healthcare brought on by the trifecta of the smartphone becoming the EMR, patients treating patients (p2p medicine), and real market economies entering health care (people paying for their own healthcare). this is a megatrend that will take decades to fully play out but we will see the start of it in 2015.

All of these predictions are spot on, of course -- the patient will become more and more in control of their care.

But if you talk to the people on the ground you'll find that these things aren't really being talked about or worked on at the provider level.

Case in point, John Halamka, the CIO of Beth Israel Deaconess Medical Center, considered one of the most innovative thought leaders in healthcare technology, wrote a post the other day reviewing some of the key health IT issues on his plate during 2014 with some predictions for 2015. In short, he's focused on implementing software that will facilitate accountable care workflows inspired the Affordable Care Act; meeting government electronic medical record adoption standards (Meaningful Use); and complying with government regulations around the protection and security of personal health information (HIPAA).

These are very different things than the things that guys like Fred Wilson are thinking and talking about. Venture Capitalists are completely focused on the patient. Real world healthcare operators (CIOs) are primarily focused on meeting government requirements.

This disconnect -- or, at least, that degree of separation from the patient -- isn't the fault of CIOs; they have no choice but to focus on the urgent and intense demands coming from the government to ensure that they continue to receive government incentives and avoid penalties.

Venture Capitalists are focused on where healthcare technology and the patient are going (e.g. where the money will be). Given the intense regulation, health system CIOs don't have that luxury.

All of that said, for the most part, I think government intervention into healthcare IT has been a good thing. Healthcare execs are totally focused on efforts to increase quality and reduce cost. Most stakeholders (providers, payers, regulators) have gotten behind value based care payment models -- the winds are all going in that direction. And providers are now fully onboard with electronic medical record adoption (at last check ~80% of providers are using them). None of this could've happened this quickly without government intervention.

But now that the groundwork is laid, it's time for the government to back off a bit and let the market start to drive more of the innovation in healthcare IT. Providers need the room to move their businesses and IT investments away from meeting the requirements of restricting, top-down government initiatives and closer to providing tools that are centered-on and built around the needs and desires of the patient.

The Consumerization Of Procurement

The other day I was talking to a founder of a B2B software startup about how hard it is for big companies to buy things. Even at a super low price point (a couple hundred bucks a month) software purchases still have to go through a litany of approvals. I was telling her how almost exactly two years ago I wrote a post titled, Individual Employee Budgets, where I predicted that employees would have their own discretionary budgets that could be used to buy things that would make them more productive and profitable employees. With the growing trend towards the consumerization of enterprise and the ability for anyone in their basement to build and distribute a great productivity application to millions of employees, individual budgets, I thought, would be a requirement for companies to succeed and retain employees. For smaller purchases, traditional procurement eventually has to get out of the way.

I still believe this will happen, but it's moving much slower than I predicted.

That said, two years after writing that post, when I think about the software I use to get my job done, much of it is 'consumerized'. That is, it's sold directly to me and in order for me to use it my company doesn't have to go through a painful procurement process. Software like Wunderlist, Google Maps, TripIt, Sunrise, Feedly, Evernote and Google Docs, to name a few. There are only a couple of applications that I use that were procured through a traditional procurement process -- and most of those aren't as useful or as easy to use as those that I procured myself. Self-service software has to be really, really good as the switching costs are near zero.

It's disappointing that the way companies buy hasn't become more flexible as enterprise software has become more consumerized and easy to procure. Employees are ready for self-service productivity tools and software makers are ready to build and distribute them. The only thing we're waiting for is for big buyers to let it happen.

Enterprise Software For Patients

Most readers know that an EMR (electronic medical record) is the back-end software that runs a healthcare organization (think ERP for healthcare). EMRs have been around for a while. Recently most large hospitals and health systems have begun building out the patient-facing version of their EMR; allowing patients to communicate electronically with their doctors, refill prescriptions, schedule appointments, view clinical information, etc. I've written at length about the differences between B2B software and B2C software and how B2B software is generally not very good (particularly from a usability perspective). And it's not very good simply because it can get away with not being very good. B2B companies really just need a good salesperson that can lock-in long-term contracts to be successful.

B2C companies, on the other hand, need an incredible product to be successful. If your user experience isn't flawless, you cannot survive in the B2C space. The switching costs for consumers are near zero -- the user experience must be incredible. Product is much more important than distribution.

Applying this to healthcare, if you're a hospital and your EMR is hard to use, your employees will still use it because they have to.

But if your patient portal is bad you will lose patients instantly. It's too easy for patients to switch to something else.

The Healthcare Information and Management Systems Society (HIMSS) published a good report last month talking about patient portals.  They noted that despite the difficulty of building a wonderful online consumer experience and the totally different skill set required to execute on it, 80% of hospitals surveyed chose their patient portal vendor simply because it was the same vendor that provides their EMR (the top three portals are made by Epic, Cerner and McKesson). All of these vendors have been building B2B enterprise software systems for more than 30 years. They're all wonderful companies. But they have no idea how to build a patient facing product. Their management, engineering talent, sales force, culture and DNA is all about B2B. They have almost no chance of building a world class consumer product. That's not a knock on these companies, it's just reality. You can't be really good at both.

As we transition to a world where the patient is in the drivers seat, exposing patients to old fashioned enterprise software code is a terrible idea. Hospitals shouldn't let a piece of software touch their customers unless it's been vetted and tested fully and it's clear that patients love it. If you check out the satisfaction scores for most patient portal apps you'll find that most patients despise them (one of them had 2,000 reviews in the iOS app store and more than 1,500 of them were only 1 star).

Patients are becoming consumers. They want slick, easy, mobile, beautiful, simple and seamless web experiences. If the software that touches patients doesn't give them that they're going to go somewhere that does.

Now, in defense of these hospitals let it be known that there aren't a lot of great consumer-focused software companies building out patient portals. So in the short term they might have no choice. But I'd encourage CIOs that are making patient portal investments to consider the consumer, and to cautiously enter into flexible and short term contracts with these patient portal vendors.

You wouldn't buy groceries from the company that washes your car and you shouldn't buy a patient portal from the company that built your EMR.

On The Web, Bad Reviews Are Good

The Wall Street Journal had an article a while back on online doctor reviews. It noted that 25% of patients are now viewing doctor reviews before booking an appointment.  For the segment of patients that either don't have a doctor or are unloyal to their doctor (about 60% of patients) this ratio is far higher and growing fast. Like most products and services, patients want to see what the community has to say before "buying".

This has fairly significant consequences for providers. In some ways this trend is commoditizing the big hospital brands. It used to be that you’d want to go to a doctor that was affiliated with one of the prominent hospitals in your community. In some ways this is still true; but today, if a doctor has good online reviews from other patients, the patient doesn’t really care as much which health system the doctor is affiliated with. The doctor can gain trust from patients without the big brand. The community replaces the brand. The larger implication of this is that in the future health systems will have to focus more on their product (cost and quality) and less on their brand. But that's an issue for another day.

The article notes that many providers are uncomfortable with patients posting reviews about them for the world to see. This hesitation is completely understandable. But smart providers will embrace reviews rather than avoid them.

Case in point: just look at Amazon. There are 536 one star reviews of the new Kindle Fire on Why would Jeff Bezos ever allow negative reviews to be posted about his product on his own website?

The answer is simple: it’s all about  trust. Bezos knows that the bad reviews increase trust and actually end up helping him sell more Kindles.

When eBay started many years ago, most of their transactions were small purchases like Pez dispensers and other low-cost items because buyers were worried about giving their credit card to a stranger over the internet.

Fast forward to today and eBay sells all sorts of very high ticket items on their site -- they sell tens of thousands of cars over their mobile app. That's right, people buy cars on their phone.

In order to buy a car on your smartphone you have to really trust the seller. That trust comes from reviews. It never would've happened without the trust that was built through seller reviews.

Providers need to embrace this as well. And some already are: Cleveland Clinic, the University of Utah and other big hospitals are now allowing patients to post negative reviews of their doctors on their websites. Like Bezos and eBay sellers, these providers understand that the trust gained from being transparent about a provider outweighs any negative perception that might come from bad reviews.

From hotels to taxis to healthcare, we're seeing that the community is trumping the brand. Reviews from the community create transparency, and transparency creates trust, and trust creates growth.