Chesterton's Fence

When a new person joins the team, people love to welcome their “fresh eyes” that can “spot the nonsensical things we’ve grown blind to.” People quickly discount their earned wisdom by casting experience as a burden. Although the new joiner may appreciate this welcome, I’ve yet to see the pithy sentiment come true.

Don’t get me wrong: every team needs fresh minds and diversity of tenure to ensure workers don’t get stuck in a rut. However, new product managers could benefit from getting to know the lay of the land before they push for change. Unexamined product decisions can destroy a business.

The One-Way Door

Product decisions are two-way or one-way doors. Most decisions are two-way—you can step through the door and back out with minimal consequences. Changing the format of a team meeting is easily reversible. Running an experiment is low stakes: if it fails, return to business as usual or launch a new one. PMs shouldn’t waste time on two-way doors and bias for action over deliberation.

One-way doors are tough to change once decided. A one-way door requires a lot of thought, research, and debate to be successful—such as infrastructure choices or multi-year business plans. PMs should bias for thoughtfulness over action when the stakes are high.

Sometimes, the rationale for past decisions may be uncertain, like legacy software dependencies. In these scenarios, people may refuse to touch them or adopt the risk-seeking mindset of “turn it off and see who screams.” Neither approach is wise—the former is too passive, and the latter hyperactive. Instead, we must approach unknowns with the methodical opening of a one-way door.

Chesterton’s Fence

Philosopher and apologist G.K. Chesterton described a thoughtful approach to policy reform in his 1929 book, The Thing. Chesterton’s principle advised against reform until decision-makers understood the rationale that created the present state. Put simply: If a fence exists, there’s likely a reason for it.

All sorts of “fences” abound in software. Technology rapidly changes, new frameworks emerge, and people switch roles, so the knowledge of critical legacy systems gets lost in the shuffle. The product may seem littered with unintuitive features when a new person joins the team.

While it’s tempting to strip away counterintuition, restraint is essential. According to Chesterton, we should not remove a fence until we know why it exists in the first place. A guillotined head can’t be glued back on.

A new product manager should remain humble when beginning a new role. It’s tempting to scoff at the “ridiculousness” of an incumbent feature, but until we learn about its history, we can’t know if the feature is ridiculous.

Learn why past product decisions were made by talking to several functions and stakeholders—especially those with years of tenure.

Second-Order Consequences

We approach a fence. After asking around and conducting internal research, we understand that it kept cattle from running onto a busy road. Given this rationale, we can respect and appreciate the prior decision, but we believe it’s now vestigial. We must step over it every day, and it’s hard to mow around, so long grass grows along it, and neighbors complain that it looks unkempt.

Since a highway was built, the road now experiences little traffic, and fewer cows live on the property now than years ago. So, we want to rip down the fence.

Learning history is the first step in removing Chesterton’s fence, but it’s insufficient. Destroying a fence may have second-order consequences.

Last summer, I helped a friend remodel his basement. He wanted to knock down a wall to create a more open floor plan, but as we removed drywall, we discovered a support beam directly beneath his kitchen’s refrigerator. Thankfully, we lowered the sledgehammers, or I might not be writing this.

Second-order consequences are what happens when we remove that support beam. Yes, we’ll achieve our first-order objective of an open floorplan, but we might experience a second-order consequence of an open ceiling.

To deprecate part of a product, we need to consider the long-term effects of that decision.

Imagine you want to increase the daily active users of a marketplace app. Removing CAPTCHA from login could simplify the sign-in experience and increase user engagement. But, when the service becomes flooded with bot traffic, the quality erodes, legitimate users lose trust, and they stop using it altogether, sabotaging the initiative’s very purpose.

A strong product is built with intention and careful decision-making.