Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Innovation Games: Does a customer even know?

 
Branko Santo
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

a very interesting aproach, and right where it is needed. Programmers and especialy software engineers have a lot of problem with customers who themselves do not know what they want.

Engineer: What would you like your program to do?
Customer: I would like....{1, 2, 3, 4, 5, ...}
Engineer: Perhaps also...{a, b, c...}
Customer: Oh yeah that would be nice!

Two weeks pass, all the diagrams, preparations are set and coding is already underway.

Customer: Could I also get ... {55, 56, 57, 58..}...

This is so often the case with programming. I am looking foreward to aquiring your games and trying them out (offcourse first with friends).
 
Luke Hohmann
author
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... and I am looking forward to hearing about your experiences with the games!
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Two weeks pass, all the diagrams, preparations are set and coding is already underway.

Customer: Could I also get ... {55, 56, 57, 58..}...

Off the innovation topic ... If this is really your life, and you haven't already done it, read up on the way Agile methods describe iterative development with a "planning game" session for each iteration. HERE is one good resource.
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "Could I also get" that comes two weeks later is often the result of that single person finally having conversations with other users/customers/stakeholders. This symptom reveals that more communication needs to happen across users before the developers receive laundry lists.

The innovation games should involve a selection of multiple users/customers/stakeholders. That way you can get those conversations to happen earlier in the project.

It's very likely that if you are getting frequent "Could I also get" comebacks, there are also multiple "That original thing I needed really isn't all that important" that you never hear about. That can waste a lot of developer time and unnecessarily bloat the software. Innovation games would also help to weed out these features that one person thought would be useful that later turned out not to be.

Innovation games cause more conversations. Conversations cause the users to better understand their needs and how to prioritize them.
[ November 01, 2006: Message edited by: Marc Peabody ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Marc Peabody:
The "Could I also get" that comes two weeks later is often the result of that single person finally having conversations with other users/customers/stakeholders.


Or there was some other way to generate an insight tht lead to the new idea for a requirement.

Although games certainly can help to generate a huge amount of those insights earlier, I still think that some insights really only can be expected when the users start to actually use the real system. A technique that can probably help with this is the usage of prototypes (even paper prototypes - perhaps there are games that go in that direction?).

Still, I think it remains important to release a real running system to the customer as early as possible. The feedback from *that* experience cannot possibly be beat, in my experience.
 
Branko Santo
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually me being a single developer currently can not do too much about it.

But there always is a solution and the one I like is.

Customer: I need "function 1"
Product manager: Function 1 will take x time and cost y money. If you cancel within 1/2x than it will cost 60% of y,otherwise it will cost 100% of y.
Customer possibility 1: OK I really need it!
Customer possibility 2: Oh perhaps it is not as needed.


Bottom line is that developer time costs $$ and engineers time costs $$$$ so if they want to pay we can change the specs all day long for as long as they want.

Yeah not very agile but is a way out of situations like this.
 
Luke Hohmann
author
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Branko, the situation you describe is referred to as "Non Recurring Engineering" and is a common practice that enables customer to increase the prioritization of highly valued items in the product backlog.

See, for example: http://www.pragmaticmarketing.com/productmarketing/topics/05/0503ds.asp
 
Branko Santo
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Luke thanks for the link

It was a nice read!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Branko Santo:

Bottom line is that developer time costs $$ and engineers time costs $$$$ so if they want to pay we can change the specs all day long for as long as they want.

Yeah not very agile but is a way out of situations like this.


If you ask me, that's actually quite Agile.

Well, even more Agile would it be if you were able to reduce the costs to change the spec. In fact with a "fully Agile" approach, the costs of changing the *spec* become near zero - only when you change something that is already implemented, costs inevitably rise.
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic