A Proposal Born from the 20% Rule

Have you heard about Google’s 20% rule? At Google, employees are allowed to spend 20% of their working hours on projects outside their usual responsibilities.

Our team adopted a similar culture early on. It is common to hear things like “I’ll try that under the 20% rule” or “Why don’t you tackle it with your 20% time?”

This post describes a case where something born from the 20% rule made its way into the product.

From the 20% rule to discovery

In the service we are building, we recommend products to members on product pages, the home page, and more. Starting around August I used my 20% time to observe the data behind those recommendations.

My motivations were:

As I dug into the data, a few questions emerged, so I shared them with the team.

Someone said, “If we can run an A/B test, why not try it?” That prompted me to examine the data in even more detail to see if we could run experiments.

I found that:

In other words, we had a great candidate for an A/B test.

From discovery to proposal

Based on what I found, I proposed “an A/B test that swaps the order of recommendation slots on the product page.”

Our expectations were:

I also proposed “an A/B test that incorporates information not currently used in the recommendation logic.”

Because we discovered potentially valuable data that the current logic ignores, we expected that using it would make recommendations more accurate and boost click-throughs.

Both experiments ended up being approved, making them examples of 20% time ideas flowing into the product.

Results

The A/B test that reordered the product page slots has already finished. The variant with the reordered slots delivered a higher click-through rate across all recommendation areas on the page.

I was relieved that the proposal produced good results, but I also reflected on the fact that I had not made many suggestions like this before.

We have a BI tool so people outside the development team can view data, but complex queries are often difficult to run there.

For example, log data is huge and raises performance concerns, so BI tools have limitations. Likewise, only the product development team can usually access the internal logic of the service or the state of the infrastructure.

From this experience I learned that, even when only the development team has full access to the data, having a “user-first” and “quality improvement” mindset while observing the data can reveal insights that are invisible when you only focus on building features. Those insights and questions can lead to meaningful outcomes.

Closing thoughts

This was a story about how our 20% rule culture led to a proposal and ultimately a product change.

More often than not, the 20% rule ends with “I tried something I was curious about but it didn’t pan out.” That informality is the whole point: it fosters a culture where “I want to explore this because I’m interested” is respected. Having an environment that makes that possible is a real privilege, and this experience reminded me of its value.