Hello friends, and welcome back to the Product Fundamentals podcast, episode 7: The Startup Wave. 

In this season, we are tracking the evolution of how we came to make software in the weird way we do, from the earliest origins of our methods, through to today.

Last episode, we talked about the 2001 Agile Manifesto and the emergence of Lean Software Development, situating them in the context of the 2000 dot-com crash. 

Most working software professionals today likely work in environments and on teams that call themselves Agile. The rituals of the daily standup, the grooming and sprint planning meetings, and retros are central to the rhythm of many of our working lives. In some ways, we could end this story with the triumph of Agile and be done with it.

But beyond the routines, there are still important pieces to understand about why we work the way we do. How did the product strategies that we follow, with MVPs and endless A/B testing and an fanatical focus on growth – become so common? Why and how did the startup become the basic unit of the tech ecosystem?

This episode , we’ll cover the story of the 2010s startup wave that defined software for so many current technology workers. This is a complex story, so we’ll tackle it in a few parts. First, we’ll cover the scars of the dot-com bust and the emerging ideas about how software businesses should do better, then we’ll discuss the new technologies and economic conditions that helped to fuel the startup wave. Let’s get into it.

[The scars of the dot-com bubble]

Last episode, I mentioned the financial scale of the dot-com crash, which dealt a body-blow to the tech economy. I talked about the 78% fall in the stock market and the 88% collapse in venture-funding, but I didn’t mention the human costs.

In the US, more than one million people lost their jobs to the dot-com crash. In just Silicon Valley, the losses totaled perhaps 200,000, or about 7.5% of the population. Indeed, the population of Silicon Valley, which had been growing more than 1% per year beforehand, stayed flat for four years after the crash. The collapse even hit education – the number of undergrads earning computer science degrees fell by a third, from just shy of 60,000 in 2004 to less than 40,000 in 2008.

In this context, it’s little wonder that industry’s introspection went far beyond just waterfall-versus-Agile. A deeper reexamination of how we build software businesses was coming.

[The customer relationship]

So far in our story, all companies, whether using iterative development or chasing the waterfall, presupposed a specific customer. Whether it was the monopsony of the US Defense Department in early computing, or the enterprise customer for bundled hardware/software through the 1980s, companies knew who their customer was. After all, that’s who was providing the thousands of explicit requirements that the developer would work to satisfy.

This shifted slightly in the 1990s, as we saw Extreme Programming in particular try to pull the customer in the room, as an ongoing partner. This DNA worked its way into the Agile Manifesto as well. But the focus was still on the customer providing acceptance testing – as a business, we already knew pretty well what we were building, we just wanted the customer in the room to validate specific choices along the way. Even as time had progressively torn down our confidence in the wise central planner to design good software, the industry maintained some confidence that we at least knew what our customers wanted.

The dot-com crash dramatically challenged this confidence.

Perhaps the most striking example came from Webvan. This grocery-delivery business seemed to have everything going for it. Webvan was founded in 1998 by Louis Borders, who had previously found business success as the founder of Borders Books. The target addressable market was huge; groceries were a 440 billion dollar market in 2000, which was more than 4% of US GDP. It had ample funding: it raised just shy of $400 million in venture capital funding from giants like Benchmark, Softbank, and Goldman Sachs. And it had an ambitious and appealing mission: to deliver groceries to people in every major metropolitan area in America within a 30-minute window of the customer’s choosing.

It began service in June 1999 in the San Francisco Bay Area, and less than a month later, it committed to a $1 billion contract with industrial construction giant Bechtel to build fulfillment centers across America.

By the time the company had served its first customer, it had already raised hundreds of millions of capital, and committed to more than a billion dollars in future expenses.

There was a rationale for this: the belief in the first-mover advantage. By raising a ton of capital and deploying it quickly, Webvan had hoped to claim market share first, and then figure out operations and profitability later.

Webvan IPO’ed in November 1999, just five months after its first orders, and four months before the dot-com peak. It raised another $375 million from the public.

Suffice it to say, Webvan’s plan did not work. Despite having seemingly all the resources in the world, the business fundamentally did not work. The combination of operations and logistics, pricing model, the target customer’s technological adoption and willingness to pay, against an entrenched alternative in the form of grocery stores, did not add up. In its only full year of operations, the business made less than $200 million of revenue on more than $500 million of expenses. The company shut down service in June 2001, just 18 months after going public, and was dissolved shortly thereafter.

