How I killed Mailcloud’s 21,000 users today(malcolmbell.net)
malcolmbell.net
How I killed Mailcloud’s 21,000 users today
http://malcolmbell.net/2014/04/29/how-i-killed-mailclouds-21000-users-today/
6 comments
I find the "premortem" way of looking at it psychologically more appealing. When asked to "think of all the dangers", I can imagine a tendency existing to bury one's head in sand and say "what danger? What risk?". We also know of "hindsight bias", and I wonder whether a premortem would be a way to exploit it rather than be a victim to it.
At least, I'm not rational enough to reason identically whether I've been primed with death or just the risk of death. So I think this would be a useful exercise for me (and those like me).
At least, I'm not rational enough to reason identically whether I've been primed with death or just the risk of death. So I think this would be a useful exercise for me (and those like me).
It seems like a minor distinction, however asking people:
"6 months from now, we end up failing. What went wrong?"
gets much better answers than:
"what are the biggest risks?"
"6 months from now, we end up failing. What went wrong?"
gets much better answers than:
"what are the biggest risks?"
I disagree, Risk Assessment is the process of assessing what could go wrong. In the Pre-Mortem, you take a different approach, and take, as a given that the project has failed, so now you are not discussing what could go wrong, but what did go wrong.
It's a subtle, but important distinction. As the article notes, that once you have an image in your mind of a failed project, you come up with a somewhat different analysis than if you are trying to picture what could wrong.
I frequently see attitudes in risk-assessment, particularly in those that have planning responsibilities, where people actually get quite defensive when people are pointing out the risks in the project, to the point at which others in the room no longer wish to participate. On the flip side, if we are presupposing things went really wrong, and everything failed - it almost becomes a game to figure out what went wrong.
I'll take it one step further - at a tactical level, when my engineers/technicians are preparing for a complex change in our IT environments, and they do their walkthrough, and demonstrate the change is guaranteed to work - that is just the first, almost minor step. The second, much more important one, is to then find at least three ways in which the change will fail. Getting something to work might only take a few hours. Finding out how the change will fail may take several days, or even weeks - but it's much more informative and useful to the change control procedure than demonstrating something will work, and I find the mindset of "accepting and looking for failure, rather than resisting it" is the key.
It's a subtle, but important distinction. As the article notes, that once you have an image in your mind of a failed project, you come up with a somewhat different analysis than if you are trying to picture what could wrong.
I frequently see attitudes in risk-assessment, particularly in those that have planning responsibilities, where people actually get quite defensive when people are pointing out the risks in the project, to the point at which others in the room no longer wish to participate. On the flip side, if we are presupposing things went really wrong, and everything failed - it almost becomes a game to figure out what went wrong.
I'll take it one step further - at a tactical level, when my engineers/technicians are preparing for a complex change in our IT environments, and they do their walkthrough, and demonstrate the change is guaranteed to work - that is just the first, almost minor step. The second, much more important one, is to then find at least three ways in which the change will fail. Getting something to work might only take a few hours. Finding out how the change will fail may take several days, or even weeks - but it's much more informative and useful to the change control procedure than demonstrating something will work, and I find the mindset of "accepting and looking for failure, rather than resisting it" is the key.
[deleted]
[deleted]
The researchers contend that a premortem is more effective than risk analysis:
> Although many project teams engage in prelaunch risk
> analysis, the premortem’s prospective hindsight approach
> offers benefits that other methods don’t. Indeed, the
> premortem doesn’t just help teams to identify potential
> problems early on. It also reduces the kind of
> damn-the-torpedoes attitude often assumed by people
> who are overinvested in a project. Moreover, in
> describing weaknesses that no one else has mentioned,
> team members feel valued for their intelligence and
> experience, and others learn from them.
I will liken the use of "pre-mortem" to the usage of "synergy". Seeing that the founder is a "grow-hacker" such word coining fits the bill.
Donning my pre-mortem cap: perhaps they pre-died because it's impossible to figure out what mailcloud actually does.
Yeah... maybe the new homepage increased conversions when they removed any semblance of information from the page? The only two options now are, "I have no idea what this is, but I'm curious"; and "I don't give my email address to randoms"
So, we imagined we have shipped our closed BETA version of Mailcloud, and nobody wants it. Worse than that, it doesn’t even work, reviews are terrible and generally the whole world hates us – signified in a homepage Techcrunch piece because our product was so bad.
Problem is, your failure is not likely going to be that dramatic. The product will likely work, have some users who like it and some positive or at least not terrible reviews, but will just never take off. Might not be a clear reason why, you just didn't "hit it."
Problem is, your failure is not likely going to be that dramatic. The product will likely work, have some users who like it and some positive or at least not terrible reviews, but will just never take off. Might not be a clear reason why, you just didn't "hit it."
good thoughts but I think a much better version of this is the Dangers Strengths Opportunities exercise (e.g. http://robdkelly.com/blog/getting-things-done/dos-exercise/)
The danger part is effectively the same with the added bonus of being able to convert all Dangers into Opportunities. Once you do that, you've gotten the entire team to agree that, to achieve success, all they need to do is accomplish the Opportunities.
The danger part is effectively the same with the added bonus of being able to convert all Dangers into Opportunities. Once you do that, you've gotten the entire team to agree that, to achieve success, all they need to do is accomplish the Opportunities.
It would have been good to see some examples, not just the concept.
http://en.wikipedia.org/wiki/Risk_assessment