• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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>
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
reply
    Bookmark Topic Watch Topic
  • New Topic