Owning the full stack unlocks opportunities

When you’re building a company or a product, how do you decide whether to own the entire stack or whether to outsource parts of the product? Owning the entire stack could allow you to create a better user experience (vis-a-vis WeChat and how you can text message, order a taxi, or make a doctor’s appointment all in one app), but sometimes this power is wielded in ways that stifle innovation.

To close the loop entirely, AT&T set about designing its own radio sets. AT&T’s new radios were engineered to receive only AT&T broadcast frequencies — and, not surprisingly, only AT&T programming. (via the Master Switch: The Rise and Fall of Information Empires)

When does vertical integration enable you to succeed in an industry and when does it not?

I used to think it was better to outsource things you are not good at, and instead focus on your key strengths — then why is Tesla trying to bring manufacturing in house when they could move much faster following Apple’s footsteps and outsourcing their manufacturing to China? After all, the Chinese manufacturers have decades more experience producing electronics and cars and could much more easy troubleshoot problems than we could.

Bringing things in house is what has enabled Tesla to get so far and be the leading electric vehicle company in the world — having no credible competition in the electric car market for 5+ years. Cutting out the middle man enables three things:

  1. Reduces client implementation complexity -> we can build more things!
  2. Lowers costs – we’re not paying someone who is incentivized to charge more
  3. To innovate – we can quickly iterate in-house
I’ve been reading the Master Switch: The Rise and Fall of Information Empires, and it’s fascinating to learn about companies who started with one core competency, and expanded moved things in house to gain a competitive edge. Radio Corporation of America (RCA) for example, originally started as a radio broadcasting company, but decided to start producing and selling radio sets so that they could control the frequencies that the radios could receive.
Are there industries then, that lend themselves more to vertical integration than those that don’t?
The answer is usually mixed. In the computer industry, for example, Microsoft is not vertically integrated but won most of the market share — Apple, on the other hand, is vertically integrated and won the lion’s share of not the market, but the profits.

Similarly, in the mobile phone industry, Google Android is not vertically integrated and has won the market (87%  market share), while the Apple iPhone (12% market share) [1] has contributed to making Apple the most profitable company in the world [2].


Working inside the system to kick butt

I meet many people who bash Snapchat or Facebook as products. They think of the products as a waste of time. That’s one way to approach making products. Another way is to do the opposite. Put Snapchat on a pedestal. Ask “What makes Snapchat addictive? How did they get to over a 100 million users? Can we take their strategies and leverage them to achieve our product x’s goals?”

You can adopt this strategy with your career choices too. Gary Gensler worked for Goldman Sachs and became a top manager (this is a career decision some would ordinarily pooh-pooh as selling out), but then he left and worked for the CFTC (Commodity Futures Trading Commission) to help fix the broken and corrupt derivatives market — and he was the only person fit for the job, because no one else in the government understood how derivatives worked. He eventually helped bring transparency to the $400 trillion previously opaque swaps market, transforming the sleepy CFTC into a powerful regulatory force.*

Gary Gensler defends record as he leaves CFTC

Did design make the iPhone successful?

While good design helped Apple’s iPhone gain traction — it was not the driving factor of success, as many people assert. The driving factor was Apple’s  innovation in touch screen technology. Nothing like it had come before — before the iPhone, you could only view sparse, text-only versions of sites like the New York Times.

Examining the evolution of technology allows us to recognize that technologies we see as normal today, such as the internet, were once simply imaginations in someone’s head.

Industry had attempted to create a responsive touch screen for years. The first was a resistive design, a soft touchscreen that flexed under touch to tell the device which part of the screen was being pressed. This flexible screen wasn’t very accurate because the device couldn’t precisely tell where the screen was being pressed. HP took the touchscreen a step further by using lasers. Touching the screen broke the lasers and allowed the device to move the cursor to where the screen was being pressed. This worked but didn’t allow for multitouch. In 2007, Apple released a capacitive touchscreen — the most innovative touchscreen technology ever seen.

While novel touchscreen innovation was the main factor for the iPhone’s success, design had a helping role. When a product is well designed, people are more likely to use it. Think about how flipping through news on Flipboard makes it addictive.