Cases like Webvan were a striking cautionary tale for the post-bubble software industry. It took more than money, engineers, and a juicy market opportunity to build a successful business. Identifying and solving for this certain missing thing that could predictably set the successful businesses apart from the Webvans became an urgent task in the early 2000s. 

[Robinson’s MVP]

In 2001, the same year that the Agile founders were having their summit in Utah, a software business consultant in California named Frank Robinson was engaging with this problem. He advocated for the idea that software teams need to think rigorously about the critical set of features a product must have in order to successfully bring it to market. He was reacting to a perceived tendency for teams to build too much, especially in their first version of a product, before they sold it to customers.

Robinson called his solution to this problem the “Minimum Viable Product,” or MVP. Indeed, Robinson’s company even claimed a trademark to that now-ubiquitous term.

Here’s Robinson’s definition of Minimum Viable Product:

“The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.”

For Robinson, the idea of an MVP was actually quite quantitative; as he refined the idea, Robinson increasingly linked it to business finance concepts. The MVP was all about capital efficiency: it was the version of the product that hit the optimum point on the benefit-vs-cost curve. It was relatively low-risk and low-cost compared to feature-complete versions of the product, and it captured a significant amount of the returns theoretically available for the product. Robinson would later invoke the Sharpe ratio, a concept from the financial analysis of securities, in defining MVP. The Sharpe ratio of a stock is a measure of the average return generated by an investment, relative to the volatility in those returns. All else equal, a high Sharpe ratio is good: it means that the returns on an investment are high relative to the riskiness of those returns.

Robinson’s notion of Minimum Viable Product is a local maximum in the “Sharpe Ratio” of a product – it generates the highest return for the lowest relative risk (which is to say, the lowest amount of time and money invested in building the product).

As such, Robinson largely situated his work in the context of an existing company using its resources to create a new product, rather than focusing on entirely new ventures. Robinson’s not a startup guy – he’s advising established companies on how to deploy their capital internally. But there are some Agile undertones – his proposed way of discovering an MVP requires engaging with the customer through discussions, prototype reviews, and “test selling” a product that does not yet exist.

[Blank’s Customer Development]

Similar ideas were seemingly independently developed by product manager and entrepreneur Steve Blank, who in 2005 published the book, “The Four Steps to the Epiphany: Successful Strategies for Products that Win.” Blank doubled-down on customer centricity, and he explicitly focuses on startups.

The Four Steps to the Epiphany lays out a “Customer Development” methodology for building a new business. One absolute law of books describing methodologies that I’ve picked up on through this project is that everyone’s book needs to define itself in opposition to some “traditional approach,” which is of course outdated and outmoded.

Blank’s traditional approach bogeyman is “The Product Development Method,” which he traces back to the consumer packaged goods industry in the 1950s. This is a simple linear model that flows from concept creation, to product design and development, to testing and marketing, to launch and first sale.

Blank says that this model has its place. He writes, 

“... the model is a good fit when launching a new product into an established, well-defined market where the basis of competition is understood, and its customers are known. The irony is that few startups fit these criteria.”

Startups are up against a very different challenge. And this leads to a big important idea that will drive the startup wave of the 2010s: building the product is subordinate to finding the customer, discovering their needs, designing a first-cut solution to customer problems.

As the title of the book gives away, Blank thinks startups need to go through four major phases of development in order to succeed.

First is customer discovery: The entrepreneur – which really is a single person, or a small group of people, not yet a company – begins with a general vision for the product, then decomposes it into a series of testable hypotheses. The entrepreneur then goes out to potential customers to understand their needs, desires, and pain points. The purpose of this is to validate the entrepreneur’s hypotheses, tweaking and refining the vision in light of what is learned from customers. 

Second is customer validation, in which the details of the specific solution are validated with customer input, with the goal being to identify and build the product with what Blank called the “minimum feature set” in the book, but which he would later say was the same idea as the Minimum Viable Product. Only once the customer pain and the minimum feature set is well-understood does software work really begin. 

The measure for the success of this minimum feature set is its enthusiastic embrace by early adopters, whom Blank often calls visionary customers or “earlyvangelists.” These customers should feel the value of the fledgling product so acutely that they will pay money to use a rough half-built partial solution; that’s the MVP. Only once these early adopters have been found and engaged does the business worry about crossing the chasm to mainstream customers and to making sure the business model is repeatable and scalable. Until then, don’t build your mature product. Don’t become attached to a concrete product vision – these things are traps.

All right, now we can breeze through the rest of Blank’s four steps. Third is customer creation. With a fundamentally viable product, the entrepreneur now focuses on building a customer base through sales, marketing, and other customer acquisition strategies.

Finally, fourth is company building, in which the business develops the organizational structures and practices that will allow it to be a scalable and sustainable business. 

So what is Steve Blank doing to how we work?

Throughout the four steps, Blank advocates for taking a “scientific” approach, with a focus on validating hypotheses, turning beliefs into facts. When a hypothesis is invalidated, the entrepreneur should pivot, incorporating the information learned from the invalidation into a new product vision and plan. That thread of the successful business as a learning machine, which we first encountered in Episode 5 with multi-learning from The New New Product Development Game, and again in Episode 6 with Lean software, is alive and well here. 

But more importantly for the question of how we build software, Blank is really clearly putting the customer in the driver seat, so much so that there’s no reason to even have software engineers until after customer development is well under way. But Blank is also skeptical of doing any “company building” activities too soon, either. A company has no need for a distinct marketing department, for example, until after a minimum feature set product has been delivered to early adopter customers. 

Blank’s ideal startup is far from the deeply-funded dot-com bubble giants. Indeed, he specifically calls several of them out, including Webvan. The early stage startup should be small, ruthlessly focused on customer discovery and customer validation above all else. There are no executives, no departments, no frills at all, until customer development has succeeded.

There’s an obvious break from Robinson’s MVP here, which was meant to help existing companies make the right-sized investments in new products. For Steve Blank and those who will follow in the startup wave, the company is an outcome and byproduct of a series of successful experiments in understanding and solving customer problems. The company isn’t the point.

[Product/market fit]

All right, so that missing je ne sais quoi – separating companies that are ready to grow from companies that are not – needs a name. Let’s get it one. 

In 2007, software engineer, executive, and venture capitalist Marc Andreessen wrote a blog post called “The Only Thing That Matters.” To condense a bit, he writes,

“This post is all about the only thing that matters for a new startup… If you ask entrepreneurs or VCs which of team, product, or market is most important, many will say team… On the other hand, if you ask engineers, many will say product… Personally, I’ll take the third position—I’ll assert that market is the most important factor in a startup’s success or failure. Why? In a great market—a market with lots of real potential customers—the market pulls product out of the startup.”

He goes on to tightly echo Steve Blank’s notion that a successful product is not necessarily feature-rich; it’s simply one that customers are knocking down the door to get.

“Conversely, in a terrible market, you can have the best product in the world and an absolutely killer team, and it doesn’t matter—you’re going to fail.

Andreessen credits fellow executive and venture capitalist Andy Rachleff with “crystallizing” this notion, and then posits what Andreessen calls Rachleff’s Law of Startup Success: “The #1 company-killer is lack of market.” 

He then adds a follow-on, which he calls Rachleff’s Corollary of Startup Success: “The only thing that matters is getting to product/market fit.”

He adds,

“Product/market fit means being in a good market with a product that can satisfy that market.”

And here it is, the missing term for what Webvan and other dot-com companies failed to find: “product-market fit.” Andy Rachleff, who apparently coined the term, credits legendary venture capitalist Don Valentine with developing the underlying concept.

Like so many of the big ideas we’ve discussed in this series, the importance of product/market fit seems… kind of trivially obvious, right? Who is going to disagree that understanding and meeting a customer need is critical for a business?

I think the answer is that no one would disagree, but the environment had shifted, meaning that the way organizations worked no longer fit their context. Businesses needed to update their methods to fit their new surroundings.

As we’ve discussed, the software industry emerged from aerospace, military contracting, and bundled enterprise hardware/software packages, and the first great crop of consumer-oriented startup companies had largely met ignominious ends in the dot-com bubble. The software industry didn’t actually have that much experience or that many successful models for serving a distributed consumer customer base. And as we’ll soon see, the technological landscape was about to change in big ways once again as that relentless exponential growth in capabilities continued.

So, an idea like “product/market fit”, can be a novel and pressing problem, despite its obviousness. 

[The Lean Startup]

Before we get to the new technologies that would shape the startup wave, though, there’s one more important text to talk about.

