I like faking functionality and shipping quickly to gauge real world uptake prior to development. This is not always feasible but if it is, it has a lot of upside. Developers do not like to carefully build out features that are possibly going to get killed. They often resolve this dissonence in two ways:
1. Build a partially implemented feature and push live as a ‘live prototype’ with the idea that the module can be refactored if it actually survives. The danger with this is that the ‘prototype’ might suck and that the planned re-factoring often never happens. Matt Mercieca makes the case that a badly implemented feature that is released into production should not be called a prototype at all.
2. Kill it in process – leverage the fact that correct implementation of an unproven feature would be time-consuming to force management to de-prioritize it against other initiatives that have proven value. This means that the feature may never make it in front of the user.
With a faked feature already in the wild and successful, Developer can be told to build it out smart, built it to last and to scale and s/he will believe that there is a reason for this effort beyond pure hope.
http://ventilla.posterous.com/preaching-user-driven-design
Posted from WordPress for Android