Hurry Up and Wait

We're a little over three months into working on our startup studio, Assembler Labs. (Detroit's startup studio -- spread the word!) I've been in Detroit for one month and since then, we've been cranking on ideas. As we get our hands dirty, I'm noticing a fun tension we're going to have to get really good at controlling: how to balance the urgency to kill ideas with the need to be patient for results.

One of our theses is that, as a startup studio, we increase the likelihood of our success by shutting down dud ideas as quickly as possible so we can move onto great ideas. This way we're more efficient with our limited time and resources and reduce our opportunity costs.

"You better get really good at sussing out whether an idea can be great or not ASAP," you might think. And you'd almost be right.

An entrepreneur and investor we recently met in Chicago reiterated what Ian and I often discuss: you need to build a business around the problem -- not a solution. This is probably a blog post itself, but when I think of a problem, I think of its components: the customer, the problem, and the customer's willingness to pay for a solution to that problem. 

These components -- and the dynamics between them -- make up your market. Talking to potential customers about a problem we're currently working on reinforced this for me: the willingness to pay is a function of your product, not the other way around. Your goal is to build a product that maximizes that willingness and the amount paid. As such, your product will naturally change, a lot. 

So, ultimately, we need to be exceptional at selecting and prioritizing fantastic markets with valuable problems.

This insight is so key.

👉 The market you choose is often more important than the product you build.https://t.co/N8P2j4l0JS pic.twitter.com/6yT4UBfMr7

— Justin Jackson (@mijustin) August 26, 2018

Focusing on problems can feel bad, though. The trouble (or, at least it can feel like trouble) is that sometimes you need to dig around in a problem for a while before you land on a viable (read: valuable) product/solution. This can feel really bad. It can feel like you're not making any progress and you're going down a rabbit hole. It can make you impatient if you let it.

Sadly, impatience can lead you to prematurely abandon an exceptional market before you gave it the time it needs. Markets -- and of course problems -- vary widely in complexity, but it can be easy to forget.

We need to pay attention to that bad feeling, but curb it. We need to urgently test our hypotheses, but be okay soaking in a problem we think is worthwhile. We're not going to hit the ideal solution on the first shot (but if you have, let's talk). 

As a startup studio and inherently working at the earliest stage possible, we realize that ideas and products will mutate over time as they're bombarded by customer feedback, competitive emergence and disappearance, and behavioral trends. That's fine. But we need to only pick great markets, then repeatedly hurry up and wait.

How lightness leads to resilient product teams

Sixteenth-century English and Spanish colonialism in the Americas has a lot more to teach us about creating high-functioning product teams than it would otherwise seem.

Just as some product teams succeed and others, well, don’t, one colonization approach led to arguably the most powerful and successful nation in human history, while another approach led to 300 - 400 years of volatile revolutions, fractious -- sometimes failed -- states, and political instability.

Why the difference?

Geography aside, John Lewis Gaddis, borrowing from Milan Kundera, writes in On Grand Strategy that he thinks it comes down to lightness. I think the same concept applies to product teams. [1]

Lightness of being

What does “being light” even mean? Gaddis defines it as “the ability, if not to find the good in bad things, then at least to remain afloat among them.” Using Machiavelli, he summarizes it as “learning not to ‘sweat it.’” It’s navigating with prevailing winds instead of trying to fight a headwind.

Queen Elizabeth I

For Elizabeth I in the late 1500s, it was slow-playing decision making and knowing her capabilities. Instead of speeding to catch up with the Spanish and their decades-long head start, she let private corporations establish colonies -- with her permission, of course. She protected state money, ships, and men, let entrepreneurs shoulder the risk, and let them sweat the details as they saw fit according to the conditions they themselves experienced.

This “absence of control,” this “lightness,” allowed those actually running these colonies to evolve their own forms of government bottoms-up, as long as they stayed within their royally-dictated charters. The thirteen colonies had “to respond frequently -- but not too frequently -- to the unforeseen.” Those self-created governments eventually led to the self-sufficiency, maturity, and independence that sparked the American Revolution and the founding of the United States.

From a product leadership perspective, I think there are a few things you can do to help your teams be light:

1. Work with the team to clearly establish their constraints up front. This should be a reflection of the company vision, the product strategy, and the relevant business goals. It should help the product team know what is aligned and what is not aligned. Like the colonies’ royal charters, it should establish expectations between leadership and the teams. 

