The Doorbell in the Jungle

A pattern for cultivating positive exposure to miracles

Gardening Platforms explains the reason why taking a horizontal approach to building products and platforms can unlock miraculous outcomes with minimal risk. The downside is that the tactics are often highly counterintuitive and can seem almost backwards.

This post builds up a fanciful (and slightly silly) parable to help build better intuition about why some of those horizontal patterns work, and then unpacks some of the implications for practical strategies.

A fanciful parable

There once was a thriving industry selling a particular type of widget. The widgets were super premium quality, carefully customized to each buyer and made to exacting standards. Even with the most talented artisans, 90% of widgets that were produced were rejects. Widgets were a luxury good, so it was important to have the utmost quality to entice discerning customers to buy them.

One particular widget store in Colombia was packed in tightly next to neighboring stores. The front of the store faced a busy shopping street. The back of the store faced a dense jungle.

The front of the widget store had a glamorous display window aimed at showing off the finest widgets in meticulously maintained marketing displays, enticing customers off the street. Inside was a sparkling showroom full of attentive sales representatives who would meet with every customer, work to understand their needs and then, at great expense, selected precisely the widget to sell to them, customizing one if need be. The store had a reasonable profit margin on the widgets, but it took so much variable cost of sales people and support for those front-of-house customers that they made only a linear amount of value: each additional salesperson or artisan craftsperson made a small additional bit of profit for the store.

At the back of the building was the factory where artisans toiled to make the widgets. It was also where reject widgets piled up, and every so often a recycling company came to collect them and sell them for scrap.

A new employee named Luiza joined the organization. She saw all of the reject widgets piling up every day in the back of the building, and realized that if the company could somehow find a buyer, they’d be able to unload a number of widgets in bulk without having to pay the expensive variable sales cost for premium widgets. If the company could find buyers for those reject widgets, it would transform the business. But who would ever want a reject widget? Still, Luiza had an unshakable feeling that the business could be better off.

Luiza tried to make the case for transforming the business around selling reject widgets from the back of the building to wholesale customers. But everyone thought she was off her rocker — building a loading dock and receiving area in the back of the building would be a considerable expense, and all profits were being plowed into hiring more salespeople and artisans. The theoretical wholesale business would have to have hundreds of millions in sales to make it bigger than the front-of-house business, and did she really expect people to hack through the jungle to get there? All of the Serious Business People in the company didn’t have time for such a fanciful idea — they were busy linearly scaling the business, as Serious Business People do. No one could agree on how much demand they could reasonably expect — but everyone could agree it would be a miracle if someone were to hack their way through the jungle. Everyone was extremely busy with the demand of their current jobs, so nothing happened.

One day as she was walking to work, Luiza saw an old door lying out along the road and had an idea. She picked up the door and bought one of those new-fangled wireless doorbells. The next morning she woke up early and hacked through the jungle to the back of the store building. She used copious amounts of duct tape to attach the recycled door along the back wall. Next to the door she attached the wireless doorbell. The door wasn’t operational, but if you didn’t look too closely the Potemkin door seemed realistic enough. Then she went back to the front of the building — only a few minutes late to start her shift — and went about her day.

For a month or two nothing happened. Then one day, the doorbell chime rung throughout the building. “What’s that?!” the Serious Business People cried out. Luiza went to the back wall and peered out through a small vent. Improbably, there was a person at the fake door in the back of the building, looking a little worse for wear.

“Can I help you?” Luiza asked through the vent.

“My name is Bruno. I was wondering if you might be willing to sell me a few hundred of your widget rejects,” the person responded. “I’ve got to set up an auction for a fundraiser at my community center and I have nothing to sell.”

“We might be able to. But… how did you get here?”

“Well, I’m desperate, you see. If I don’t get something to sell at this fundraiser the community center will go defunct. I figured you might have some rejects to sell, if I went around the back. It was… a bit challenging to get back here (there are tons of bramble bushes!). But I’d really appreciate if you could sell them to me.”

