Menu

Where are your “invisible asymptotes”?

Eugene Wei’s Invisible asymptotes is a long, excellent article about the importance of not just thinking about product-market fit, but also product-market unfit:

For so many startups and even larger tech incumbents, the point at which they hit the shoulder in the S-curve is a mystery, and I suspect the failure to see it occurs much earlier. The good thing is that identifying the enemy sooner allows you to address it. We focus so much on product-market fit, but once companies have achieved some semblance of it, most should spend much more time on the problem of product-market unfit.

For me, in strategic planning, the question in building my forecast was to flush out what I call the invisible asymptote: a ceiling that our growth curve would bump its head against if we continued down our current path. It’s an important concept to understand for many people in a company, whether a CEO, a product person, or, as I was back then, a planner in finance.

He goes on to discuss those asymptotes for different companies (for example, shipping fees for Amazon). Another interesting bit:

We speak often of the economics concept of the demand curve, but in product there is another form of demand curve, and that is the contour of the customers’ demands of your product or service. How comforting it would be if it were flat, but as Bezos noted in his annual letter to shareholders, the arc of customer demands is long, but it bends ever upwards. It’s the job of each company, especially its product team, to continue to be in tune with the topology of this “demand curve.”

I see many companies spend time analyzing funnels and seeing who emerges out the bottom. As a company grows, though, and from the start, it’s just as important to look at those who never make it through the funnel, or who jump out of it at the very top. The product market fit gradient likely differs for each of your current and potential customer segments, and understanding how and why is a never-ending job.

Figuring out what your product’s invisible asymptotes are sounds like a really good thought process to me. At the beginning of the article Eugene mentions one way Amazon tried (and succeeded) in answering this question:

For people who did shop with us, we had, for some time, a pop-up survey that would appear right after you’d placed your order, at the end of the shopping cart process. It was a single question, asking why you didn’t purchase more often from Amazon.

Another technique he mentions:

One approach I’ve taken when talking to companies who are trying to achieve initial or new product-market fit is to ask them why every person in the world doesn’t use their product or service. If you ask yourself that, you’ll come up with all sorts of clear answers, and if you keep walking that road you’ll find the borders of your TAM taking on greater and greater definition.

A good way to frame this could be to ask yourself something like this:

If we didn’t change anything about [product name], at what point would we hit a growth ceiling, and what are the factors that would cause that?

If you can have a reasonably confident answer to where the S-curve inflection point will be, you can start planning on avoiding it early. That’s a worthy effort, and definitely something I intend to think through for our products.

Platforms and serendipity on the internet

In Filter Failures Ethan Chiel asks if platforms are sucking the joy out of the internet, and he makes a pretty compelling argument:

The internet as we use it now is, for the most part, what the large platforms want it to be: an engine for serving us what their various systems think we want, or what we wanted before, or what our demographics want en masse.

Here’s the problem:

What’s lost in the process is whatever you might have found that neither you nor an algorithm might guess is interesting. Some song in a forum thread you idly clicked on, a news item about something you’ve never expressed interest in or heard of that you read because you had 5 minutes to kill and it caught your eye.

This reminds me of how we used to browse music stores. We idly flipped through CDs, and picked a few to try out in the listening booth based on the cover, the song titles, and some undefined ¯_(ツ)_/¯ factor. Now we just see and hear what we’ve seen and heard before, and the cycle continues…

Product managers: don’t play favorites with methods and techniques

While reading this great interview with the band CHVRCHES I came across a passage that struck me as a good description of how product managers should work. They describe the producer on their latest album like this:

And I think that’s why he’s so good at what he does. He’s not a kind of producer that has one thing that he does and he tries to make every artist do that thing. He steps into the room and tries to figure out the people that are in it and figure out the music they’re making, and then how can he add something to that and offer wisdom and guidance and make it better.

