Avoid Failure: Know Your Hypotheses

Problem

For Project 1, we were on our 4th UI refresh of the social media app, without rigorously testing it with the market. We felt sure that this new design was better than before. The CEO, who was an ex-designer, kept churning through new designs and we were coding but not shipping.

In Project 2, working this time as an engineer, we felt sure that redesigning this component would greatly speed up the system and get us more users. After a huge redesign and cost, we got exactly zero more users.

For a digital cinema compression and projection system - Project 3 - the technology was superior but the system did not fit into the users' workflow. A technologically inferior product was adopted by the market, and our products were mothballed.

I lived through each of the instances above as an engineer, all of which had product or project management. Each project ended in failure. The hypotheses that "we felt sure" about were not data-driven.

These failures led me to one of my major learnings that I took to heart as a product manager: understand the hypotheses you make about your product and test them.

Actions taken

As a product manager, I attempt to understand the assumptions on all projects, so we don't trip over them. Do we truly understand the users' desires for the app without talking to them? Is responsiveness useful to users, and have we measured the performance and its impact on usability? Are fantastic quality and compression ratios the most important, when the users' workflow affect their adoption even more?

As a PM, ask those questions that might be blind spots that could trip up the product. Always understand what's driving what you're building and the data that underpins your plan. What assumptions are you making that impact the user and business? It's very common for group-think and biases to action to create unspoken assumptions - basically unproven hypotheses - and these can sink your projects after you've already sunk time and money into them.

Lessons learned

As a PM, you should be able to say "we're implementing this because we got this data from talking to users and it looks like our hypothesis is true". Do you have enough data to believe that underlying hypothesis? Do you need to put more discovery or testing in your plan before implementation (a little goes a long way)? An early conversation in the project is low risk and low controversy yet is highly effective and definitely less costly than missing an incorrect assumption. Asking for complete certainty for a project is prohibitive, but double-checking your fundamental assumptions before major development will give the feature much higher odds of achieving the expected outcomes.