A pile of reject widgets was just sitting there, waiting to be picked up by the recycler the next day. One of the Serious Business People did a calculation and quickly spoke up.

“They’re willing to buy our rejects? And in a single transaction with no retail sales support… that would make us more profit than we make in a typical week all at once. Open the door! Let’s sell it to him!”

“That’s a wonderful idea,” explained Luiza, “but we have a problem. There is no door. You wouldn’t let me build one!”

“Well let’s make one. We have a sledgehammer don’t we? This is enough money that it’s worth it!”

So they sledgehammered open a space in the wall. Bruno looked slightly bewildered as the a hole crumbled open in the wall. But he handed over the cash, and took the reject widgets.

“If this is a success, I’ll be back,” Bruno promised.

The Serious Business People high fived at the unexpected bonanza. Someone jury-rigged the old door in place over the new hole in the wall to keep the elements out. It was now a real door… kind of.

Time passed. Then a few weeks later the doorbell rang again. The Serious Business People recognized the sound immediately and ran to the back of the building. It was Bruno.

“It was a huge success,” Bruno exclaimed. “I’ll take double the order, if you have enough.”

There just so happened to be enough reject widgets lying around that hadn’t been picked up by the recycler yet. The Serious Business People, dollar signs in their eyes, packaged up all of the rejects and took his cash. Luiza suggested using a tiny bit of the profits to get a proper door installed. The Serious Business People, celebrating their second unexpected bonanza, told her to do what she wanted.

And so it went: every few weeks Bruno came and took a large collection of rejects off their hands. They started deliberately maintaining a stockpile of rejects to make sure they’d have enough on hand, just in case he came back.

A few months later, the doorbell rang, and Luiza was surprised to see an unfamiliar face.

“What can I help you with?” she asked.

“I’d like to buy some of your reject widgets in bulk, if that’s something you do?”

“We can… but how did you find out about us?”

“Well, Bruno is a friend of a friend. He had been making quite a splash selling widgets at his community center. I thought maybe it would work at my community center, too. I asked him where he got all of the widgets, and he said he went around back and got them at a discount. It was hard to get here — there are a ton of bramble bushes back here! — but I managed.”

He wasn’t asking for quite the same quantity as Bruno had, but they already had a door back there, and a pile of extra widgets on hand, so it was a no brainer to sell to him. A few weeks passed and the new customer came back, asking for a larger order this time. And so it went for a few months, with Bruno and this new customer showing up every so often.

Then the doorbell rang and there was yet another unfamiliar face.

“How did you get here?” Luiza asked.

“Well, I figured it would be great if there were some way to buy rejects at a discount. I didn’t know if you did it, but I saw what looked like just the faintest trail leading through the jungle around the back, and I figured I’d try. I got pricked by a few bramble bushes, but it wasn’t too bad.”

The new customer wanted an even smaller amount than either existing customer, but the pile was just sitting there so it was still a no-brainer to sell to him. Luiza suggested converting one of the storage closets to be reject widget storage, now that they had to keep a much larger number on hand for any of the wholesale customers who might show up. Again, the Serious Business People quickly acceded, since it was such a small expense compared to the bonanza.

One day a few weeks later two wholesale customers came at the same time. Luiza suggested putting in a proper desk to receive customers, which again was accepted as a no-brainer.

The number of customers got larger and larger as word of mouth spread, and some customers even came from the next city over. One day during her shift Luiza went to the back of the building to hack away some of the bramble bushes and make it easier to get to the back of the building. One of the Serious Business People saw what she was doing and pitched in.

The number of customers continued to increase. One of the Serious Business People inspected the little path that had formed through the jungle and suggested that if they paved it with gravel it would make it much easier for their customers to traverse. Luiza pitched in to help lay the gravel.