We all have methods and techniques we gravitate towards: Jobs-to-be-Done, Agile, customer journeys, sticky notes… It’s totally fine to have favorite methods that we know inside out and that have worked well in the past. But it would be a mistake to force one of our favorites on a team when it’s not the right thing for them.

One of the most difficult things a product manager needs to do is first understand how a team works and what makes them effective, and then figure out which methods and processes can create the right environment for them to thrive. That’s the skill that sets apart the great product managers from the good ones.

Tips for better estimates

Ah, estimates. That thing we all know we need to do (and get better at), but no one really wants to talk about. Well, Gina Trapani takes the topic head on in a great post called Estimation Is a Core Competency:

Estimates don’t need to be perfectly accurate as much as they need to be useful.

Good estimates create trust among your PMs and business leaders and collaborators. Being able to identify the risks and uncertainties in a project early gives your project team the information they need to plan around those risks and uncertainties.

Are you consistently getting waylaid by unforeseen work mid-flight, or just taking longer to execute on the work you did know about? That creates distrust between engineers and business leaders, and if it happens repeatedly, that distrust compounds and calcifies into resentment— that is, if you’re still in business.

Gina goes on to give some great tips for better (i.e. more useful) estimates.

“One Laptop Per Child”: a great solution to the wrong problem

Do you remember the “One Laptop Per Child” project? The PR event made a huge splash back in 2005, and I remember being really impressed and inspired. As it turns out, OLPC is a textbook example of what happens when an organization has a sincere desire to solve a problem that they simply don’t understand.

Adi Robertson, writing for The Verge, has an excellent history of the project called OLPC’s $100 laptop was going to change the world — then it all went wrong. It starts with this anecdote:

Then, Negroponte and Annan rose for a photo-op with two OLPC laptops, and reporters urged them to demonstrate the machines’ distinctive cranks. Annan’s crank handle fell off almost immediately. As he quietly reattached it, Negroponte managed half a turn before hitting the flat surface of the table. He awkwardly raised the laptop a few inches, trying to make space for a full rotation. “Maybe afterwards…” he trailed off, before sitting back down to field questions from the crowd. […]

If you remember the OLPC at all, you probably remember the hand crank. It was OLPC’s most striking technological innovation — and it was pure vaporware. Designers dropped the feature almost immediately after Negroponte’s announcement, because the winding process put stress on the laptop’s body and demanded energy that kids in very poor areas couldn’t spare. Every OLPC computer shipped with a standard power adapter.

As you read deeper, it becomes clear that they were working on a solution that didn’t take local issues into account at all:

Bender thinks OLPC might have struck more deals if it had focused less on technical efficiency. “Every conversation we ever had with any head of state — every time — they said, ‘Can we build the laptop in our country?’” he says. “We knew that by making the laptop in Shanghai, we could build the laptop [to be] much less expensive. And what we didn’t realize was that the price wasn’t what they were asking us about. They were asking us about pride, not price. They were asking us about control and ownership of the project.”

To put it another way:

OLPC had created a computer that could withstand dust and drops, but it hadn’t accounted for political messiness.

There are many lessons to learn from this story, but most important is almost certainly that a desire to do something good isn’t enough to make a product successful. If you don’t fully understand the problem you’re solving and the people you’re solving it for, your chances of success are incredibly low.

Echo chambers and epistemic bubbles, and how to break through

Thi Nguyen’s essay Why it’s as hard to escape an echo chamber as it is to flee a cult is one of the most insightful things I’ve read in a long time. Nguyen argues that echo chambers are very different from what he calls “epistemic bubbles”, and that conflating the two concepts places our focus on the wrong solutions to the problem. In short, the difference is this:

In epistemic bubbles, other voices are not heard; in echo chambers, other voices are actively undermined.


Epistemic bubbles are easy to pop, because all it takes is to introduce previously unheard voices into it. Echo chambers, however, are extremely difficult to penetrate, because at its core lies the belief that everyone not in it is untrustworthy:

