The anti-pattern I’d like to explore today is what I affectionally call the head of problemaka senior’itis. In my experience, this is the factor in org design that increases burn and bureaucracy. This anti-pattern is lethal for companies.
It starts off quite innocently. Let’s assume you are the CEO at the early stages of a company and you have identified a problem to solve, say in the general area of customer support. Customer support as a function doesn’t exist yet. You ask around your peer group, you look at successful companies and then you make the common mistake – you get afflicted by senior’itis. You decide that you need somebody senior to run that function, you need somebody who has done it before somebody with pedigree. You need a Head of customer support. You then spend a lot of time trying to woo the right candidate, the one that checks all the boxes. You hire him after a long drawn out courtship. You are happy, your customer support problem will be solved, you have found the right person. You have hired a person who will take accountability to solve the problem.
The anti-pattern I’d like to explore today is the Ponzi roadmap. It usually starts with the best of intentions but has extremely harmful effects as a company scales.
When a company is in the initial stages and has a small engineering and product team the planning model that emerges is what I call the pooled model. Engineering is considered a pool of resources and usually composed of full-stack engineers. The product is typically small and mostly a monolith, every engineer can work on anything and there are just a few PM’s (maybe just one). Since we are all agile, every quarter the PM comes up with a list of priorities and outcomes, engineering staffs the priority from its pool of engineers and delivers outcomes. The next quarter rolls around and we do this all over again. Engineers move on to working on different things every quarter. This makes perfect sense in a small company – but goes horribly wrong as you start scaling up.
Nothing is more responsible for the good old days than a bad memory – Franklin Pierce Adams
We’ve all read about how culture eats strategy for lunch. The internet is jam-packed with a million blog posts on the superficialities of culture. Its time for some inside baseball with some actual actionable things to watch out for and prevent.
It is absolutely true that the culture of the company dictates how it can adapt to change and eventually succeed. Culture is hugely important, however along the journey from a small company to a midsize company to a large public company, the culture will change. At all these stages, different parts of the company will have different cultures and norms. In fact sometimes within the same team, you will have differences based on where the teams are located and their size.
It’s been 10 years since the 2008 financial crisis. Astute observers will correct me and point out that the crisis actually started in early 2007 when the Bear Stearns High-Grade Structured Credit collapsed. This was the first collapse of a hedge fund that was loaded up to the gills with subprime CDO’s. If you were following FT Alphaville in late 2006/ early 2007, you’d be ahead of the game. The signs were there! Some great coverage to relive and re-read
So how does this relate to you, young product manager? Some obvious and simple lessons articulated below.Read More »
I just finished reading the book Thinking in bets by Annie Duke. I highly recommend this book if you want to understand how to make better decisions. She talks about this amazing concept called resulting that blew my mind. In her own words
…was a victim of our tendency to equate the quality of a decision with the quality of its outcome. Poker players have a word for this: “resulting.” When I started playing poker, more experienced players warned me about the dangers of resulting, cautioning me to resist the temptation to change my strategy just because a few hands didn’t turn out well in the short run.
Human beings crave certainty and in the world of product management it translates to “estimates of value”. Product managers have to make tradeoffs regularly on what initiates to work out next. At a certain stage of the company the need for “formal estimates of the value of doing X” will kick in, otherwise, how do you know to work on X or Y? There will be an overwhelming desire to quantify everything to the nth detail before deciding what to do next. We all know the dangers of that – If you torture excel enough you will get the answer you want. Use of a complicated bottom-up model in the early stages of a product’s evolution is a huge warning sign for me.
A thought experiment on the sort of fintech experiences and products we’d want as consumers in the distant (or near) future. The thought process is structured as a conversation between an older father and an adult son. Italics is the dad.
So son, hows your financial life going? Everything under control?