HTTyPo
There's a typo that runs the Internet.
In 1996, the Computer Scientist Phillip Hamam Barker and Roy Fieldings released RFC1945, which proposed a new header field in the HTTP Protocol. The new field called referer — a misspelling of the word referrer — allowed "the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained". A great addition to the protocol, but ter-ible spelling 😛
75 years later, on every website request that is made, there is now a referer header. Barker later joked that he was trying to get the Oxford English dictionary to adjust their spelling..."since my spelling is used several billion times a minute more than theirs"
SQL queries have been written, databases have been designed, bugs have been introduced...because of how Barker and Fieldings spelled this word.
"In this great future, you can't forget your past"
Developing products is inherently path dependent. History matters. Every product decision you've made determines every product decision you're going to make in the future.
Product-Market Fit is where that initial path is set. It is Decision A. At that point, you could've head in any direction. You could turn around quickly, and head in another direction. But the further you go down a particular trail, the further you have to backtrack. The more people you convince to join you on the trail, the more you have to explain why everyone needs to turn around.
I've found that thinking about your product path dependency is a helpful framework for understanding why your product is the way it is, and how to shape its future. It helps clarify why parts of your product — the product you are building! — stink and are so hard to fix. It clarifies which decisions matter and which do not.
And it helps you understand how and when you can change that path.
Exploring Some Paths
Let's explore a few examples of Product Path Dependency at play...
SMTP Protocol
Most email clients don't let you retract an email once it's been sent. You also can't edit a sent email. Most email clients — from Superhuman to HEY to Gmail — are built on the assumption that a sent email is a sent email.
Products have gotten creative to work around this assumption. Superhuman adds a 10 second wait period to allow you to unsend. If both sender and recipient are using Microsoft Exchange, an email can be "recalled".
But an early decision in 1982 is largely still dictating how much of the world digitally communicates.
Slack is a great example of what can happen when new entrants aren't burdened by past decisions. Rather than using SMTP, slack uses Websockets. When you send a message, the recipients see the message almost immediately. And you can edit, delete, pin and share the messages you're sending.
Once you've used Slack, you wonder why email was so static and immutable. It revisited an assumption, and made it painfully visible.
Instagram
There's been a lot of shade thrown at Instagram for attempting to clone hit features like Stories (Snapchat) and Reels (TikTok). Occasionally these clones will work, in the case of Stories, but most of the time they flop. From NYTimes Tech Reporter Taylor Lorenz:
Instagram started as a simple photo sharing app. Snap photo, add filter, share with friends. Now put yourself in the shoes of the PM responsible for shipping Reels. You're trying to figure out how to fit Reels in alongside Stories, IGTV, Shop, Well-Being Guides, DMs for Brands, Influencers, Advertisers, and a user base in every country around the world.
What to do about product path dependence?
Path dependency is inherent to product development. It is a badge of successfully building something that people want, and an organization that can support it. So if we can't avoid it, what can we do about it?
Early Decisions are Disproportionately Important
There is a paradox of early product decision-making. Early decisions are disproportionately important in that all future decisions will rely on it. Yet they are also the ones that need to be made the fastest and given the least consideration. "Try it out and see what sticks." Until it sticks, and then you are left with that decision for a very long time.
I think there's a way to resolve this tension by making decisions that preserve future optionality. It's somewhat of a hack to avoid making a decision that you will have to unwind in the future.
Let's take a user data model as a simple example. When you have no users, designing your data model is easy. You can change on the fly. As you build more features — like your sign up flow — they are built around the assumptions you made in designing your user model. Are you going to collect birthday? Are you going to ask them to use a company email address? Can they invite friends? As you build upon these early product assumptions, they become harder and riskier to change.
Designing for optionality may take slightly more time, but thinking through some potential options you might want down the line can reduce your path dependence.
Will Users be part of an Account?
Will Users need to be Linked via a social graph?
Will Users need to have multiple Plans?
An option-preserving decision early on can save you months or years of migration work down the line.
Competitors are forging their own paths
Competitors are on a path as well, but it's different from yours. By understanding your competitors path, you can understand what they might do in the future, and what they aren't able to do given their prior decisions. A company geared at large enterprises has likely built a sales team that will be reluctant to lower prices to sell to startups. A company designed to run on-prem will have quarters/years to migrate to the cloud.
New entrants are unburdened by decisions of the the past and can move much faster in many more directions. Every so often, revisit the assumptions and "path" that you are on. If you were to start all over again, how might your product and the org look different? Migrations and re-writes can be painful, but better to do so early than to continue to building on a crumbling foundation.
PMs are the "Product Historians"
PMs can play an important role in understanding the market, organizational, and technology constraints that of the past, that led to the product today. In doing so, you'll be able to revisit past assumptions, avoid making the same mistakes, and build the trust of your team and customers. It's easy to fall into the trap that those who came before made bad decisions. Rarely is that the case. They made the best decision they could with the data and assumptions they were working off of.
By putting yourself in the shoes of those that came before — and really understanding the context — you can make even better decisions going forward.