An ‘echo chamber’ is a social structure from which other relevant voices have been actively discredited. Where an epistemic bubble merely omits contrary views, an echo chamber brings its members to actively distrust outsiders. In their book Echo Chamber: Rush Limbaugh and the Conservative Media Establishment (2010), Kathleen Hall Jamieson and Frank Cappella offer a groundbreaking analysis of the phenomenon. For them, an echo chamber is something like a cult. A cult isolates its members by actively alienating them from any outside sources. Those outside are actively labelled as malignant and untrustworthy. A cult member’s trust is narrowed, aimed with laser-like focus on certain insider voices.

Or to put it even more succinctly:

An epistemic bubble is when you don’t hear people from the other side. An echo chamber is what happens when you don’t trust people from the other side.

This is a long essay, but I highly recommend reading the whole thing. It was a real eye-opener for me.

Tracking development uncertainty with hill charts

I read something recently that struck me as a really good idea for our team. Usually that feeling goes away after a couple of hours (“nah, it’s cool but not a good fit for us”) — but not this time. In Running in Circles, Ryan Singer talks about the knowns/unknowns in a project like a hill:

The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.

At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.

He has a a nice visualization of it:

He also uses an example from a recent project to show how they map this out:

As they “move over the hill”, different parts of the project become known, and they become more certain about what’s left to do. We’re working on some checklists to identify development risks before we start a project, and this looks like a great way to visualize those risks and track them as you go.

Social internet, social media, and the move to smaller networks

I should stop reading (and writing) about Facebook at some point, but there’s been some really interesting thinking around the social internet in general recently. I especially enjoyed Benedict Evans’s The death of the newsfeed, because it puts into words a lot of things I’ve been thinking about. On the social implications of algorithmic feeds:

One basic problem here is that if the feed is focused on ‘what do I want to see?’, then it cannot be focused on ‘what do my friends want (or need) me to see?’ Sometimes this is the same thing – my friend and I both want me to see that they’re throwing a party tonight. But if every feed is a sample, then a user has no way to know who will see their post. Indeed, conceptually one might suggest that they have no way to know if anyone will see this post.

This is one of the major flaws of algorithmic feeds. People share things so that those things can be seen. But if you can’t tell who will see the things you share, that’s frustrating, and more than a little nerve-wracking. Hence the move back to smaller networks:

I think one could suggest that this is some of what’s behind the suggestions of systemically lower engagement on Facebook newsfeeds, and behind the obvious growth of person-to person chat (most obviously WhatsApp, iMessage, FB Messenger and Instagram – three of which Facebook of course owns). The social dynamics of a 1:1 chat work much more strongly against overload, and even if one person does overshare they’re in a separate box, that you can mute if you like. […]

Messaging can be more private, have less social pressure, and be more fun. A Snapchat story isn’t a permanent record and has less pressure to show off your perfection. Stickers and filters are more fun and spontaneous than Facebook’s rigid blue boxes (and the days of throwing sheep at people are gone alone with Facebooks’ platform). And some of these offer light-weight ways to interact without obligation, which was also a feature of Facebook’s model, but deliver that piece of Maslow in different ways.


On that note, I think the distinction Cal Newport draws in On Social Media and Its Discontents is really important:

There’s a distinction between the social internet and social media.

The social internet describes the general ways in which the global communication network and open protocols known as “the internet” enable good things like connecting people, spreading information, and supporting expression and activism.

Social media, by contrast, describes the attempt to privatize these capabilities by large companies within the newly emerged algorithmic attention economy, a particularly virulent strain of the attention sector that leverages personal data and sophisticated algorithms to ruthlessly siphon users’ cognitive capital.


In the final analysis, I agree with Cal:

I support the social internet. I’m incredibly wary of social media.

More

  1. 1
  2. ...
  3. 56
  4. 57
  5. 58
  6. 59
  7. 60
  8. ...
  9. 203