Learn things that don't scale!

Have you ever felt a sudden burst of joy when you enter a restaurant which has the perfect lighting, sound, temperature and seating space for the occasion you went in there for?

In such a moment, overwhelmed by the suddenness of this joy, I find myself searching for all the reasons why I am feeling good (despite my wife’s constant reminders to ‘stay in the moment’).

A great restaurant experience is never an accident. It is always a well thought out and well-executed plan of creating a beautiful customer experience.

Airbnb, a new giant in the hospitality industry, painstakingly went about creating the perfect experience for their customers. In an interview with Linkedin co-founder Reid Hoffman,  Brian Chesky, the Airbnb CEO talks about how they designed an 11-star customer experience. Brian says “In order to scale, you have to first do things that don’t scale at all.”

The counter-intuitive concept of ‘doing things that don’t scale’ was first introduced by Paul Graham, co-founder of Y-Combinator in this seminal blog post. He argues that launching a new startup requires a series of unscalable activities. He says:

“The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars. Instead we should try thinking of them as pairs of what you're going to build, plus the unscalable thing(s) you're going to do initially to get the company going.”

Founders have to fight with their own inertia in doing non-scalable things as they are looking to build a scalable machine and every non-scaleable component added in their company is slowing them down from that ultimate goal. 

Product Managers (who join a late-stage startup) find themselves in a different kind of trap while dealing with non-scalable effort. I would like to call it “The Scalable Skills Trap”.

The Scalable Skills Trap

Overwhelmed with the choice of things to learn, professionals select what to learn based on its future usability. 

This trap may apply to any knowledge worker, but I would like to take the example of how it manifests itself in Product Management. 

A few years back, I found myself in the scalable skills trap. I started my career in Product Management in an e-commerce company. Excited about this new role (“mini CEO” anyone?), I spent a lot of time reading various books on Product Management. I scoured through the internet to find all possible articles, blog posts, videos, etc on Product Management. I quickly embraced the widely accepted wisdom on Product Management (customer first, business-UX-engineering intersection, lean methodology, etc). 

While it was really good that I spent this time reading and learning about Product Management, I failed to recognize that each of the authors who wrote this content on Product Management had simplified and generalized their complex experiences to make it readable for a wide audience. This made me incorrectly assume what Product Management ‘ought’ to be. I unconsciously believed that managing a product required me to strictly follow a simple framework repeatedly. 

This incomplete view of Product Management limited my ability to be a great Product Manager. One of my first assignments was to add new capabilities in the Warehouse Management System. The problem statement required me to spend a lot of time in the warehouse and read a lot about warehouse management. This was my first encounter with the Scalable Skills Trap as a Product Manager. While I visited the warehouse a few times and read just enough about warehouse management to do a “good enough” job, I completely missed out on the opportunity to do a “great” job. 

Learn Non-Scalable things and build great products

To understand this Scalable Skills Trap, let’s go back to the restaurant example that I talked about in the beginning. Let’s imagine a scenario where you, a Product Manager of a high growth food delivery company, is asked to set up a chain of restaurants. 

In order to offer an amazing restaurant experience, the Product Manager would have to figure out the following (and many other things):

• Location - Based on customer demand, rental costs, labor supply, size of the unit, parking space, etc
• Food - Cuisine, pricing, 
• Ambiance - Concept and branding, seating layout, lighting (the warmth of colour, number, and distribution of fixtures), sound (speakers and their distribution, the genre of music), menu card, cutlery, etc
• Backend operations - Kitchen equipment, Raw material supply chain, Payment (POS) and Accounting systems, 
• People operations - Chefs, sous chefs, waiters, managers, etc
• Permits and licenses
• Marketing - Social media pages, website, Food app listings, Google listings, etc

For a Product Manager to successfully execute the launch of a new restaurant, they would need to go into the minutest details of each element of restaurant design. They might have to context-switch between reading up regulations on fire permit and selecting serving spoons. 

But where is the time?

Deadlines are the biggest enemies/motivators of a Product Manager. With time being a finite resource, how can one learn everything relevant to the problem at hand? 

The answer to this, like everything else in Product Management, is Prioritisation. As a Product Manager you would need to prioritize the following:

1. What should one learn?
2. How much should one learn?

The answers to these questions are highly contextual. You would need to ascertain the most important aspects of your product and the impact your learning (or not learning) has on the quality of the product. You would also need to rely heavily on your teammates (within and outside Product Management function) and their skill sets and spend time learning complementary skills. 

Are non-scalable skills really non-scalable?

The biggest skill of a Product Manager is taking a new unknown problem and solving it in the best possible manner with the given resources. As you grow as a Product Manager, you would encounter increasingly complex problems which would need to be addressed faster than before. To manage this, you would end up creating mental models which help you arrive at decisions fast. 

We are all building on top of our mental models, explicitly or implicitly. Every time we learn a new thing and use that to solve a problem, we add another brick (or muscle, if you may) on to our mental model. It may not be apparent when we are working on the problem. But as time passes, and we have time to reflect on what we did, we can visibly see an improvement in our ability to solve new problems.

The experience of working on the warehouse management system in that eCommerce company has helped me greatly in managing various process-heavy problem statements.

Learn things that don’t scale. Experiences have a serendipitous way of coming around.