Are you path dependent in your product management job?
The choices and decisions made in the past can influence the options and limitations that each product manager faces when developing and managing a product. That's a fact.
So, how should you avoid constraints and keep your mind open to potential pivots?
In this article, I will dive into the concept of path dependence and explore the strategies and techniques that can help product managers make informed decisions that drive product success.
Keep reading for more!
Once Upon a Time…
Before we jump into the risk of path dependence in product management, let's go back to 2010…
HBO is one of the most popular streaming channels, gathering millions of people in front of TVs. Reaching out to their customers, they created a streaming platform - HBO Go - and now everyone can easily catch up on the shows they missed on cable. Yet, it's not very popular as people's hearts are occupied by an old, good cable. So HBO doesn't plan for any crazy bandwidth as it’s made only to watch episodes you missed.
Too good to be true, right?
Well, the great success of the Netflix app doesn’t help - soon, everyone wants in on this streaming service game.
HBO needed to move fast to find the fastest and cheapest way to create an app for itself. You might think they’re lucky as some of it had already been built, right? HBO Go is already up - they only need to make it available to everyone. Teams upgrade the app, and they publish it as HBO Max because it sounds much cooler.
But -
When people start using their streaming service, things go wrong. People on Reddit are even asking themselves and others how somebody could make an app that bad. Articles are written about the terrible quality of the platform, and, most importantly, it crashes as the finale of one of the most popular shows premiers. The attempts made by HBO to improve the app are mostly futile - the tech debt is too big. The decision to repurpose the existing app made it extremely difficult to use and nearly impossible to improve.
What happened?
HBO had become path-dependent as they got stuck with the path they had previously created when building the first app. The time, resources, and cash invested in the app blinded the team, making them path dependent and less inclined to explore other possible pathways moving forward.
But what does it mean for us - product managers?
Path Dependence in Product Development
As we build our products, we make more and more decisions, leading to a lock-in where our past decisions constrain us. They can be based on customer habits, product layout, or technical and infrastructural design. Our decisions enter a process of self-reinforcement - we build metrics, organize the team and coordinate our goals based on them.
We also bring specific ways of working to our teams - making it hard to change how we work. If we always build extensive user story maps and acceptance criteria, people will get used to it and demand it in the future. Next time, when you come up with a business problem instead, it will take a lot of work for the team to adapt. Adapting the team might lead to longer delivery times, and it’s not something you want as a product manager, so you will have to stick to your process of writing documents instead of involving the team and sharing information.
The same thing happens in the development process itself. Sometimes when cutting corners, we take on debt that’s incredibly hard to repay. Working around it leads to longer delivery times and developers’ frustration, but we stick to solutions we built before and try to stitch layers of spaghetti code together.
Simply put - path dependence makes us inefficient - becoming locked in takes away our ability to react to our environment - changing customer needs, technology, or competition. Processes we build get imprinted onto our teams, hindering the basis of the agile approach.
Is there any way out of it?
Tips To Avoid Path Dependence
Based on my experience, I created a list of strategies and techniques that minimize the risk of path dependence limitations.
#1 Avoid making decisions too quickly
Sometimes decisions seem simple, but they may be hard to revert to and have serious implications. It’s worth considering the potential side effects of our decisions. Think about the future and what paths each decision might put you on. Ask your peers for advice and try to understand what will happen a year from now if you make this decision. When facing any increment of effort in Product Management, we tend to take the easy route - saving time and releasing quickly is a double-edged sword - it might put us in a tech debt that will take a lot to pay off. Bring the repayment plan in the picture.
#2 Make your decisions smaller
We learn by making lots of small decisions instead of huge bets. Based on these learnings, we can understand whether the direction we’re moving in is right or wrong. Small decisions are also easier to reverse - letting you change course as you move along with building the product. Try to break apart big products into small increments, validate your assumptions and focus on a short time to market. If you fail, you’re not tied up by having invested months into development. I recommend finding one really painful problem at a time so that even if you don’t solve it perfectly on day 1, you still bring lots of value.
#3 Learn to kill your darlings
Killing your products, no matter how proud of them you are, is a must if they don’t serve the product goals or meet your customer's needs. It helps you stay aligned with the desired outcome and teaches you that there is no sentimentality in the product. Sundowning features are one of the most demanding skills to master in product management, but an incredibly valuable one. Go ahead and cut some weight ✂️
#4 Motivate the team to think about possibilities
The most significant risk with path dependence is in the waterfall approach to software. I’ve seen product managers (including myself) prepare the whole wireframe for a product before coming to the developers and asking them how long it will take to deliver it to production. Thereby, a team works on a feature for months while solving the same customer problem in a simpler way through communications, which could have taken days. In this case, the team has already reached a critical juncture - the product manager has chosen the path single-handedly.
#5 Make change a constant
One of my colleagues tends to hold each retrospective using a different framework - sometimes using Start, Keep, Stop technique, sometimes moving to Rose, Thorn, Bud - this keeps teams constantly stimulated and prepared for change. In my team, we run experiments on teamwork - take on new techniques of working together and checking if it delivers value after a specified time. A mindset that everything is changeable and should change makes it easier to avoid the trap of path dependence. Especially in the product, change is, and should be, constant.
#6 Forget sunk costs
The biggest issue we have when trying to change our path is the amount of time and money we spend on a project. How often does your manager tell you, “We have already spent X; we can’t change our strategy now”? How many times do you think it to yourself? We must remember that throwing money at the fire will only make the fire stronger. When facing difficult decisions, like killing a feature or pivoting, do not think about what you have invested. The only two things that matter are what investment you’re facing now and what return it will bring. Focusing on the future instead of remembering the past will go a long way.
Summary
Now you see that path dependence is an issue that most product teams will experience in one way or another - they come from technical debt, past product decisions that back us into corners, and a lack of foresight in the fast-moving software world. By living and breathing change and effective collaboration, we can minimize its effects and reduce the chance of problems happening in the future.
Do you have any thoughts or experiences on this topic? Feel free to reach out to me via LinkedIn.