One day a customer had such a big order that they tried to drive their four-wheel drive along the gravel path to the back. They were able to make it to the back door successfully, but just barely. Luiza and one of the Serious Business People decided to invest a day of effort in widening the path and filling in a few of the uneven dips to make it easier for four-wheel drives to make it.

Business continued to pick up. Over time the back of house evolved to have multiple loading bays, multiple parking spaces, and a well-lit paved street to it. Finally, the business built a sign at the street announcing the wholesale reject widgets available in the back.

Years later, the front of house still existed, but it was more of a small scale boutique. Most of the business was done wholesale at wildly better profit margins. Luiza went from an unrealistic dreamer to the person who had saved the company.

And all of it started by putting a doorbell in the jungle, just on the off chance that a miracle would happen and someone would come by and ring it.

Why this pattern works

The Serious Business People were looking at the cost to build a whole, high-quality wholesale business over the long-term and the expected amount of business that it would take in, in one big lump. There was no current demand for it — what customer would be crazy enough to hack through the jungle for an uncertain reward—so the uncertainty on expected volume was huge. Even if they had projected it to be highly profitable per transaction, if they multiplied it by a very small likelihood of happening, the expected value would be too low to invest in.

The Serious Business People had an error in their analysis. If they wanted to jump in with two feet and build everything all at once, then yes, they’d need to have a clear case for huge amounts of profits that make all of the upfront investment worth it. But that’s not what Luiza proposed. Luiza was proposing a teeny investment — the doorbell in the jungle — just in case, and then continuously and incrementally responding to any demand that showed up.

The cost of installing that doorbell in the back was basically nothing: just a early morning from Luiza and a $5 doorbell. The downside was both tiny and capped. But the upside was large and uncapped: if traffic miraculously showed up, they could transact with that traffic for large profit. From there, they could incrementally invest more and more, in response to concrete, as opposed to theoretical, demand. At each point they could stick their neck out just a tiny bit with some incremental investment. Every step after that first tiny leap of faith could react to concrete demand instead of speculating about it, making the extension of the business continuously viable along its evolution. At any step the demand for the next step might not show up, but then they’d only have stuck their neck out by just a tiny additional bit and wouldn’t lose much.

The jungle created a kind of naturally-occurring gauntlet: a challenging sequence of steps that potential customers had to navigate. The customers that made it through the gauntlet had crawled through bramble bushes, which demonstrated that they were extremely motivated. Those self-selecting users demonstrated the tiny critical mass of initial demand. Whenever you have extremely motivated users, it’s likely there’s even more demand that is just barely below the current user’s pain tolerance bar. If you reduce the amount of bramble bushes the customers have to crawl through, then you’ll unlock more demand because you’ll allow a larger set of users with slightly lower motivation to become customers.

A product has Product Market Fit (PMF) if the value you unlock is greater than the cost of building the product in the first place. We typically think of PMF as if it’s some global threshold. But the PMF threshold is tied to a specific population: the “market”. If you can define the “market” down to a very small collection of highly motivated users, then even a seemingly low-quality offering can have PMF, just with a very small but highly motivated “market”. If the amount of investment you’d have to make is small, the smallest viable “market” that makes it worth doing can be very small indeed.

You could make a more explicit and large business case for a big investment based on a long-term speculative Total Addressable Market (TAM)… but why do you need to? If the decision in front of you is very small and has very little opportunity cost, then you can have the best of both worlds. If no demand materializes then you’ve lost only a tiny fixed opportunity cost. But if there is demand you can respond to it reactively with no risk and all of the upside.

This pattern works when you have some existing things that can be duct-taped together at very low expense, and where once you have concrete demand you can quickly service it before the opportunity goes away. It works especially well when your product is open-ended, allowing your users to do novel things without permission that you can react to. For this pattern to work you also must be able to be patient. A complementary successful linear-returns business can help extend your runway and give you considerably more time to wait for a miracle to occur.

