Avoid Failure: Know Your Hypotheses
27 January, 2021

Michael Smith
VP of Innovation at Omnipresent
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
13 October
A high performance team refers to “ a group of goal-focused individuals with specialized expertise and complementary skills who collaborate, innovate and produce consistently superior results.”

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan
2 August
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
12 July
Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Vineet Puranik
Senior Engineering Manager at DocuSign
1 July
Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Saikrishna Desaraju
Engineering Manager at Deliveroo