Clearbit and design as a strategic power

I’ve been a big fan of Clearbit since I used their API a couple years ago for a project at my previous company. It was so easy to use, documentation was super clear, errors were useful for debugging, and it gave me exactly what I needed. I’ve also always been impressed by the clean design of their website, brand, and messaging — it’s just…straightforward.

So, I was happy to read their CEO’s blog post about their recent $15M raise (emphasis mine):

When we raised our seed round in 2015, we told ourselves that was the only funding we’d ever need. We focused on staying lean and raced to profitability within our first nine months. For the past three years, Clearbit has been profitable. We are in this for the long term, which chiefly requires building a sustainable business.

Our rapidly growing team of 60 people work tirelessly to support the best B2B companies in the world. Companies like Segment, Asana, and AdRoll have built their entire sales and marketing stack on top of the Clearbit data layer.

To that end, we’re happy to announce that Clearbit has raised an additional $15M in funding at a $250M valuation.

Second, we’re stepping up our game for our existing 1500+ customers

Daaamn, check out those terms. They raised $15M at a $250M valuation (let’s assume pre-money). That gives investors only 5.4% of the company. How did they get those terms?

  1. They obviously didn’t need to raise the money. They’re profitable and have been for 3 years. Understood.

  2. They must be growing at a fair clip.

  3. They’re attacking a large market (b2b sales/marketing tech).

  4. They must be very capital efficient.

But what makes their business defensible? Ian and I got into a debate over this. (I’m going to borrow from 7 Powers (I often take book recommendations from Keith Rabois’s Twitter feed)). We both agreed their dataset is defensible. It’s a (sort of) cornered resource. They scour the internet for data that’s probably not very structured, and piece it together to form an identity, be it person or company. While not impossible, it would be very difficult for another company to acquire that resource.

Then I proposed that design is one of their strategic powers and the debate began. Their API, documentation, marketing — it’s all fairly clear, concise, and good looking. It makes their product a pleasure to use and probably better than competitors’ products (I honestly wouldn’t know as I haven’t used anything other than Clearbit for the same purposes).

If a company highly values design, and orients something like product development around specific design processes/principles, and all that results in a superior product, that’s a process power. And very defensible.

Clearbit seems to value design and there’s probably an organizational ethos, as well as function-specific processes, that results in these awesome APIs and clean marketing assets at capital efficient rates (ahem, 3 profitable years).

Other recent examples support this. Stripe — awesome, simple APIs to help developers build payments into products. Plaid — awesome, clear APIs (with fantastic documentation) to help developers tap into personal finance data. Twilio — awesome, easy-to-use APIs to help developers build calling and texting into products. These companies focused on developer friendliness through the lens of thoughtful, purposeful, clean, and simple design, whether data object design, API design, documentation design, or marketing design.

It isn’t a new concept that design is a competitive edge (hi, Apple), but it’s reinforcing to me that design can serve as a potentially equally strong strategic defense as some of the other well-known powers, like brand or economies of scale.

As a former Clearbit customer, I’m stoked for them and so impressed from a strategic and operational perspective. And I’m so happy that software products across the gamut are emphasizing design more and more and it’s becoming more strategically, and thus financially, justifiable. Now if my health insurance company would just take note….

Invisible products, momentum, and other thoughts on Creative Selection

I finished Creative Selection a couple weeks ago on a flight. When I started it, I was coming off the highs of finishing Who Is Michael Ovitz and Not for the Faint of Heart -- both incredibly personal, profound, and captivating accounts of high-trajectory careers in entertainment and diplomacy.

Those are the types of books you finish quietly, hoping to remember everything you just experienced, but knowing you probably won’t. I’m so grateful for books like that. They deepen my hunger for more tell-alls of gripping negotiations, creative deals, business building, masterful accomplishments, and tragic failures.

Parts of the internet spoke highly of Ken Kocienda’s book, and I figured it was in the same neighborhood, although perhaps on a different street, as the other books. So I jumped in. These are some things that stuck with me.

The best products work so well they just fade into the background

The book started out slow for me. Steve Jobs cameos aside, I dreaded a couple hundred pages about...keyboards. (Others felt similarly, too.) Especially something as ordinary as an iPad and iPhone keyboard. Right? Those are givens. They’ve always been there and, plus, aren’t they just obvious and derivative of the regular keyboard? It’s QWERTY, our old friend.