For many of the participants in that wave, the critical text was Eric Reis’s 2011 book, The Lean Startup. Reis was a software engineer and entrepreneur who knew Steve Blank well; Blank was an investor in Reis’ startup, and Reis copy-edited a draft of Blank’s The Four Steps to the Epiphany. 

On a personal note, we’ve finally reached the point of the series that overlaps with my career. I founded a small startup in 2011, and I remember Reis’s book was absolutely everywhere. The Lean Startup was the seminal text for entrepreneurs.

The Lean Startup borrows liberally from Blank’s The Four Steps to the Epiphany, combining Blank’s customer-development methodology with some elements of lean software development, and then addressing a few new topics.

For Reis, businesses start with a vision, which is taken as relatively fixed. Realizing that vision requires a strategy, which must be refined through testing and validation. The product that the company ultimately delivers is the manifestation of that strategy.

To identify the right strategy, Reis doubles-down on the startup as a learning machine, focused on validating hypotheses. The ultimate goal is delivering value to the customer while stripping out all forms of waste. In order to discover what customer value is, and what waste is, we form hypotheses and test them. Reis writes, 

“I’ve come to believe that learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what customers want can be eliminated.” 

To enable and capitalize on this learning, Reis advocates for a mix of strategies, but places special emphasis on the MVP, measurement, and the pivot. 

For Reis, though, MVP doesn’t have a tightly-defined meaning. The MVP…

“Helps the entrepreneur start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort… Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.”

The key is that the MVP gets exposed to the customer. Reis gives examples that range from a “concierge MVP” in which the founders take on unscalable heavy operational work to prove demand before doing any automation, through Zappos’ MVP – in which the founder took photos of shoes at a local shoe store, created an ecommerce site, and sold the shoes full-price before actually buying them from the store –  to Dropbox’s, which was simply a video of the not-yet-existent product working flawlessly, with a sign-up form for the waiting list. In some of these cases, the MVP is not a product at all – it’s simply a tool to get what Blank called customer validation.

The MVP is supported by extensive measurement. The MVP should establish some baseline numbers for the business, such as sign-up rate, etc, retention rate, and so on. By measuring how future changes affect those rates, especially when those changes are conducted through A/B testing, the entrepreneur discovers how to improve the product, and what the proper development strategy should be.

The final piece of Reis’ model is the recurring choice to pivot or persevere. As the entrepreneur learns from experimentation and measurement, he or she faces the decision of whether to continue investing in the existing strategy, or whether to switch to an alternative. Operating in the leanest possible way and validating hypotheses quickly is the method to reduce the cost and risk of pivots, and it preserves capital in order to buy as much time as possible to find product/market fit.

So that’s Reis, and that’s the last of our big thinkers laying process groundwork for the startup wave. Before we discuss the lasting impact of these ideas on how we build software today, though, let’s catch up on the technological and economic changes that powered the startups of the 2010s. 

[Technological Change]

[[APIs]]

The first technology that fueled the startup wave was web API.

Application Programming Interfaces, or APIs, have a long history in computing. Indeed, the idea of a library of common reusable functions that could be accessed by any application on a computer dates back to the earliest days of software – the very first book on practical computer programming, The Preparation of Programs for an Electronic Digital Computer, written in 1951, describes such a system.

An Application Programming Interface simply lets a program (that is, an application) interface with some library of existing reusable code to solve a problem. An operating system might provide APIs that let programs interact with hardware; a programming language might offer a library of common functions as an API.

The API acts as a layer of abstraction – a programmer can call APIs from within their program through a standard interface, without caring about what’s happening under the hood. Over time, as technical capabilities evolve, the underlying logic used in the library might be completely rewritten, but as long as the interface of inputs and outputs remains the same, new programs can keep using the API. The API becomes an abstraction layer that enables compatibility across software and hardware.

When the term “Application program interface” was coined in 1968, it was in precisely the context of ensuring programs could continue to work even as hardware rapidly improved.

Protocols and APIs for computers to interact over networks had existed since at least the early 1970s. But it wasn’t until 1998, with the release of the Simple Object Access Protocol, or SOAP, and more importantly, 2000 with the release of the REST architectural style, that the Internet had standardized APIs.

REST – an acronym for Representational State Transfer – was not a protocol, but a set of design rules for APIs to be used over the Internet’s basic protocol, HTTP. The REST style builds naturally on the object-oriented programming paradigm that we discussed in episode 5 by, well, transferring a representation of the state of a resource. That resource is usually an object like a user or a tweet or an item for sale, and the API allows one computer on the Internet to interact with and manipulate objects on another computer.

Some early public web APIs included those offered by Salesforce and Amazon in 2000 and 2002. Some consumer web apps like bookmarking tool del.icio.us and photo sharing website Flickr followed in 2003 and 2004. But the web API really became central to the software industry when social media sites Twitter and Facebook released their first APIs in the summer of 2006.

These APIs enabled entirely new companies to be built by leveraging capabilities offered by other companies. By 2008, you could, for example, build a website to plan events that could be logged into with a Facebook account, that knew about the weather, that fetched directions from Google Maps, that accepted payments through PayPal, and that sent text messages through Twilio. Instead of building any of those capabilities in house, they were all made readily available through the abstraction layer of public web APIs.

Many of these APIs began as free, and overtime, their owners began to charge money for use. The emergence of this “API economy” dramatically lowered the overhead for a startup company to deliver value. A small independent team could leverage the work of other companies with thousands of engineers, putting it to use towards the startup’s goals with potentially just minutes of coding work.

[[Smartphones]]

The proliferation of web APIs was also an important enabler of the emblematic technology of the 2010s: the smartphone.

While BlackBerry devices had supported third-party applications since 2002, it was the broad adoption of Android phones and the iPhone, and their embrace of third-party app developers, that proved critical to the startup wave. The Android software development kit, or SDK, was made available to app developers in November 2007; Apple quickly followed with the iPhone SDK in March 2008. Both platforms launched their app stores to the public later in 2008. 

The platforms created opportunities for existing software vendors and newcomers alike. 

• Both platforms’ SDKs provided APIs to interact with the device hardware, while abstracting away any need for the developer to understand the nuances of the hardware. 
• Public and private web APIs provided the means for the smartphone to access the data and leverage the capabilities of much more powerful servers. 
• The App Stores provided distribution channels which had never existed before, potentially dropping user acquisition costs significantly, especially in the early days of the platforms. 
• Push notifications and the pocket-sized form factor enabled new interaction patterns that had not been possible on full computers.

Of course, smartphone adoption was incredibly rapid.

In 2009, 20% of American adults had a smartphone. By early 2013, it was more than 50%; in 2015 it was two-thirds. By early 2021, 95% of adults under age 50 in America had a smartphone. Worldwide, there were 6.6 billion mobile smartphone subscriptions in 2022.

Mobile devices were yet another accelerator of the move toward lightweight, fast development approaches. With standardized hardware and API layers to simplify development, a built-in direct-to-consumer distribution channel in the app channel, and a “gold rush” sense that a new market frontier had just been opened, organizations that could ship fast and iterate their software quickly were at a distinct advantage.

[[Cloud infrastructure]]

At the same time that mobile platforms were creating space for new business models, a new category of “cloud infrastructure as a service” was rapidly emerging. Amazon Web Services, the first big mover and the consistent market share leader in this domain, released the Elastic Compute Cloud, or EC2, service in an unlimited public beta in August 2007. 

EC2 removed the need for a software company to own any server hardware, or to form a long-term contract with a data center provider. Instead, anyone could write code on their local computer and push it over the Internet to AWS’s data center. Amazon charged developers for computing capacity in small units, such as hourly blocks of time, with varying levels of hardware available at different prices. Over time, AWS has added many more types of hosting capabilities beyond Compute, essentially removing the need for a software business to own, or even think about, any infrastructure hardware.

While Amazon was the first big public mover in such flexible cloud infrastructure, there were several fast followers. Google launched its competing Google App Engine in early 2008; Microsoft’s Azure cloud computing platform followed in early 2010. Digital Ocean and IBM would follow with their own offerings later in the decade. Within less than 5 years of the first public beta of AWS, an entire ecosystem of cloud infrastructure providers had bloomed.  

The emergence of cloud infrastructure as a service took the up-front capital expenditure of a software business for hardware or hosting and drove it nearly to zero. Moreover, a startup could reach significant scale without necessarily having anyone on staff who understood hardware; for many applications, infrastructure had gone from being an important specialization to being a minor part of a full-stack engineer’s job. As a result, spending on hosting became a purely variable cost. A software business needs to only pay for its real usage, which makes becoming a globally-scaled business much easier for a cash-strapped startup.

[Interest rates]

At the same time that cloud infrastructure was cutting upfront costs for startups, their access to money was expanding rapidly.

The economic fuel for the startup explosion came from the low-interests of the post-Great Financial Crisis period. In the US, the Federal Reserve Bank’s federal funds rate for lending to banks remained below 0.25% from December 2008 through December 2015. This was its lowest level since a brief moment in the 1950s, and its only sustained period near zero. These low rates drive startup formation in a number of ways.

The first is by expanding the supply of money available to invest in risky assets like startup equity. With interest rates on safe assets very low, investors that need to earn a steady return on their investments, such as pension funds, are pushed to invest in riskier assets than a conventional stock-and-bond portfolio. Wealthy individuals follow suit. This leads to a ballooning in the size of venture capital funds; more capital means more startups.

Moreover, startup valuations are also driven higher by low rates, making the idea of founding a startup more attractive to entrepreneurs. Stocks are conventionally valued based on the present value of their discounted future cash flows. Low interest rates mean a low discount rate is applied to that calculation. As a result, the stock of a company whose cash flows are mostly in the future, even the distant future, is much more valuable in a world with low interest rates than higher interest rates. 

Startups are the most sensitive to this difference, because their cash flows are likely the farthest into the future. Even a small change in interest rates can have a huge impact on the present value of those future cashflows.

Low interest rates mean the future is relatively more important to a company’s finances than its present; high interest rates mean the present dominates. In the era of near-zero interest rates, the future was almost all that mattered. 

In the software industry, the protracted period of near-zero rates left us with some enduring artifacts: 

First, the mentality that “all that matters is scale” is a natural consequence of low-interest rates. Burning money now to reach more customers, with the intention of capturing revenue from those customers at some point in the future, is a rational and indeed totally appropriate strategy in a world of zero interest rates. Spending $50 on customer acquisition costs for a user who many only generate $55 in revenue 5 years from now is rational if your discount rate is just 1 or 2 percent. If instead your discount rate is 6%, that’s a terrible investment. This mental model, that attracting users and building stickiness is more important than revenue, became nearly ubiquitous during the startup wave.

Second, the low-interest rate environment gave us “the unicorn.” The term was coined by seed-stage venture capitalist Aileen Lee in her 2013 article, “Welcome To The Unicorn Club: Learning From Billion-Dollar Startups.” At the time, there were just 39 private companies with valuations greater than $1 billion dollars. Due their rarity – estimated by Lee at just 0.07% of all seed-funded companies in the preceding decade – Lee chose to call these companies unicorns. The persistent low interest rate environment, though, quickly removed the rarity implied by the mythological name: as of April 2023, there are now 863 private companies with valuations greater than $1 billion in North America, with another 416 in other regions. 

Finally, the high valuations that low interest rates help create in turn makes equity-based compensation more attractive to tech companies. When valuations are high, the percentage of a company’s stock given to an employee in compensation for a given dollar amount – and therefore the amount of dilution that investors and owners suffer – is much lower. That is to say, giving a worker $100,000 in stock is a lot less painful for a startup whose equity value is high due to future expected cash flows than that same $100,000 is for a retailer whose expected cashflows are in the near-term. 

So, low-interest rates help to spur the RSU and stock option trends in compensation for software workers, which helped draw more workers into the industry.

With startup-specific business models defined, new enabling technologies in place, venture funding increasingly widespread, and the opportunity for fantastic wealth increasingly obvious, all the seeds had been planted for the startup wave. 

[Startup takeoff]

While it’s hard to find solid statistics on software startups in particular, it is clear that there was a huge acceleration in startup formation in the first two decades of the 21st century. The Department of State for Delaware, where venture-backed companies are incorporated, records a roughly baseline of 32,000 to 35,000 new corporations being formed per year from 2003 to 2007. After falling by nearly 20% during the 2008 to 2010 financial crisis window, startups returned with a vengeance: for the period from 2010 to 2021, the most recent year for which data is available, the number of new corporations grew continuously, more than doubling, from 28,000 to 62,000 firms per year. That’s a sustained 7.5% compounding annual growth rate in new C-corporations – it’s safe to assume much of that growth was software startups.

Venture capital data, though spottier, tells a similar story. According to the American tradegroup, the National Venture Capital Association, the number of companies receiving venture capital investment in the United States nearly quintupled between 2010 and 2022, from 3294 companies in 2010 to 15,379 companies 2022. That’s a compounding annual growth rate of about 14% in the number of firms receiving investment. Of course, the quantity of money is also up dramatically, from about $22 billion in 2010 to $241 billion in 2022, nearly 11x growth, just in the United States. 