For example, if I’m a marketing company, my vision could be that we will measure everything for marketers to help them know how effective they are. The product strategy, thus, is to pragmatically and progressively measure critical channels. This quarter’s goal could be to increase measurement adoption of a certain channel that was launched the previous quarter. It’s up to the product team to decide how best to do so.

2. Set expectations on how to communicate progress. Leadership will want to -- and should -- have opportunities to check in with product teams. I personally think these check-ins should be more advisory than not, but orgs will differ. The goal of this is to ensure that whomever needs to know what’s going on does know and different functional teams are kept up-to-speed. This is more a case of don’t do what the British did by having unhealthy cross-oceanic relations and instead have healthy communication.

3. Protect autonomy as much as possible. Product teams will do, hear, measure, and see things that leadership simply won’t. They’re not only on the front lines, but are tasked with hitting business goals by whatever means. So, trust them to get the job done and let them do it. By giving them autonomy to make their own decisions and, thus, mistakes, you foster resiliency, which helps them navigate the unexpected.

The problem of not being light

By the time the English even got around to getting serious about their North American colonies, Spain controlled almost all of South and Central America.

They had ships constantly headed home, straining under the load of goods meant for Spanish coffers and marketplaces. The colonies had “great cities, serviceable roads, and standard practices.” Uniformity was so enforced by the more micromanaging Spanish that a “Mexico City gentleman visiting Lima, 2,600 miles to the south, would have felt entirely at home.”

This sounds like success. It might even look like success. But it didn’t work because it led to “shallow roots” -- it didn’t promote self-sufficiency and didn’t breed persistent success. Spain’s Philip II and his governing machine had to will this kind of consistency into existence, despite each colony’s different geography, culture, economics, and situation. They never learned to not “sweat it.”

When this sheer force of will disappears, what continues the job? In Spain’s case, the answer was nothing. As Spain weakened, its colonies lacked the political maturity to self-organize like the American colonies had. Even Símon Bolívar -- the South American George Washington -- argued that because the Spanish had so tightly controlled the colonies, they were left in a state of “permanent infancy.”

Building product teams is difficult -- really difficult. It requires mutual trust and high standards, without a doubt. I think it can be tempting as a product leader to want to dictate or get in the weeds, but before you do, ask yourself: what type of colony and, eventually, country do you want to build?  

----------------------------

[1] Geography was definitely a big contributing factor. If you want a deeper lesson on this, I highly recommend reading Tim Marshall’s Prisoners of Geography.

Validating ideas, part 1: does anyone want it?

You have an idea. You’ve been tossing it around in your mind for the past few weeks. Your brain wanders back to it while you’re showering and it hijacks your train of thought while you’re in a meeting at work.

How do you explore whether it’s worthwhile? Whether it’s worth jumping ship to go forth?

If you’ve done some research, you may have stumbled across frameworks that look like these. 

Credit: This presentation

Credit: This blog post

Everyone picks a different shape or arrangement of shapes, but they’re pretty much the same thing.

• Does anyone want it?
• Can it make money?
• Can it be done?

But, this is actually a framework of frameworks of frameworks. 

In this three-part series, we’ll break apart each one in detail, starting with wrestling the question, “does anyone want it?” And, to help keep this conversation focused on application, we’ll work through an idea together. 

Our idea will be: a podcast app. Podcasts are becoming more popular and there are various podcast apps out there, but the listening experience isn’t awesome just yet. Even more, money is flooding into the space with no apparent end in sight. So, we want to dive in, but we have to do some validation first.

Does anyone want it?

Customer desire is the starting place for all this madness because there’s no commercial point in building something that people don’t - or won’t - want. You can absolutely be an innovator and an inventor, but that won’t necessarily make you money. While we’ll get to the economics of the idea in the second post, desire is the first barrier to overcome.

Break apart “does anyone want it?”

Focus on two components of the question: “anyone” and “it.” To move forward confidently, get crystal clear on how to define these.

What is “it”?

“It” is what you will sell customers and what they will be motivated to buy. It’s the position your product or solution will sit in amongst everything else in the market. It’s what your customer will hire to do the job they need done. It’s what you will do versus what you’ll explicitly not do.

I particularly enjoy how Ryan Singer at Basecamp writes about what they want to emphasize vs. de-emphasize in their product.

