Hidden Layers in Product Management
Hidden Layers in Product Management
How to excel in an ill-structured domain
👋 Hey, Deepak here! Welcome to another post of the Growth Catalyst Newsletter.
For the new ones here — 9,000+ smart, curious folks have subscribed to the growth catalyst newsletter so far. Receive the newsletter in your email by subscribing 👇
You can read 50+ posts from the past here - https://www.growth-catalyst.in/archive
Excelling in product management requires years of building products, learning, and unlearning. And even then, many people on the way get confused around the question, “how do I excel in this domain which doesn’t have any set templates?”
You will often hear differing opinions based on people’s experiences. Few people I know actually left the PM profession in search of something structured.
So in this post, we are going to cover how to excel in an ill-structured domain like product management.
To tackle the question, we need to start elsewhere — neural networks and deep learning!
Neural Networks and Deep Learning
If you have some interest in AI/ML, you may have come across deep learning.
To understand deep learning, we have to first understand neural networks. Neural networks are inspired by the way the human brain works, hence the name. The goal of building neural networks is so that computers can perform the same tasks of vision, speech, calculations, etc. that humans can do.
A simple neural network has 3 layers — input layer, hidden layer, output layer.
We can understand the layers better from an example. Suppose we want to build a neural network to predict house prices in Bengaluru, India. Which factors will affect the price of the house? We can list few key factors:
Square footage
Bedrooms
Distance to prime location
Age of the house
These input factors make up the input layer. Let’s say we provide the input for a house - 1200 square ft, 2 BHK, 3 km, 10 years)
The neural network would spit out a price for the inputs provided. That makes up the output layer. So what happens in the hidden layer? Hidden layer performs calculations.
The term "hidden" is used because the calculations that take place within the hidden layer are not directly visible or interpretable from the input or output layers. In this sense, the hidden layer represents a "black box" that contains information that is hidden from view.
How Hidden Layer Gets Built
The hidden layer is built by training the neural network. The training process takes Square footage, Bedrooms, Distance to prime location, Age of the house along with prices (output) for 1000s of houses in Bangalore and feed it to the neural network. The training data would look something like this.
By going through this data, the neural network has to figure out the pricing formula. It assigns numerical weights to different factors. Like you can see in the first two rows of the data above and say that distance to prime location is a major factor. So it will have a higher weight. The whole things look something like this, and Y (price in this case) comes out as an output.
Now it’s easy to understand how the pricing gets calculated with a single hidden layer like the one above. But deep learning (think of it like advanced neural networks) has multiple hidden layers. With multiple hidden layers, it becomes difficult to explain how the model arrives at certain conclusion.
In other words, even if we know the mathematical weights in different layers, explaining output truly becomes a hidden layer or "black box".
But why are we discussing weights and deep learning in the context of product management? Given that it represents how brain works at a high level, it can serve as a powerful analogy to understanding any area our brain can master.
Where the Analogy is Helpful
The analogy is pretty powerful in an ill-structured domain like product management.
The analogy isn’t that helpful in areas which are more structured and objective in nature like mathematics. We can see the logical steps and where we go wrong. That helps us in gauging our learnings in mathematics pretty accurately. In other words, we know the concepts in mathematics and they apply in a pretty formulaic way. The hidden layer isn’t actually hidden when it comes to mathematics.
The Domain of Product Management
Product management is an ill-structured domain. Ill-structured domains have concepts, but the ways in which concepts apply are highly variable.
As a result, experts in ill-structured domains have to deal with constant novelty, where every problem is unlike previous cases that the expert has seen. Medicine, design, product, business strategy, etc. are some of the ill-structured domain.
And since how concepts apply isn’t crystal clear in a PM domain, it is harder to get trained at (pun intended). So PM domain has the hidden layers which are hidden even for people who are good at it because they find it hard to deconstruct and articulate how they arrived on a conclusion.
For example, let’s look at same inputs and how the hidden layer can make all the different in what to build. When a new PM hears a customer saying they want to order only healthy food, they can go on and think about a feature/filter.
Compare this what the response of a good PM will look like.
This isn’t true about well-structured domains like mathematics. We can see the logical steps in a maths problem and where we go wrong. That helps us in gauging our learnings in mathematics pretty accurately. In other words, we know the concepts in mathematics and they apply in a pretty formulaic way.
Before we move to understand how to create effective hidden layers in PM, we need to break a myth or two.
The side-effect of the hidden layers is many PMs believe product management is more art than science. Anything we can’t decipher and find a straight line often is considered art. Poetry, painting, etc. are some examples. Why did Michelangelo draw the Cistine chapel ceiling the way he did? It’s pretty hard to answer.
So if we had to define art - art implies a personal, unanalyzable creative power. But most decisions in product management are analyzable, and two people with same level of understanding would even arrive on the same decisions after studying the constraints. So by that definition, it’s not mostly an art. Certain aspects or moments in this field can be considered art. But so is true about any scientific invention, or even programming.
Hidden Layers in Product Management
So what do we do to improve the hidden layers given that we don’t have a formulaic way of doing so?
It turns out it is a two-step process. The first step is learning the concepts and frameworks well. Some of these concepts and frameworks are widely available like user persona mapping, doing customer research, breaking a feature into stories, etc.
But since PM is a new and evolving field, many of the concepts/frameworks haven’t been articulated widely yet. So you get to learn them from blogs/books/courses by experts. Most of the blogs/books/courses which are good in this respect come from strong operators with many years of experience in product management like Lenny Rachitsky, Casey Winters, etc. You don’t get to learn them in widely available interview preparation courses.
By learning these concepts and frameworks, you can become a decent PM. But to be good or excellent, you have to go beyond frameworks and focus on step 2.
The second step is the training that happens through feedback. The more nuanced and detailed this feedback is, the faster your brain learns an unstructured domain. In neural networks, this feedback comes in the form of loss function which calculates how far the predicted price is from the actual prices. In PM, the feedback helps you correct the weights in the hidden layers of PM.
So what are the sources of feedback, and what type of feedback is useful? We will cover this in the next section.
Building Better Feedback Loops
Most of the times in a work environment, our brains know whether the decision is correct or not based on feedback from a colleague or a supervisor. To adjust the weights faster though, we need to understand why. And the more nuanced and accurate this why is, the faster the learning happens.
A good feedback can look like this, “You should focus on doing the customer research the right way. I saw some leading questions in your research script. It also missed some questions around this new feature we have launched. You need to read this book/blog that helps you understand how to avoid leading questions. You also need to double-check your documents, provided that’s why you missed the new feature.” The italic part talks about what is wrong. What follows talks about why. Understanding why can be a back and forth conversation.
A bad feedback looks like this, “The team isn’t happy with the progress on research. You should work on it”
So how do you get feedback to learn? Here are the ways:
Real-life products: Shipping real-life products, in your main job or on the side, teaches you a lot about real-life challenges and provides very nuanced feedback. This is provided you consciously create the feedback loop by building hypotheses, talking to users, analysing the success/failure of a feature, etc.
Merely shipping products faster isn’t going to cut it. Understanding why and expanding your mental models is vital.
Managers/seniors at work: Managers and seniors at work can provide a lot of useful, nuanced, real-time feedback because they have the most context of your work. What you have to be careful though is whether the feedback (both what and why) is accurate. In many cases, the wrong feedback causes harm. Peers usually have the same understanding as yours, so they won’t be that useful here.
Books written by operators: A book written by late Andy Grove, ex-CEO of Intel, on ‘high output management’ is much more valuable in understanding what and why than management books by management gurus who don’t have the domain experience.
Actionable/rigorous courses: Courses come in all shapes and sizes. Some are run by people who have been there, done that. Others are run by people who are good at learning concepts and then sharing it with people. Avoid the latter and always focus on the former.
Look at the what the instructor has done in the past, their specific experiences in building products and how that ties to what they are teaching. For example, execution isn’t my strongest suite, so I avoid teaching about execution and put out as the disclaimer in my courses.
Look at the courses below and answer me which would you take as a product manager
Case studies: Detailed case studies, like Matthew Ball essays around Netflix, help in understanding why a company or product took certain decisions and implications of it.
Here is a list of things that don’t help in learning.
Reading news/ superficial articles: If you have read news around product and startups long enough, you would realise that they don’t add much value in isolation. It’s just a bunch of numbers and information, forced to fit a narrative. Though it may be useful for those keeping a general watch on industry, it doesn’t sharpen your hidden layer of PM.
The same is true about superficial articles that keep pushing generalisation like why something did or didn’t work without proof or data. I would even suggest you to start avoiding these because they are akin to junk food. You feel like you are getting energy out of it, but in the long run they make you unhealthy and corrupt your model.
Learning concepts without nuances/application: I have met enough PMs who believe they know something when they don’t. The belief primarily comes from a course they have done or a book/article they have read. To quote Feynman, “There is a difference in knowing something, and knowing the name of something”.
Unless you have applied what you learnt in a course in real life, it’s very hard to really know that. The tragedy of our domain is that most of the courses start and end with concepts and frameworks. The bigger tragedy is sometimes they wrap dummy hypothetical projects with no real feedback to give you confidence that you have actually mastered it.
Can the projects be better? They can be if they imitate the real-life ones with data, research, decision-making, someone challenging your decision, etc.
To summarise it all, feedback is essential to learn in an ill-structured domain like product management. To start with, you have to know how to separate good (nuanced, explains why, and accurate) from a bad one.
Hope this post helps you in orienting how to learn Product Management. Do let me know how you found it and share your thoughts in the comment section :)
Well written, reminded me of Tim Urban's way of writing, I could understand most part of content, just by looking at the images.