There’s a good chance no one will end up ringing any particular doorbell, but if they do, drop everything and go respond to their request! The likelihood that any one miracle happens is low. But if you place a large enough set of doorbells and are able to be patient, the likelihood at least one of them triggers is high — the likelihood is proportional to miracle-rate-per-doorbell X doorbell-count X time.

If the doorbells are cheap enough you can install lots of them in different places, allowing you to react to concrete demand from a diversity of possible directions instead of having to guess where the theoretical demand will come from. By installing doorbells, you reduce the need for there to be a single product with large TAM that everyone in the organization agrees to focus on. All you need is everyone to agree that installing the doorbell is low cost, and that if a customer were to ring the doorbell it would be an obviously good idea to respond to the request. This is a significantly lower bar than making the case that the ultimate value of that direction is large. Instead of making a highly speculative case about the floor of value, you make a case for a very low ceiling of cost. To make a case to put the doorbell in place you’re minimizing the chance that the small cost is not recouped, not trying to maximize the value.

By placing lots of doorbells you also neatly avoid having to create a significant organizational schelling point, spending inordinate energy to get everyone in the organization to agree to coordinate on going after one potential set of theoretical customer demand among all of the other theoretical options. Instead, you can place lots of little doorbells on different options. Once a doorbell is rung, it becomes much easier to rally the organization around that concrete demand, because everyone can hear the demand with their own ears.

One of the reasons this pattern works is because demand across customers is not independent, but rather coevolves across the population of customers as more and more investments are made to reduce the bramble bushes. The early adopters might be a bit rough around the edges. But over time as more and more on-ramps are created for less-and-less motivated users, you can walk up into the head of demand.

Of course, doorbells are not free. If your entire product offering is doorbells and no real doors, then the overall product might be dismissed as vaporware. You also want to make sure that building a door when a doorbell rings won’t be dangerous — if it violates a key part of your security model or would allow customers to do self-harming actions, then you shouldn’t build it. It’s also important that everyone can agree that if the doorbell were rung, it would be a no-brainer to respond to it. If some enterprising sales person went around putting doorbells up everywhere, even if one of them rings then it’s not necessarily a good idea to respond to it — it might pull you into a random distracting corner, or cause you to build a feature that undermines the whole product. It’s best practice for product leads to be the ones to decide where to put doorbells, ensuring that responding to any of them would help evolve the product in a direction aligned with a coherent long-term strategy.

Realistic examples of the pattern

What do doorbells in the jungle look like in the real world? Here’s a few examples inspired by real situations.

Developer sign up form

Imagine you have a product that includes developer documentation. A simple doorbell might take the form of a page deep in your developer documentation that describes a feature you’re considering building, and has an email signup form for potential customers to register interest. When someone submits their email, hop on the phone with them immediately to understand their use case and motivation!

Informal store listings

Imagine you have an open-ended application (say, something like a spreadsheet app) that allows savvy users to create complex configurations specialized to their use. If you add a feature that allows users to create a deep link to a pre-saved template as a starting point, you’ve created a doorbell in the jungle. Watch carefully in your usage stats for deep links that are used by more than a few users. You might find that someone has created a viral, surprising configuration that implies demand for an extra feature you could add directly to the main application. Or maybe you discover that someone spent a whole lot of time building a carefully crafted configuration and is now selling access to the link for $5. If you see that, a reasonable next step is to allow people to manually control permissions on their configurations. Next, you could have creators have a profile and list their public and private configurations. Then down the road you could make it easy for creators to accept payments directly in the app. Maybe you can even develop a whole marketplace within the app!

Geek mode

Imagine you have an application with a ranked feed as the main interface. You could add a “geek mode,” hidden deep within settings, that allows the most motivated users access to all of the knobs and switches your app uses internally to decide how to rank content in their feed. (Be careful that you think the semantic model you expose is one you want to commit to supporting long-term, since one it’s exposed it will be hard to change.) Very few users will find the time to invest in customizing their feed, but those that do will give you a wealth of information. You could reach out to them for targeted UXR interviews to understand their goals and see where there’s bramble bushes they’re crawling through that might be reduced, unlocking demand from more users. You can also figure out clever ways to aggregate those motivated users’ behavior and feed them into the default ranking configuration you use for less-motivated users.

