# 4 Steps I Always Take To Fail - Link: https://www.andreidraganescu.info/2017/08/03/4-steps-i-always-take-to-fail/ - Published: 2017-08-03T18:08:25+03:00 - Author: Andrei Draganescu ![](https://draganescu.files.wordpress.com/2017/08/3f53c-1ux8l4mxa1fv-38w4hgkonq. jpeg) > _Success is counted sweetest > By those who ne’er succeed.To comprehend a nectarRequires > sorest need. I’m a failed entrepreneur, which makes me a great employee. I’m a failed implementer, which makes me a great architect. I have a track record of unsuccesful projects, which makes me a great analyst. I failed at so many things I basically lost count. They teach failure is not a great thing to showcase. Yet, for every big success there are countless small failures. I think we should talk to people about that which they didn’t achieve, with an equal interest as shown to that which they did achieve. > I like to call myself an “expert in failure”, as an euphemism for “hands on experience”. Success is a bad teacher. You bask in the feeling of it and you rarely stop to consider how and why. Failure is interesting, if only because most things fail. Other than hindsight, I found failure hard to track, before it occurs. Yet, one of the things I learned about failure is to spot this cycle in which once I stumble, I keep rolling downhill, and failure becomes the overarching story, one that I see unfolding only when it is too late. ### The cycle of failure Start. 1. I am Underwhelming 2. I am Overwhelming 3. I am Disappointing 4. It’s Useless Failure. The joke? Once you’re in the cycle of failure, you cannot fail fast, you just break things. ### 1. Underwhelming, aka too little too soon. I was underwhelming, multiple times, and my mirror neurons picked up on the feelings of my audience and it was the worse kind of de-energizer ever. After you were underwhelming, the project needs exponentially more energy to be a success. For example, I learned that MVPs are not for everyone, now I select my audience. I realised not all people can grasp an MVP, instead of using the MVP, they start searching for missing features. But there are always missing features, even in old legacy products, in an MVP the search for features only deflates momentum. Another example, Hi Fi mockups are only useful for the person(s) with the original vision, not a single other soul. I dropped the idea of HiFi mockups. Now I’m all from low fi straight to working demo. It’s the same problem, people see polished UIs and expect them to work. Then, when you demo, rehearse for God’s sake and stick to the script. Losing the ideatic thread is completely underwhelming. Presentations are like music, that’s what I learned. You know how it sucks when someone stops a song you like in the middle? That’s how an audience feels when the presenter forgets the next step or humms and fiddles with memo cards. Also, > If you cannot make an MVP that works, then you have a non viable idea, so kill > the project. Do not get too excited by what you are about to accomplish: measure your explanations. Apple TV, Apple Watch … all of the Internet of Things industry, are examples of failure by underwhelming. My advice: if it is too soon, only a select highly invested stakeholders can appreciate progress. If it’s too little hold back. Just don’t be underwhelming. ### 2. Overwhelming, aka too much too soon. A lot of time I overwhelmed folks because I craved to compensate the initial shit demo. But I’ve seen it’s not just me. I’ve seen teams demo the kitchen sink over and over again. Overload. There is no joy in being overwhelming. For me it felt like lack of appreciation. I knew it wasn’t, but when your stakeholders are overwhelmed that is how it feels. It feels you’re doing the best possible work and all these people are suddenly assholes. Be smart. There is no spontaneous asshole. In order to avoid being overwhelming, manage your expectations. In all phases except the measurement phase my expectations began to be of a minimal acknowledgement of progress. I think its great to move all the pressure of high expectations when measurement proves the worthiness. > Emotional rewards of incremental progress only dimminish the visceral reward of > success. Google Glass failed by being overwhelming. If they weren’t simply lying, I think Theranos and Magic Leap failed like this too. My advice: if it’s too much, summarize. If it’s too soon, summarise more. ### 3. Disappointing, aka too little too late. When you are late, the wait creates high expectations. Yet, even on a romantic date, you may be a little late provided you’re a ravishing appearance. No, do not take this as advice, remember, I am an expert in failure. Missed deadlines are the baking powder of disappointment, except when you are outstanding. Personally, I think failure by being disappointing is the worst. It’s worse than losing other people’s money. What I found is that whenever you try to: * fix everything * solve all problems * treat all edge cases * provide for all personas * work for 1% of users * tweak all the buttons * measure the roundness of corners … while stakeholders expect something completed, you will end up disappointing. I always failed by being disappointing when my projects suffered from the holy grail syndrome. The holy grail syndrome is when everyone believes you’ll fix all their problems, but instead you fix your problems. Hey, I could call this “the spring announcement for fall launches of products that you may buy next summer” syndrome, or even better the “failed Kickstarter” syndrome. My advice: if it’s too late focus on the stakeholders, not on your backlog. ### 4. Useless, aka too much too late. I realized, “too late” is not measured in number of days since I started execution, but in “events” that happen, or were always incoming, events which stack up, and in time bury my project. > When enough events cover your project no one will see it. I also found that “too much” does not describe **features**. > “Too much” **always** means “too much to let go”. Features, stakeholders, people invested, team members, money spent, months passed, friends made, promises to be kept they’re all like dragging the project into the ground but you can’t dispose of any. I have failed by allowing debt to fuel faltering projects. I have failed by being blind to events that made the project irrelevant. I failed by trying to eclipse irrelevance with bloat. There are countless ways to be useless and I came to think, probably as a form of psychological shield, that one can’t be an emotionally accomplished manager without at least on fully working useless project delivered too late. So many Microsoft Research Projects, and all the Nokias and Yahoos of the world failed like this, repeatedly. My advice: always be pivoting. --- As final word of advice: failure comes upon a project in very different ways and I think one good strategy is to make a dream catcher out of **milestones**. ![](https://draganescu.files.wordpress.com/2017/08/42780-1ea8zvrlqsi35n1lw0cff9a. jpeg) > Milestones are the detectors of incoming failure. A project without milestones is blind to dysfunctional behaviour. Agile is a very tricky methodology from this perspective. Plowing ahead in constant change, missing retrospectives, failing to set milestones ahead of time will make any project vulnerable to the whirlpool of failure. Trust me, for I learned that: > _Not one of all the purple Host > Who took the Flag todayCan tell the definitionSo > clear of victory > _As he defeated — dying – > On whose forbidden earThe distant strains of triumphBurst > agonized and clear! Thanks Emily. ![](https://draganescu.files.wordpress.com/2017/08/15130-1cduva7ry1dyylmwss8lajq. jpeg)