Turning Feedback Into Inspiration (1)

Steve Jobs has often cited this quote from Henry Ford: "If I'd have asked customers what they wanted, they would have told me, 'A faster horse!' "

This is Jobs's defense of Apple's reluctance to listen to even its most passionate customers, and the line is a good one to remember the next time you're considering a new round of focus groups. "The whole approach of the company is that people can't really envision what they want," says Reid. "They'll tell you a bunch of stuff they want. Then if you build it, it turns out that's not right. It's hard to visualize things that don't exist."

But Jobs doesn't exactly ignore customers; he uses their ideas as inspiration, not direction; as a means, not an end. Ever since the netbook boom began, many people have begged Apple to put out its own. These tiny, ultra-portable machines represented the fastest-growing segment of the PC business, and the company seemed to be missing out. Some people (yours truly included) even went so far as to hack PC netbooks in order to run the Mac OS. Jobs could not have been more dismissive. "We don't know how to make a $500 computer that's not a piece of junk," he said of the prospect of an Apple netbook.

Cut to January 2010, and there's Jobs unveiling a $500 computer that isn't a piece of junk. But the iPad isn't a netbook. It's both more, and less -- not just a faster horse.

Outside In Software Development

So, are traditional software development methodologies using an Inside Out approach and could this be a significant factor in the failure, or mediocre success, of most software development projects? It is interesting to consider this paradigm in the context of Steve Jobs' comments. I believe traditional software development lifecycle projects typically use an Inside Out approach to developing solutions. That is, they use an approach where users or customers are asked what they want, typically during user interviews and workshops. The responses gathered during these sessions are then collated in the form of a business requirements document. This document then forms the basis from which systems are developed and tested and are said to comply with the requirements.

The problem here is that once users have been asked what they want, nobody is performing an analysis of what they really need. Wants are translated into business requirements without any regard for understanding the really need, from the user perspective or from the Outside In.  Outside In describes a way of analysing a situation by examining it from a user perspective and in doing so, it aims to provide value to the user.

Outside In Software Development is an approach whose focus is to provide value to a system’s users. By using scenarios and stories, the Outside In approach provides development teams with a clear understanding of users’ needs, bringing them out of their IT domain into the user domain and thus reducing the incidence of systems which do not fulfil user’s requirements. Added benefits of this approach include:

• Leads to simpler and more cohesive systems, because developers will write only the minimum amount of code to satisfy the user requirements.
• Minimal code reduces the costs associated with system maintenance.
• Development, testing and implementation times are minimised.
• Testing is performed based on real user scenarios ensuring higher code quality.
• Reduced project time means risk.
• Ensuring user needs are addressed ensures greater customer satisfaction.

An Outside In Software Development is one of the latest Agile approaches to software development and can be used in conjunction with the CEMMethod, ensuring a successful software development outcome.

References
(1) Invincible Apple: 10 Lessons From the Coolest Company Anywhere http://bit.ly/bOb6S5
An Introduction to Outside-in Development http://bit.ly/cOjCXM