12 reasons why products fail, enterprise edition
30 October 2013, 17:56
Part three of the mini‐series I am running at the moment on the usual social channels—twitter, g+, linkedin and xing—called wishful thinking breeds failed products. It distils what I have witnessed and heard during 20 years in the (mobile) software industry.
. By request, they are listed below for future reference. :
‘Better play it safe, because it has not been done before.’
‘Better play it safe, so it won’t cause all these extra rounds of meetings.’
‘Better play it safe, because the first feedback was rather reserved.’
‘Better play it safe, so we get the OK.’
‘Better play it safe, because the engineers say it cannot be done.’
‘Better play it safe, because that code base is spaghetti.’
‘Better play it safe, so we all can go home at five—and on 14:30 (D) / to the pub (GB) on friday.’
‘Better play it safe, because the blame will fall on us.’
‘Better play it safe, so we have time for more features.’
‘Better play it safe, to pass the usability test.’
‘Better play it safe, to pass the regression test.’
‘Better play it safe, to not jeopardise my promotion.’
ask not what this blog can do for you…
Now, what can you do? First of all, you can spread the word; share this blog post. Second, the series continues, so I invite you to connect via twitter, g+, linkedin, or xing, and get a fresh example of wishful thinking every workday.
And third, if you recognise that some of the wishful thinking is practiced at your software project and you can and want to do something about it, then email or call us. We will treat your case in total confidence.
ps: you can check out part two if you missed it.
Labels: practical, why products fail
0 comments · post a comment
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
What is Peter up to? See his /now page.
- info@mmiworks.net
- +49 (0)30 345 06 197
- imprint