What I Learnt in 2020

Here's a list of things that I learnt over the last 1 year all of which has had a profound impact on my thought process.

Relationships matter 

This is one of those things that’s there in every leadership book and honestly who would disagree with this? Inadvertently, I’ve been an individual contributor for most of my life and therefore have never had the opportunity to think deeply about the importance of relationships and the dynamics of a team. 

However, this year I feel like I’ve finally understood WHY relationships matter. Apart from the fact that nobody likes working with a douchebag, relationships matter because it creates a clear distinction between the problem-at-hand and the person. 

Nobody likes to receive negative feedback on their work after slogging for 18 hrs straight. But when you have a strong relationship, it’s very clear to the person that what everyone is striving towards is perfection - the feedback is not about personal competence but more about solving the problem in a better way. As simple as this sounds, I believe that achieving this level of team dynamic is the difference between great teams building fantastic products and mediocre teams. Mediocre teams never provide critical feedback assuming it would offend colleagues and this shows in the product. 

And of course it works both ways, only if you have a good relationship can you expect good (and critical) feedback to consistently reach you. Excellence doesn’t come for free - it requires literal blood, sweat and tears and it’s the dynamic you have with people that ensures that this excellence is consistently achieved at the right velocity without collateral damage. 

tl;dr - Great Relationships = Great Feedback Loops = Great Products  

First Principles 

I’ve always known about the power of reasoning by first principles, however this year it’s been abundantly clear that First Principles (FP) thinking is the only effective way to solve problems at a foundational level. Fundamentally, this involves breaking down or distilling a problem into its building blocks/truths/axioms/first principles and then reasoning upwards from there to find a good solution. I won’t go into details here about the What and Why of First principles thinking as both Farman Street and Wait But Why have done a fantastic job of explaining it. However, I’ll add two points that I’ve learnt while putting it into practice: 

1. Breaking down requires depth:

The breaking down phase requires an extremely thorough understanding of both the problem and the domain. Without depth here it’s very difficult to differentiate the signal from the noise and peel away the levels of abstractions. We have multiple biases at play that force us to skip the problem and jump to the solution, which make this stage quite difficult. I’ve written about this here. 

2. FP thinking may not be relevant for all types of problems

This type of thinking is both time consuming and requires a lot of mental energy. Therefore applying FP thinking to all problems that come by you might not be an effective strategy. A better idea would be to classify your problems into two categories (i) problems you want to solve (ii) problems you want to get rid off for now. The get-rid-off problems are lower priority and probably not worth spending a considerable amount of time on. The want-to-solve ones are problems that can give exponential returns if solved and therefore worth the time and energy of FP thinking. 

I’m not completely convinced on point (ii) yet. I believe that mental models also come into the picture for the get-rid-off type problems, but I’ll keep that for another blog. 

tl;dr - To solve a problem effectively break it down to its fundamental principles and reason upwards 

Art + science

I’ve written a bit about this in the past. In Summary - 

There’s a human user behind some/all stage(s) of a products life cycle. Numbers can never accurately capture human empathy and therefore being 100% data driven in product development is a fatal flaw. What’s equally important is to develop an intuition or rigour for what really solves a users pain point and use that to guide you.

In addition to this one more point I've learnt is that there has to be an equal balance between an art-like approach (intuition) and a science-like approach (data-driven) . However what I’ve seen is that when ever numbers are involved we involuntarily try to hyper-optimise and forget about the essence of WHY those numbers were created in the first place. Whenever we put numbers it’s always important to understand that it’s a proxy for something else.

Here’s an example: Learning is important for childhood development. But an important questions to answer is - “How do we know if a child has learnt a concept in school?” To address this we decided to hold exams and use scores as a way to measure that. Over time this resulted in hyper-optimization for scores, ultimately resulting in rote memorisation & shallow learning all across schools. It looks like we’ve forgotten why exam scores were actually brought in and what the ultimate goal was. 

tl;dr - Good Product Development = Art (intuition-driven) + Science (data-driven)

Simple is Hard 

I believe people take it for granted how difficult it is to implement simplicity in products. Simplicity requires ruthless prioritisation and a deep understanding of your users. It’s important to understand that people “hire your product” to get a job done (JTBD framework) and honestly, its much easier to say “Lets just put a setting for that and let the users decide”. 

However, every time your user encounters a decision point (settings, entries, selections etc) it requires mental effort and makes it fractionally more cumbersome to use the product. A product’s early adopters would not care too much about simplicity since the problem that the product is solving is likely 10x more painful. Therefore these users will power through the difficulty of using the product. But if the product has to cross-the-chasm and reach the vast majority, simplicity is a must have. 

Steve Jobs was without doubt the master of simplicity. In Insanely Simple, Ken Segall points out how Jobs used to hit people with a “simple stick” every time someone made things needlessly complicated. One of my goals in 2021 is to spend time learning the art of creating good abstractions. If a technology or process is inherently complicated that does not mean that you need to expose your users to that complexity. A good abstraction provides the powerful functionality and yet beautifully hides the complexity. Kind of like this:

tl;dr - Building simple products requires you to take on the burden of thinking for your users. 

T shaped vs H shaped 

Over the last year we’ve been expanding our product team at Yellow Messenger owing to which I’ve had the fantastic opportunity to talk to a lot of interested people. Most of our teams are in the foundational stages and aiming to grow fast which inadvertently means that our team members generally have a mix of 2-3 areas that they are simultaneously good at. For eg: Our product team has individuals who along with having good sense of product thinking also have some combination of ML, UX, web dev, sales and marketing, operations etc skillsets. This means that while we look for people to join the team we are always looking for people who are good at the intersection of two skills with one of them being Product Thinking. (Product + X + Y where X,Y = some permutations of AI, Data Science, Analytics, Marketing, Growth etc)

I believe this can be generalised to most product teams at startups who have recently raised a Series A/B round (or earlier). The reason is because the job roles at these startups have not yet evolved to warrant specialisation and therefore would prefer to hire people who are good at product + X + Y simultaneously. So if your goal is to work at an early-stage startup, position yourself as an H-shaped individual who has decent amount of depth in 2 or more fields at the same time instead of just being T-shaped (depth in 1) .

tl;dr - If you want to work at an early stage startup its useful to position yourself at the intersection of 2-3 areas.

Choose Upstream Problems 

This year I realised the importance of prioritisation and the classification of problems especially while working at a startup in hyper growth mode. The reason to do so is to identify foundational problems or “upstream” problems (from Dan Heath’s book by the same name) which when solved yield exponential return-on-investments. In “Thinking in Systems”, this goes by the name of “leverage points” - areas of the system which when changed allows you to efficiently change the characteristics of the system. 

In my experience the biggest challenge in attempting to solve upstream problems is actually in identifying them. This is because most of the problems that you’d probably see around you on a daily basis are second or third order effects of the root cause. I won’t go into much detail here as Dan Heath’s book has very nice elaborated on the concept. I’ve also written a little bit on how we unknowingly solved an upstream problem at YM here. 

tl;dr - Identifying upstream problems helps you build non-linear solutions (1 solution solving multiple things)

If you made it till here, thanks for reading and do let me know your thoughts! Hope you have a fantastic year ahead filled with growth and learning.