In that time, the share of venture capital dedicated to software has doubled from 18% of the total to 36% of the total.

In short, the 2010s were indisputably the decade of the software startup.

[So what?]

So, there were a lot of startups in the 2010s. Why does this matter?

First, consider how it contrasts with so much of the history of software that we’ve discussed. Our profession began primarily as large, established, repeat-player vendors building bespoke mainframe-scale systems for giant customers, often the military.

But by the end of 2010s, the intellectual, cultural, and economic heart of the software industry was in the companies that are, or were, single-product companies fueled by venture capital, with a real or imagined history as scrappy disruptors serving individual consumers or small businesses with software that was subject to constant revision.

The idea of the “MVP” has become a meme in software, and like the label “Agile,” it has been an empty enough vessel that all sorts of meanings have been ascribed to it. Clearly, there are antecedents of the MVP in earlier methods, all the way back to Winston Royce’s throwaway prototype in 1970, but robust versions of the customer-tested software MVP also weren’t really possible until at least the early 2000s. You needed the ability to cheaply build and quickly launch some sort of product experience to large numbers of customers, measure and quantify the aggregated interactions of users with the product, and rapidly iterate on the product strategy based on that input. The pieces to enable that process weren’t in place until very recently.

Moreover, the rise of the startup brought the tight coupling of the product and the company to its peak. The idea that the customer must be discovered first, and then the product is defined, and only then does a company come into being around it, is a distinctly recent idea.

Many of the ideas and practices of the startup wave have made it into the working methodology of large established companies, either through cross-pollination, or simply because some of the startups got big. Now, even within established companies, new products are expected to begin with some sort of "MVP” phase (whatever that may mean). In many organizations today, it’s hard to imagine a team starting a project without ample customer validation before the first line of code is written.

Of course, the customer always mattered, but in the 2010s, the industry completed the long-running transition from the early era of enterprise customers providing exhaustive and legally-enforceable requirements, through a brief hubristic phase of “if you build it, they will come” in the dot-com bubble, into a model of proactive search and discovery for customer needs. Those patterns are a central part of how most of us work – or at least, aspire to work – today.

With the software development team now expected to do so much more than just write code, the definition of the team changed. I believe The Lean Startup is the first of all the texts on building software that I’ve referred to in this series to directly acknowledge product managers. 

I’m kicking around the idea of doing a history of various job titles in the future, so I won’t spoil the story now, but suffice it to say, there have been people with the title “product manager” in the software industry since at least the mid-1970s. But in all this talk of methodology, they were never relevant. Scrum had “Product Owners,” but they weren’t necessarily much like modern PMs. Software development was the domain of programmers, architects, and project managers. Product managers were conceived of as off doing business stuff far away. Finally, in the early 2000s, product managers became a direct player in the software development process. By the time Reis writes in 2011, he’s basically taking them for granted.

I think it’s fair to say that the first decade of the 2000s, as the industry digested what went wrong in the bubble and geared up for the startup wave, is when the modern product manager came into being.

Finally, the new technologies that fueled the startup wave deeply changed how we build software. Cloud infrastructure made smaller businesses with less initial capital viable. Smartphones created new opportunities, but also added two more device platforms to build for, creating new developer specializations that nearly every business needed to hire. More specializations strengthened the case for the return of the cross-functional team. The app gave new life to installed software, but most apps relied on a server for content and processing, making the web API ubiquitous and essential. For many teams, by the mid 2010s, the API had become the product.

[Wrapping up]

With a newfound focus on understanding every nuance of the customer, new technologies enabling vast data collection, and the massive scale of user bases in a mobile-first world, the mid 2010s saw one more shift in the way we build software: the widespread embrace of in-product experimentation.

So next time, we’ll trace the threads of how our work became such a quantified, analytical, scientific endeavor. Join me next episode for the history of beta releases, A/B tests, and the rigorous quantification of OKRs.

That’s all for this week.

As always, your comments and feedback on this episode are very welcome. You can find a transcript, links to sources, and ways to reach me on the show website at prodfund.com. 

And if you like this series, and you want to hear more, do me a favor and share it with someone you think would enjoy it too.

Thank you very much for listening.

[Miscellaneous sources]

• https://www.infoq.com/presentations/history-api/ | Great talk on the history of the API