But I kept going, picked my head up a couple hours later, and realized: it’s not obvious. It’s not a given. How stupid of me — one of the products I use the most had faded so significantly into the background, I never thought of it. It just worked. And the reason it worked is because a human thought enough about how it should work, what the user would expect, what would allow it to really fade to the background. That was always the goal.

Ken even writes that he worried the keyboard would get in the way of the human user focusing on just typing. That’s ultimately what led him and others to simplify the keyboard, even eliminating the auto-suggestions bar on top of the keyboard (it’s now back in iOS).

En-vogue startup/corporate ethos dictates customer — and thus, human — centricity, but this is a good reminder of what it really looks like in practice. Kocienda explains Apple’s practice of “the intersection” of liberal arts and technology by quoting Jobs:

The reason that Apple is able to create products like the iPad is because we’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users. The users don’t have to come to them, they come to the user.

This reminds me of David Foster Wallace’s take on liberal arts thinking in This is Water (more on that in a later post), but it really comes down to choosing what is meaningful (users) and how to think about it (demos). For Apple, the devil’s in the details and in the rigor of the process. All the demos that Apple engineers do throughout the development process, with the constant emphasis on usability, are what are meaningful.

The feedback that comes out of those demos was pumped directly back into the product, often excruciatingly so. But it was, because the alternative wasn’t an option. As Kocienda writes: “[g]reat products make people happy almost all the time and do the opposite rarely, if at all.”

Think about that the next time you churn out a text or an email on your iPhone.

It’s all about momentum

Kocienda recalls his (failed) initial efforts to build an Apple web browser and how quickly he and his partner were blown away by a newcomer to the problem. Something he had tried for months to get working took someone with fresh eyes and an unencumbered brain just a couple days. It wasn’t a final product, but it was a big step.

Startups are all about momentum and speed (duh), but this is front and center in Kocienda’s early Apple narrative. Without this newly-created momentum, his first project at Apple might’ve failed, potentially spoiling his future at the company. Similarly, without an extremely rough, but functioning early product, a startup is toast.

What helps build momentum? Constraints. Kocienda explains:

Look for ways to make quick progress. Watch for project stalls that might indicate a lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make demos.

The biggest constraints here were time, available open-source software, and humans. Slightly abstracted, we all have these constraints: time, human resources, and material resources. How you perceive those constraints and use them is up to you, but this was my favorite part: Ken and his team used them to push towards demonstrable progress.

At a previous company, as a product manager, I often thought about how to create momentum, especially on a team of seven engineers who chafed at the idea of seemingly arbitrary deadlines (a whole other topic). We agreed on a system of, wait for it, mutually agreed-upon arbitrary deadlines, with varying levels of probability, toward demonstrable progress.

We used a whiteboard and put up each initiative we were working on, the picture(s) of the engineer(s) working on it (5x7), and the date the engineer(s) thought the initiative (or its sub part) would be complete (i.e., fully tested and deployed to production). We displayed the whiteboard to the rest of the office, where anyone walking by could see it, and incorporated it into our sprint meetings, executive discussions, demos, and retrospectives.

Among other things we did as a team, sprint after sprint, we started nailing our deadlines and shipping more higher-quality, customer-facing product, leading to happier customers.

There’s simply nothing like visible progress to build momentum.

Instinct leads to greater returns over testing

This one makes intuitive sense, but with a lot of the hub-bub around A/B testing, it can get lost in the shuffle. Kocienda uses the famous Google “blue button” A/B test to point out the incrementality in a testing-first approach and lamenting the “opportunity cost of running all the trials…[leading to] less time available for everyone on the development team to dream up a design that people might like two, or three, or ten times more.”

Listen to Keith Rabois and you’ll hear this echoed further. Product instincts have a higher likelihood to lead to 10x+ improvements than testing because instinct isn’t locally constrained like an A/B test inherently is. If there are 41 shades of blue in the test there are only 41 shades of blue to choose from. While instinct can be biased and fickle, for sure, it’s not as artificially constrained.

(This isn’t an argument against product testing as a concept, just A/B testing that avoids a decision that can be made. Product testing can be ridiculously effective.)

Overall, pleasantly surprised with the book. While some business books should be reduced to a blog post, I think the nuance Ken walks the reader through is helpful in understanding (and respecting) the decisions made, trade offs considered, and craftsmanship in building what hundreds of millions of us use every single day.




Product

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.

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.

Product

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

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.

Product

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. 

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

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.

podcast_app_product_axes.png

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