Four types of failure you can (and should) avoid
It’s always uncomfortable to write about failure. Even though company slogans announce that you should “take risks” and “fail fast”, actually doing the failing, not just talking about it’s merits, completely sucks.
While failure is a great teacher, you shouldn’t have to fail yourself to learn from the mistakes. There should be a set of questions that you can use to minimize the risk of failure.
To that end, I’ve identified the ways that I’ve failed as a product manager and grouped them neatly into four buckets. In this article, I’ll give an example of a personal fail for each of the buckets (as an act of pure personal torture) and share questions that you can ask yourself in order to avoid these types of failures yourself.
#1 Failure of communication
I’ve had dozens of communication fails, but the one that stands out the most underlines how important communication becomes when unexpected things happen. This applies even when the unexpected thing should be relatively benign, like boba.
The story begins when we were migrating a site domain from one url to another. It was technically non-trivial, and required that the site be down for at least 2 hours. The support team crafted a beautiful email letting our users know exactly when to expect this. And I told our engineering team when it needed to be done.
But then, boba happened. More specifically, our engineering team decided to get boba, as they are want to do, and I did not say, as I should have, “Hey, the site migration is scheduled to start in a few minutes. How about we get boba after we finish this important task that we’ve told our users we would be doing at a specific time?”
To make matters worse, I did not tell the support team that the migration might actually happen a bit later than we originally planned. The result was that the stated time that the site would be down and the actual time did not match up, which was a bad experience for our users.
This is all very embarrassing and clearly the question you should ask yourself to avoid this situation is: Is this a good time to get boba? Just kidding.
To minimize failure of communication, ask: Have I told everyone who might possibly need or want to know that this situation is happening, changing, or in the works?
#2 Failure of context
This is either a story about how understanding the full ecosystem of a product can change a decision matrix, or a warning about being drawn to new and shinny things. I’ll let you decide.
It was one of my very first product decisions as a bonafide product manager at Magoosh, an online test-prep company. The decision I had to make was: iterate on a new framework or iterate on the status quo.
The new UI had been developed just before I started and was designed to work with the needs of a high school audiance. It also looked really pretty. The older UI was the site structure for all of Magoosh’s exams, from graduate students through to undergrad, and was old, but stable. I reasoned that my team would have more success creating impact through the new UI because it fundamentally supported a new way of thinking, whereas working with the status quo would be like grafting shinny ideas to a rusty, old engine, which would be way less effective.
However, in my excitement to get going, I missed a very important contextual detail: The SAT exam, which the new design and content supported, was changing in a few short months and so, any improvements made on the new framework would die with the death of the existing SAT exam. This was really terrible timing, and also really terribly understanding of product context on my part. (And yes, the SAT has changes every few years, making life even more challenging for content developers, tutors and students, everywhere).
In ignoring the environment in which I was making the decision, I ended up iterating on a framework that would soon be made obsolete by circumstances. Had I realized this earlier, I would have rather made slightly less impact, that would have lasted into the future, rather than deeper, but temporal impact.
To avoid failure of context, ask: What might the future hold for this product or service? What changes are scheduled for the next 6 months to a year? How is the ecosystem shifting right now?
#3 Failure of complexity
Product and engineering is rife with complexity, so it is an inevitable place to fail. In my experience, complexity is even more tricky when you are working with a technical infrastructure that isn’t completely developed.
I experienced this failure of complexity not too long ago. Having envisioned a way to scale an experiment, I outlined a multi-quarter plan to add 2,000+ high quality pages to our site that would specifically target keywords for which we had stellar content. It was a beautiful plan, but also had a few fatal flaws: First, it relied on architecture that hadn’t yet been fully realized. Creating something new out of building blocks that are also new adds all sorts of unknowns and complexity to a project. Second, the project iterated on our catalog, where users could browse, search and filter for content. The combination of all these permutations inherently resulted in a dizzying number of state changes and hidden edge cases.
My team slowly become paralyzed by all of the complexity imbedded in the project, and while we were able to launch the first phase of the plan, it took us far longer and was far more painful than we had originally thought it would be. The project ended up costing us time, and morale.
Complexity can be hard to see in advance, but this kind of failure can be mitigated by diagraming flow states and leaning on architecture that is fully baked, not fresh.
To reduce failures related to complexity, ask: Do I know enough about the underlying technology to have high confidence in it? Are there inherent complexities in this?
#4 Failure of ego
My ego, though I hate to admit that it even exists, led me down a dangerous path despite warnings from those around me.
The situation was as follows: There was a feature, a pop-up, that I just hated. I knew users hated it too — I had seen it through testing — and I also knew that pop-ups are terrible for SEO. What’s more, 92% of people dismiss them, making them hardly effective. I was convinced that this pop-up had to go.
The only problem was that the pop-up was how we prompted users to register for our site. After 20 seconds on the site, or 3 minutes of watching content, the pop-up would take over the screen and ask users to create an account to continue. Even though the experience wasn’t great, it still was the most effective way we had to capture user emails.
I was told, very clearly, by several people levels above me, not to touch the registration pop-up. I, however, with my ego leading the way, decided that I could get rid of it at least on mobile, where it was most offensive, and when users were watching content that helped them decide if they wanted to purchase or not.
Fast forward 6 months later, and it was true that for the people who were now registering, conversion to purchase had increased. Removing the offensive pop-up was at least one of the factors that lead to a stronger purchase funnel for registered users. But, those conversions were not making up for the loss in registrants at the top. Our database of customers we could email was shrinking and so was our revenue. Major fail.
In this case, ego got in the way of even well intentioned work.
To quell an eager ego, ask: If I were wrong about this, what would I see?
Wrapping it up
To recap, here are the questions that you can ask yourself before starting a new product initiative to minimize your risk of failure.
- Have I told everyone who might possibly need or want to know that this is situation happening, changing, or in the works?
- What might the future hold for this product or service?
- What changes are scheduled for the next 6 months to a year?
- How is the ecosystem shifting right now?
- Do I know enough about the underlying technology to have high confidence in it?
- Are there inherent complexities of this?
- If I were wrong about this, what would I see?
Please let me know if any of this is helpful and comment below if you have other guiding questions that help you navigate risk. One thing I have learned about failure is that it can happen at any phase of your career and that no one is immune. There will always be a role for failure as a learning tool, but the more we talk about it, the more we can help each other side-step the obvious and predictable ones.
******
PS. It turns out that writing about failure, when you are too close to it, also completely sucks. I ended up taking many breaks from writing this in order to get more perspective on the fails.
PPS. A big thanks to Jonathan Dubin for illustrating this article and for being by my side through all of my wins and fails.
This story is published in The Startup, Medium’s largest entrepreneurship publication followed by 336,210+ people.
Subscribe to receive our top stories here.