Viewer to editor

Imagine you have a legacy desktop software application that allows highly motivated and specialized content creators to configure collections of information as XML files that can be viewed within the application. For example, perhaps it is geospatial software that allows creators to configure collections of Points of Interest (POIs) and lines to view superimposed on the globe. Years ago someone in the company built a simple web app viewer that can take an XML file and render it in a view-only mode in a browser. It’s currently used as a quick demo on the marketing page to try to encourage the specialized creators to download and use the full application.

One day an engineer on the team who is themselves an enthusiastic user of the application decides to implement an easter egg in the marketing site. If you visit the viewer web site and append a parameter to point to a publicly-hosted XML file, the viewer will load up that file and display it. To ensure that some jokester couldn’t load up offensive content and make it look like it was something the company endorsed, if you use the easter egg parameter, a dismissable warning banner shows up at the top of the page explaining that the content is provided by a third party and that the company doesn’t necessarily endorse it. The engineer uses the easter egg feature for a few of her personal hobby projects that she shares with other enthusiasts, but then she forgets about it.

A few months later something catches her eye in the usage stats: a few different XML files are being viewed by users in the wild, and one of them has hundreds of thousands of views. They’re all cool (if a little offbeat) uses of the platform. She checks the referrers to find where the file was shared and reaches out to the author on Twitter. When she talks to him she realizes that what had happened is another enthusiast had noticed the easter egg she was making use of. They wrote up a little guide on how to use the easter egg, and shared the unofficial guide with some other enthusiasts. The author of the viral XML file had found the guide and used it to share what he had created.

That inspires the engineer to invest a bit more time. She adds a feature where if you load an XML file, you can also open a text box in the web app and tweak the XML manually, seeing the results live in the viewer. Later the marketing team sees an increase in organic interest in the full version of the application. It turns out that a collection of new users had gotten introduced to the full application by simply tinkering in the web app, and that made them more motivated to install and use the full desktop app. In addition, users of the main desktop app can now publish their creations to a much larger audience of users who would never have installed the app but are happy to click a link. The company decides to let the engineer spend most of her day job on this web viewer.

The enthusiast usage continues to grow, so then she adds a feature where a user can store a bit of custom XML directly in the web application and edit it live. Later, looking through the XML files being hosted, she notices that the vast majority of them were just a simple listing of POIs, not using the full expressive power of the XML format. For files that are of this type, she adds a simple GUI to allow those to be tweaked directly in a UI instead of dropping into the full manual editor for XML. Of course, the full XML “geek mode” is still available for users who choose to drop into it. Now the engineer watches carefully in the real-world behavior for examples of XML files that users regularly switch into geek mode for. She uses those patterns to prioritize what features to add to the GUI. Her guiding principle is to minimize the number of times that motivated users have to open geek mode to get their task done.

It turns out that that metric is a stable north star. As new populations of users begin using the application, the aggregate behaviors will change, but the “minimize how often motivated users need to open geek mode” stays a stable northstar to sight off, automatically rebalancing to what the community most wants and allowing the ecosystem demand and the platform to coevolve with each other. Over the course of many years, the company finds that the legacy desktop application can be sunset because the web app has graduated to be a full-featured viewer that embraces a larger population of creators than the desktop app ever did.

Three-bucket ranked results

Imagine you have a directory of content provided by third parties, where a user gives a query and a set of result content is returned. (The query need not literally be a formal query, it could be the user clicking on a category, or some other mix of context signals that form input into a ranking system.)

You want to make sure that users seed good-enough results for queries they make. If they see bad or spammy results, they will lose faith in the whole product and might never return. The content for a given query is simply sorted by how popular each piece of content has been for previous users.