Credit: Ryan Singer

By defining boundaries and areas of emphasis, you form your product’s outline and its positioning. It not only gives you a position to experiment with and gradually validate or invalidate, but it also gives you a place from which to say “no” to feature requests, internal debates, executive overreach, or reactionary scrambling.

To get a sense of where you should position your product, it’s (obviously) helpful to do some competitive research. We’ll leave that topic for another day, but assuming you’ve done that, plus some customer research (will also leave that topic for another day), you might have some axes upon which to slide your product.

Let’s look at our podcast app example. Based on some customer and competitor research, we could come up with the following axes. These axes can now help us focus and validate.

“Does anyone want it?”: Anyone ≠ anyone

While you could theoretically build and market your product to anyone early on, that’d be foolish because:

• It’s harder to measure product/market fit (if you’re aiming for everyone it’s harder to tell if you’re making progress),
• It’s harder to know who to listen to for feedback (you’re guaranteed to get diverse feedback, anyway, so why make it harder on yourself?),
• It’s harder to market to everyone (the same messaging, positioning, and medium will not resonate with or reach everyone), and
• It’s harder to know what adjacent customer segments to grow into (if your customers aren’t segmented you don’t know what characteristics they share with other, untapped customer segments). 

The gist of how to work through this component is: go as narrow as possible. Or, as this article puts it: “you want to keep going until there is no meaningful distinction to be made.” Attributes to segment a market by can be geographical, behavioral, demographic, socioeconomic, etc. 

As you segment, it’s important to keep track of each slice’s market size so you can keep in mind the magnitude of desirability, which can act as an input to the “can it make money” question.

Let’s work through this for the podcast app. We know we want to target power podcast listeners, so let’s get a better idea of what that really means.

First, since this is a mobile app we’re focused on, let’s be ridiculous and start with all US-based smartphone owners. That comes out to about 204,370,410 people. 1 

Second, we want to focus only on people who listen to podcasts on a regular, say monthly, basis. One source says this is 26% of the total US population as of 2018 (but let’s discount to the US smartphone-owning population, so 53,136,306 people). That’s pretty close to another source of 57,000,000 people, so let’s roll with it.

Third, based on the “it” we’ve whittled down to, we want to get a little more aggressive and focus on people who will really use our product, put it through the wringer, and who we want to build for. They’re the power users -- the daily podcast listeners subscribing to many podcasts. The same source says it’s 17% of the US population, but we’re going to use the same smartphone discount as above, so it comes out to 34,742,969 people.

Fourth, maybe because we want to gain traction as quickly as possible and we may want to launch iOS-first, we want to target customers who are using the default Apple Podcast app. Data from 2017 shows the iOS Podcast app had a 51.1% market share, but we find out Apple released an inferior app update that is seemingly universally despised. Let’s discount that market share by a third, conservatively, to 34%. That comes out to 11,812,609 people. 2

What do we end up with? A target customer segment made up of 11,812,609 people who:

• Live in the US
• Own a smartphone
• Are older than 15 years old
• Listen to podcasts at least weekly, if not daily
• Use the iOS Podcast app
• Don’t use a third-party podcast app (yet :))

We could continue segmenting further by refining demographics like age or ethnicity, or segmenting on other attributes like what other services or podcasts they subscribe to. However, for the purpose of an app for a power podcast listener, the main behavioral trait we’re looking for is the power user attribute. Thus, there are no more meaningful distinctions to be made.

So, does anyone want it?

Once you’ve tailored the question, you’re ready to pose it. For us and our podcast app example, our question is:

Do US-based, iPhone-owning, iOS-Podcast-app-using, daily podcast listeners over 15 years old want a podcast app that prioritizes helping them listen to -- and discuss -- the content they’re already subscribed to, as quickly as possible, with highly relevant ads?

I’ll add yet another topic to the “let’s cover this another day” list, but there are various ways of getting to an answer to this question. 

At this point, though, you’re in a spot where you can ask a concrete question to the right people and begin really assessing -- and measuring -- whether what you’re cooking up is worth serving. 

---

1. According to this, there are 326,625,791 Americans, of which 81.26% are older than 15 years old (to be conservative and not count kids). Then, using this data, 77% of Americans own a smartphone.

2. Note the implicit assumption here that users who remain with the despised iOS Podcast app are at least weekly podcast listeners. We can test this later.