tag:blogger.com,1999:blog-6283515832031707233.post2349482036883265454..comments2014-08-18T08:33:24.200-07:00Comments on Games, Art and Design: Efficiency by Forced IterationOskarhttp://www.blogger.com/profile/12479201444087590865noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6283515832031707233.post-80339311555592015972009-10-23T09:37:17.257-07:002009-10-23T09:37:17.257-07:00That is an interesting question. Before I even thi...That is an interesting question. Before I even think about it I will say "possibly". And then try and think about it.<br /><br />---<br /><br />Ok, so now I thought a little bit on it and the somewhat better answer is probably to say: "It depends." And it should depend on a range of things.<br /><br />The first one is probably about how the business application makes money. Is money constantly streaming in and you are making a profit. Then your productivity will be aimed at gradually improving the profit. For this case I should probably recommend making these rapid iterations on a tiny trickle of users who get selected by split testing.<br /><br />If you change the landing page through this type of method for example. You will want to make it clear to the "victim" of the split test that the current state is a "betastate" and invite the user to return and keep on checking out the progress which is being made on it.<br /><br />If you do this to something which is more technical in nature such as a hypothetical payment system then I think you could do it the same type of way. The critical thing becomes learning how to deal with the unfortunate part of the audience which gets the first total rubbish iteration. I would recommend trying to make a game out of it and reward the users who experience this process with some implicit rewards such as encouragement, easter eggs in the product or close and personal communication. <br /><br />Timothy Fitz has a few presentations and at least one neat video around the internet which presents how they do this type of thing altho their method is larger scale and a lot less volatile. Can't seem to link the video :| but articles work http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/<br /><br />The other side of the case with the money, if it is not streaming in and not profitable I think this would work wonders for also a business application. But it would require a ton of guts and a daring team. <br /><br />The real trick is that IF you actually get a user who gets to follow your journey from rubbish to value you will have forced that user up the value chain. (The thing the cats are working with in the cat post.) You will lose some, but the ones you don't lose are likely to reach hardcore state with an accelerated pace.<br /><br />But what I think it REALLY DEPENDS ON is company culture. Most companies would most likely not be able to deal with the process. Nor be able to follow through to the point where the resulting piece of work also is fully operational and does not leave behind any technical debt.<br /><br />I'm crazy enough to recommend giving it a try someday anyway. :DOskarhttps://www.blogger.com/profile/12479201444087590865noreply@blogger.comtag:blogger.com,1999:blog-6283515832031707233.post-10470696649571280762009-10-23T07:11:26.199-07:002009-10-23T07:11:26.199-07:00Would you say this is an applicable technique for ...Would you say this is an applicable technique for business applications..? :)Essethttps://www.blogger.com/profile/09584993624930150619noreply@blogger.com