You have a supply of starter content, some created by an in-house team, some by trusted partners. But it’s expensive to create the content, and so the product is growing slowly.

A third party approaches you and asks if they can submit their content into the system. Your content team looks at it and is unsure — it’s a bit more offbeat than official content. The marketing team is unsure about allowing “unofficial” things to be ranked in the system and erode the fledgling brand of the product. After a lot of hemming and hawing, you agree to allow this particular piece of content into the system.

Over time a larger number of third parties come and propose including content. Some of it is clearly high quality, some of it is more questionable. The marketing and editorial teams are getting overwhelmed and propose just not including any third party content at all.

Instead, a clever engineer at the company creates a system that changes the dynamic entirely. Where once there was one bucket of ranked results for a query, they instead create three:

1. Featured content. This is “official” content that your company has vetted and actively endorses. Results in this bucket show up at the top of the results page and are styled specially. All of the existing first party content and content from trusted partners goes in this bucket.
2. Main Results. This is the second bucket, for content that is above some minimal bar of quality. The content is fine but the company doesn’t actively vouch for them as being especially good. These are the generic search results and show up below the featured content section. At the beginning, this bucket is empty.
3. Low-Quality Results. These are results that are not yet known to be above some minimum quality bar. It’s either content that hasn’t yet been used by any users, or might have signals that imply it’s low quality or spam. Critically, these results are not visible by default for a query. Motivated users must click through to a second page of results, or expand a collapsed UI element that says something like “10 additional low quality results”. New content with no quality signals goes in this bucket.

This system seems basically the same as the previous system, but it has a crucial difference. New content from anyone can go into the low-quality results bucket immediately and doesn’t need to be vetted. Only very motivated users will click through to that second page of results. This self-selecting group of users is more motivated, and thus more resilient and less likely to leave the product in a huff if they come across lower-quality content that was tucked away. This means you’ve capped the downside of low-quality content.

But some content that starts off in the low-quality bucket will turn out to be pretty good. If you notice that users who click through and see a particular piece of content like it, you can boost it up into the main results, showing it to more users by default. This means that content producers will want to compete on quality to earn a spot higher up in the main results. This means you have the unlimited upside of good quality content, and have set up incentives where content creators in the ecosystem will want to create good content. You can also use quality signals to boost new content into the main bucket automatically; for example if that author’s other content has typically done well you can start it off in the main bucket.

This pattern is extremely stable. As long as you continually invest a bit of effort in updating the ranking function and make sure it’s not being actively gamed, the quality of the content and results will get better and better for your users without you having to do much at all.

Internal tooling to aggregator ecosystem

Imagine there’s a consumer app that allows users to share short videos with one another, augmented with goofy filters.

At the beginning, all of the filters are bespoke and manually created by engineers that work at the company implementing ideas from the design team. Over time as it becomes more clear what kinds of filters are most popular, a few common patterns emerge. One is face filters, where the filter detects where a person’s face is and then applies a mask of image assets over the face. An engineer makes a very simple tool that allows designers to create the image assets and a small bit of declarative configuration XML and have them show up within the app. This creates a simple “engine” that allows a large number of filters to be created without involving the engineers at all. It’s not possible for non-engineers to introduce serious bugs or unexpected behaviors, because the engine takes only declarative configuration with a limited alphabet of expressivity.

Over time more and more knobs are added to the engine, allowing more expressive filters to be configured in XML. More and more types of fundamental filters are added and the expressive capability of the declarative format grows considerably. Over time, the declarative language grows more and more advanced concepts including loops, event handlers, if statements, and variables. Someone points out that the configuration language is now technically turing-complete, meaning the turing rubicon has been crossed. But the inputs and outputs to the engine are carefully controlled, so it’s still safe to expose to even random designers.

The demand for filters grows so quickly it outstrips the ability of internal designers to keep up, so some agencies are brought in as contractors. These are basically employees, so it’s fine to expose the internal configuration tool to them. As more and more people use the tool, it is continuously invested in to make it easier and easier to use and becomes more and more polished.

Later a big advertiser proposes making a filter to show off their brand. They are so motivated that they offer to even build it themselves. The core team is busy, but it’s easy to open up the tool to be used by an allowlist of external accounts.

A few months later there are thousands of external accounts with access to the system, and the tool has gotten pretty polished. It’s quietly opened up for motivated creators to use. A few weeks later, some new unofficial filters goes viral. It’s a bit offbeat — not something the company would have built or approved themselves — but there’s no denying it’s a massive hit.

Over time the amount of supply of filters from the community grows to such a point that there are too many lenses to show in the carousel within the create screen of the app. A button is added to the carousel to pull up a full filters directory. Very few end users open it, but by closely watching which filters those motivated users use seem to like, the app can rank which filters to show in the carousel, organically allowing the best filters to rise to the top.

A bit later, a filter creator eager to get distribution for their filter offers to pay some money to boost their filter to get into the top ten carousel. The company accepts, deciding to reserve up to one slot in the carousel for promoted filters.

The company has now grown into an aggregator, with dual flywheels of supply and demand, as well as differentiated demand competing to find new innovative filters. The aggregator gets to benefit from all of that inherent innovation and demand from the swarming behavior of the suppliers without having to invest too much of their own effort or risk in trying to guess which filters will be most popular ahead of time.

The Rummage Drawer

Let’s imagine you have a successful product that is primarily consumed via the web on desktop. A few years ago you implemented a mobile native app just because you felt like you should have one. You never developed a core product vision for the app — an inherent reason for it to exist — and instead kind of just implemented random features over time. It’s now a somewhat random subset of the full functionality. The app has a set of highly engaged users (who don’t appear to have much in common), but the usage of the app is dwarfed by the desktop web experience. The mobile app is a weird vestigial part of the overall experience; too popular to kill, but too random and scattershot to invest in properly.

You were just assigned to be the PM for the mobile app. What do you do? The canonical answer is to examine it from first principles. You ask yourself some variant of the question “If we didn’t have the app today, would we decide to build it?” to find a reason for the app to exist. The answer to that question is likely a shrug (the usage today is too scattershot and random), so instead of recommending killing the app (and putting yourself out of a job!) you instead do UXR and focus groups to figure out a key job to be done for the app. You then rearchitect everything in terms of this bold, opinionated vision, including cutting out all of the random features that don’t fit in this new concept.

What almost certainly happens is that the new vision goes into development hell where it’s not possible to get enough internal buy-in to make it a reality. And even if you do, you relaunch the new app with fanfare, only to find it gets even less use than the old version… and a few years later after a reorg some new leader puts it out of its misery and kills it for good.

The canonical approach makes a number of critical errors.

First, the “if we didn’t have the app today would we build it” is flawed logic. It seems like a useful frame, a kind of zero-based budgeting technique to make sure you’re considering the opportunity cost of keeping a moderate success alive. But the lens is flawed because you get to take for granted your starting point. You don’t have to prove to yourself that the starting point of the app as it exists is viable… by construction it is! The question is entirely “what kinds of cool things could we achieve, given that we have this starting point”. The “would we build this if we didn’t have it” gets at that core question indirectly, by smooshing together “would this be a valuable starting point” and “would this be valuable”. In the vast majority of strategic questions, the “would this be viable” dominates your analysis — the vast majority of seemingly great ideas get stuck in the mundane filter of real world viability. But when you have an existence proof that it is viable, you can focus entirely on the real question of “is the potential value we could create from this starting point worth the direct and indirect cost of maintaining it.”

Second, even though the users of the app today seem to be a random hodgepodge of users, they are still proactively using it, demonstrating high intent. As you talk to the users, start from the assumption they are high-pain-tolerance users who can see value that other users can’t; that their usage patterns are not random blips but the tip of an iceberg of value that could be activated if only the sea level were lower. This isn’t always the case, but if you steelman this hypothetical you might discover that there are a series of no-brainer investments you could do that would be likely to at least pay for themselves even if the hypothesis is wrong, but if the hypothesis is right would unlock significantly more value.