You can also think beyond a UI level about the product’s design more broadly — for example, compare Instagram to Facebook. People can post, like, and comment pictures on Facebook just as they can with Instagram. Many still prefer Instagram over Facebook, despite the features on Instagram simply being a subset of Facebook’s. The reason is Instagram is a product highly focused on one thing — seeing a snapshot of your friend’s life. On Instagram, there are less possible navigation states in which someone could get lost. The minimal interface makes it easy to figure out what to do next. It is this kind of design that plays a much larger role in paradigm shift. Consider the graph for example. Before graphs were designed, we were interacting with numbers either individually or in a list format. The invention of the graph enabled us to see the relationship between different variables in a way that we could not have before.*

* via Bret Victor’s Future of Programming

Getting more from conversations with advisors

I always think about how to get more from conversations. I often felt like sometimes we would have conversations with top-notch experts in our field had heads filled with specialized information about how drugs are developed at pharma companies, or how billing works in healthcare, but I would never be quite satisfied at the end of our conversation.

I started to try adding structure to my meetings, where I would create a slide presentation for each interview. Each slide contained a hypothesis I had about the industry, the status about the hypothesis, and the next step. I instantly found the conversations I had to be much more stimulating.

When Kurt and I were first building Neurocurious, a machine learning product for pharmaceutical companies, one of the assumptions we had was that pharmaceutical scientists struggled with knowing whether a potential drug was toxic or not. Before structuring our interviews, we would bounce around the question, naively assuming, of course this is a problem scientists struggle with. We then started making slides that had tables like this:


And we slowly started filling them out. We learned that an assumption we had thought true to be true for many months — that scientists would use our software to learn the toxic side effects of their drugs — was in fact not a problem. When we interviewed an ex-Pfizer director who headed their toxicology team, we learned that pharmaceutical companies, for the most part, have tox figured out. He told us, “Toxicology was a problem 20 years ago, but not anymore.”

While large companies didn’t care very much about tox, we kept interviewing all sorts of people in pharma and learned that smaller startup therapeutics companies do care about their tox, because the large pharma companies that might acquire them want to de-risk the potential drug as much as possible.

We revised our slides:


Over the course of interviewing over 100 executives, business developers, and scientists in the pharmaceutical industry, and iterating on our hypotheses, we now have a set of refined hypotheses about the problems that pharmaceutical scientists struggle with. These set of problems can be used to design a product whose value proposition aligns much more closely with the problems of the pharmaceutical industry, than the value proposition we had originally began with.

Validate before building

A difficult concept to internalize for those first starting a startup is validation. Founders might talk to people about the idea, try and evaluate the feasibility of the idea, and get caught up in implementation details, making market need an after thought.

With my first company that focused on automating drug development for pharmaceutical companies, K and I spent many of our days reading research papers about Alzheimer’s and the nuances of beta amyloid plaques. We were learning a lot – but not exactly about our product-market fit.

After the first company, we decided to prototype a genetics product. We instead started with market need and put up a landing page for the product, set up a ‘Pre-order now’ button, ran an ad campaign, and asked people for feedback. While we had one customer pre-order our $500 product in the first few weeks, we also learned about the idiosyncrasies and doubts of our target consumers much more quickly than the first time around.

That said, whether a product can be adequately user-tested or not depends. Enterprise products that are only used by one person are easy to user test. Consumer products, on the other hand, tend to be more difficult, especially if they have a social component and require network effects for the user to realize value.

A formula for deciding what to build

I’ve noticed making high-level decisions at a mid-stage company is trying. Prioritizing at a startup is easier, because you have less groups clamoring for your attention. But when marketing asks for more money for ad campaigns and the engineering team complains about how they’re overworked and need another developer — how do you know which ones to select and execute on?

One way is to draft a list of all these priorities and ask everyone to vote. This approach democratizes decision-making, which, if done too much, can lead to a company without a clear product drive.

Another way is to ask two questions. Everything boils down to numbers.

Question 1: What are the inputs?
For example, if you want a marketing campaign, do you need more money for Google ads (external) ? Do you need to a month of engineering time (internal)? Often people think about external costs, but forget about the cost of internal company resources, which are just as valuable.

Question 2: What are the outputs?
All businesses have 3 goals. So these inputs must be manipulated in some way to generate output into one or more of these company goals:

  • (1) Revenue
  • (2) Cost savings
  • (3) Market growth

Thus, the decision about what to build becomes simple. You make the decision based on the input/output ratio.