Here's a fun video to test your reflexes: Go watch this video of a few students passing a basketball to each other and count how many passes there are. It's harder than it looks. How many passes did you count?

The researchers in this paper asked: does the same phenomenon occur when we are analyzing a dataset?

So they made up a dataset and asked students to analyze it. The dataset contained made-up data about men and women's body mass index (BMI) and the number of steps they took.

Students were split into two groups. The first group was asked to consider specific questions about the data, such as is there is a statistically significant difference in the average number of steps taken by men and women? They were also asked if there was anything else important they could conclude about the data.

The second group was just given the dataset and asked what they could conclude – without any additional prompts.

There was one catch. When the data was plotted together, it looked like this.

The first group, the "hypothesis-focused" group that was given specific questions to answer, found the gorilla much less frequently than the second group.

One lesson I took from the experiment is to keep an open mind. The paper says it even better, "Not all who wander are lost".

For those interested, the original paper (2020). An interesting response from Andrew Gelman, professor of statistics and political science at Columbia University.

What is go-to-market (GTM) strategy? It's about how you as a company can deliver your value to your customers. Technical readers will most likely balk at this definition, but let me make it more concrete because a bad or mismatched GTM can completely ruin even the greatest products.

1. Pricing. Will your product be free to use? Is it open source? Is there a free trial? What metric will users be charged by, seats, usage, or something else)?
2. Sales. How will users actually purchase your product? Can they sign up and pay by themselves (self-service)? Do they need to talk to a sales rep?
3. Distribution. How will you reach your target customers? Will you use paid channels like Google/Facebook ads?
4. Positioning. How will you differentiate yourself from the competition? How will users (and hopefully buyers) ultimately understand the value you're bringing? Why can't your competition do these things?

DoorDash wasn't the first food delivery service. Postmates had started two years earlier, Eat32 a year earlier, and GrubHub a whole nine years earlier. How could they compete? Instead of going up against incumbents in high-density areas like cities, they attacked the suburban markets. From DoorDash's S-1 statement.

We believe that suburban markets and smaller metropolitan areas have experienced significantly higher growth compared to larger metropolitan markets because these smaller markets have been historically underserved by merchants and platforms that enable on-demand delivery. Accordingly, residents in these markets are more acutely impacted by the lack of alternatives and the inconvenience posed by distance and the need to drive to merchants, and therefore, consumers in these markets derive greater benefit from on-demand delivery. Additionally, suburban markets are attractive as consumers in these markets are more likely to be families who order more items per order. Lighter traffic and easier parking also mean that Dashers can serve these markets more efficiently.

For most infrastructure and DevOps companies, a useful GTM is open source. It's effective because it's meeting your first customers (developers) where they are (on GitHub). Developers increasingly want to try things before they buy them. They want to run software on their own machines (i.e. cloud) before trusting their data with someone else. And often, it's just easier to integrate it yourself first.

You can see that GTM depends on your target customer and the market you're in. B2C and B2B companies will have vastly different GTM strategies (product/GTM fit).

GTM changes over the course of a company's life, or at least it should. Many B2B companies that start with self-service eventually need to transition to a top-down sales model to support larger enterprise buyers with specific requirements (security and complexity, both of which lead to longer integration and sales cycles). They might need additional professional services to realize the full value of your product in their organization. And eventually, when you start to sell multiple products, sales reps will be needed to cross-sell those solutions to existing customers (see Net Dollar Retention).

There's never been a better time to make your project easier to use by developers. Depending on how they integrate into the stack, companies are increasingly marketing themselves as developer-friendly or developer-focused. From an increased focus on developer tools to unbundling traditionally GUI-driven applications like e-commerce and business intelligence to "headless", or API-first approach.

But why now? Three reasons why developer experience is important.

Developer experience as productivity gain. Developers spend most of their time solving problems other than business requirements. Instead, they are fumbling with configuration, debugging, setting up programming environments, and managing generic infrastructure. Better developer experience means that developers can focus more time on what matters.

Developer experience as a moat. In an age of cloud providers that can take off-the-shelf open source software and run it for a profit, developer experience is a key differentiator between SaaS-managed service and cloud-managed service.  It may not be the most defensible moat, but it is something that is difficult for others to replicate at early stages.

Developer experience as reducing friction in go-to-market. Developers are playing more of a role in the decision-making process of software adoption. They find projects (usually on GitHub) and integrate them as proof-of-concepts. They might even purchase a small plan from the provider. Eventually, the provider can use these deployments as product qualified leads to sell an enterprise deployment to the team. Reducing friction in installing and using the software at any of these stages through good developer experience can have a material effect on the bottom line.