File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Don't you think sometimes the best innovation comes when ignoring customers? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Don Watch "Don New topic
Author

Don't you think sometimes the best innovation comes when ignoring customers?

Travis Berthelot
Greenhorn

Joined: Oct 30, 2004
Posts: 24
Don't you think sometimes the best innovation comes when ignoring customers?

I'm not saying that ignoring customers will make money, but you put yourself in a customer box that limits creativity.

Compare Homeworld (3D and Action) and Ascendacy (Creative and Unique). No one would have made Ascendacy while paying attention to customers. The reality is that programmers and such are smarter and more creative than most of their customers.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I would never say "ignore" the customer. If the game developers had ignored their customers the new release might have been accounting software.

I would say the techies often know the possibilities of what can be done better than the customers. Our customers come up with what they call "requirements" but I see them as "designs" to meet some higher level of requirements that that they haven't told us about yet. When we work together to expose the true business need - the real requirement - the tech team might come up with alternative designs that make better use of the technology.

We'd never launch a whole new UI paradigm without collaborative design, but a game designer might well set out to surprise and astonish users. We beleive we need more "wow factor" now & then, but in boring old business we haven't found many opportunities.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I guess I agree with Stan, again...

I wholeheartedly object to the notion that programmers are smarter than their customers. Often enough I have found that when my co-programmers thought they were smarter then their customers, they just didn't fully understood the customers needs.

So, no, I don't think it's a good idea to ignore the customer. But you are right that it's also not a good idea to not be creative on our side.

So I think the best we can do is to make sure that there happens *more* communication, and in both directions. We need to work harder on understanding *why* our customers ask for the features they are asking for, and we need to be creative in proposing - and sometimes probably even demonstrating - alternatives.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Luke Hohmann
author
Greenhorn

Joined: Oct 05, 2006
Posts: 27
Depends on the meaning of "ignore", right? There is a time and place for soliciting customer feedback and listening to this feedback. There is also a time and place for what is sometimes referred to as "genius design" -- the act of creating something without explicit customer input.

I think that is really misleading. Successful products and services solve customers problems. it may be the case that the designer/creator of the product/service sees a problem that the customer doesn't even know that they have, but the reality is that it solves a problem (or fulfills a basic human need; I'm bored).

so, yes, there is definitely a place for "genius design", but I don't think it is about "ignoring" customers. Instead, I think it is *always* about trying to understand their problem ("I'm bored with current UI and game design paradigms -- I want something new") and then creating it.


Regards,<br /> <br />Luke Hohmann | CEO | Enthiosys, Inc. | <a href="http://www.enthiosys.com" target="_blank" rel="nofollow">www.enthiosys.com</a> <br />Innovation Through Understanding<br />cell: (408) 529-0319 | lhohmann@enthiosys.com<br />| Join the Innovation Games Forum: [URL=http://www.enthiosys.com/forumAuthor of "Beyond Software Architecture: Creating and Sustaining Winning Solutions" and<br />"Innovation Games: Creating Breakthrough Products Through Collaborative Play"
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Hi, I didn't even see this was a book thingie with expert authors along when I posted before. Glad my answer was close.

Then I ran off to read the sample chapter and found a quote that made my day: "Customer's don't want a drill, they want a hole."

That speaks right to the problem I described with user "requirements" that are really "designs". Make sure you thoroughly understand the hole. Customers and techies alike can go wrong by getting to the drill design too soon. Maybe what's really needed is nuclear explosives

It's taken years to come into focus for me, but every requirement is really somebody's design so the difference between requirements and design is just where you stand. In my domain, the functional requirements for a customer service system are part of the design for the service process. The requirement to provide customer service is part of the design for retaining customers. The requirement to retain customers ... etc. I think we really need to work at least one level up with customer in detail to know whether "drill" or "nuclear bomb" makes the right hole.
[ November 01, 2006: Message edited by: Stan James ]
Luke Hohmann
author
Greenhorn

Joined: Oct 05, 2006
Posts: 27
Stan, I tend to agree with you. A long time ago I read "On the inevitable intertwining of specification and implementation" by Swartout and Balzer. (CACM, Vol 25 No 7 Jul 1982). It provides a great analysis of what you describe and was very influential in shaping my own thinking on these matters. Highly recommended.

<sigh>
One of the things we don't do enough is mine the truly classic and powerful papers in our field. I know that part of the problem is that we have a LOT of gems from a lot of great people, but the web makes it easy enough to share these things.
</sigh>
R. Greene
Greenhorn

Joined: Aug 15, 2003
Posts: 8
On the theme of "every requirement is really somebody's design" and mining classics, I'm reminded of a paper titled "Designing scenarios: making the case for a use case framework" by Rebecca Wirfs-Brock in the the Nov/Dec 1993 edition of The Smalltalk Report. She presents a diagram derived from Alan Davis's "Software Requirements: Objects, Functions and States" illustrating various levels for requirements and how one person's "what" becomes another's "how."

This ability to look at a problem from several angles has helped, but I've had a lot of trouble figuring out the right level and/or angle. i.e. When is a requirement that smells like a design is really a true requirement or just one possible solution for a "need" that might be better met some other way.

Do any of the games in your book help you figure out how to achieve the proper perspective when looking at requirements?
Luke Hohmann
author
Greenhorn

Joined: Oct 05, 2006
Posts: 27
I think that the games help you achieve a better perspective when framing requirements, because the quality of requirements -- at any level they are framed -- is informed by your understanding of the problem you're trying to solve.

It sounds like you're dealing with the concept of equivocality -- the degree of certainty you have in regards to the requirements. If this is true, then yes, I've found that the games can help.

More deeply, I think problem solving in teams is based on reducing both ambiguity and equivocality. Here, I use the term ambiguity to mean that something can be understood in two or more ways. Equivocality refers to our degree of certainty over the meaning of a shared or desired outcome (solution to a problem). To say an outcome is unambiguous means each individual in the team shares the same meaning associated with the outcome (e.g., we agree on the problem we want to solve and/or how to solve it). To say it is unequivocal means we have a high degree of certainty as to the meaning we share. When ambiguity or equivocality are high there are problems.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This ability to look at a problem from several angles has helped, but I've had a lot of trouble figuring out the right level and/or angle. i.e. When is a requirement that smells like a design is really a true requirement or just one possible solution for a "need" that might be better met some other way.


Spotting those "requirements" that really aren't is hard. I like the notion of "ask why five times" to drill into the real reason, but some times we don't start asking until we start coding. "This is really hard, but I can think of a simpler way. Would it be ok to change this requirement?" Our current process makes changes like this more costly than they need to be. Agile teams with customer on site might navigate problems like this in seconds.

We have a rule that use case documents can't reference implementation details like screens, menus, buttons, dropdowns, etc. There is a good place for higher level documents that don't reference computer systems but just describe the business process. (Replace "document" with "shared level of understanding" if you don't like paper ) Our customers use dozens of computer systems at the same time, not just ours, and a context like that really helps find spots where we can replace or augment parts of the flow.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Don't you think sometimes the best innovation comes when ignoring customers?