Finally, the desire to impose a clear vision on the current users misses the fact that your vision might not turn out to be viable for most users. Instead of assuming you know precisely what users want, leave an opening for the most motivated users to show you, through their behaviors, what they want most. In your user interviews you might figure out the core platonic value of the app as it exists; almost retconning a meaning onto the emergent jumble. You can then invest more in the features that match that revealed throughline of value. But don’t get rid of the other features, which might make the app go from useful to fundamentally unuseful for some subset of users. Instead, you can put those random grab bag of features that don’t fit in your new vision into a rummage drawer of your app — tucked away behind an overflow menu, perhaps. Your most motivated users will still be able to get to those features, but the features won’t bother everyone else. The features you put in that rummage drawer can meet a lower bar of quality for viability — they’ll naturally be seen by fewer, more motivated users — making it an optimal place for experimentation. And then you can watch which features users use in the rummage drawer to decide which ones to invest incremental investment in. The rummage drawer might offend your modernist design sensibilities, but it will give you a broad field to observe your users’ desire paths emerging in. As a PM you often want to work on exciting problems that your leadership team values, but that requires you to have a bold, clear, legible vision… which will likelyturn out to be wrong. When you’re working on a satellite project that everyone agrees shoouldn’t be killed, it gives you the freedom to experiment and find great, possibly game-changing ideas without the pressure of pretending to have a perfect top-down vision.

Why this pattern is a secret

If this pattern is so powerful, why doesn’t everyone do this all the time?

Everyone know that Serious Business People have plans, and the more numbers and figures attached to those plans, the more Serious they are. Serious Business People carefully survey the landscape, model possible outcomes, pick the best plan among various alternatives, and then commit to rallying the entire organization around that plan so that everyone inside the company and the external customers can have faith in a roadmap. This is the vertical approach, as described in Gardening Platforms. It is the default approach because it feels concrete, heroic, and certain. No one ever got fired for being a Serious Business Person. This approach will typically have good, but rarely great, returns.

In contrast, the doorbell in the jungle approach is an example of a horizontal approach. It lets go of the idea of concrete, specific pre-planned features, instead focusing on surfing through concrete demand reactively. Those pre-ordained roadmaps of the vertical approach come at a cost: you have to invest tons of time to research a plan, socialize it, and then commit to it. If it turns out you got it wrong, it’s hard to change the direction of the ship once it’s in motion. Meanwhile you might be missing miracles that land in your lap. The horizontal approach looks loosey-goosey and not very serious, like the practitioner is just happening to get lucky. But while any specific miraculous outcome is indeed luck, the likelihood of a miraculous outcome is quite high, because the practitioner has been deliberately increasing their stochastic luck surface area.

Most organizations want a mix of vertical and horizontal approaches. They use the typical vertical approaches for a large portion of their portfolio, and then empower employees to take some of the remaining capacity to place doorbell bets based on their best judgement. Finally, they must make sure there’s enough slack to be able to jump on the opportunity if a doorbell rings.

The doorbell in the jungle pattern is an example of optimizing for serendipity. It would be a miracle if someone hacked through the jungle to ring that doorbell — but it’s very low cost to get positive exposure to that miracle so why not do it? By following the doorbell in the jungle pattern, you cultivate positive exposure to a diverse set of miracles. Done well, you can practically guarantee a miraculous result. All you have to do is let go of a bit of the illusion of control and certainty.

Editor’s note: a reader pointed out the notion of a Fake Doors MVP. Although I wasn’t consciously aware of it when I wrote this post, I must have come across it at some point and it undoubtedly inspired some of the ideas in this post.

Another reader suggested calling the pattern described in this post “jungle bells” 🎅🏼.

If you liked this post, you can find a listing of other articles at https://komoroske.com/