• 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

Innovation Games: Does it appeal to everyone?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Mr. Hohmann,

When asking people what they want in a specific product you will usually get a large list of responses, and in most cases people will request a lot of the same features. However, people are unique and want their own personal features, for example from The Simpsons when Homer's brother allows him to go off and create his own car, "The Homer" (http://www.a2zhobbies.com/pictures/Pol4000.jpg). Does your this method explain how to implement everyones features in a unqiue filling way, so we don't have ugly cars, or how does it just help you decide which of the requested features would be more beneficial to the product and the customer?

Or am I just misunderstanding what this is about?

Thanks,
Ken
[ October 31, 2006: Message edited by: Ken Gitter ]
 
author
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ken -
You're right that you're going to see both a common set of responses and unique responses by individual. The common responses, of course, should be candidates for the core offering. The games are more suited to helping you determine the "common" set of features.

Handling the variations associated with the unique responses is beyond the scope of the games and this book, but I hope you don't mind if I share some of the techniques we've found helpful (some of which are described in my book "Beyond Software Architecture").

One technique that isn't leveraged enough is to simply say "No" and not implement the uniquely requested feature. Perhaps the feature is simply too costly, and the client isn't willing to pay for the same. Or, perhaps the feature harms a strategic relationship with a key business partner. Or, .... <insert lots of good reasons to say No, here>.

Another technique is to create a set of APIs and then allow your customer or your professional services team create the desired customized solution. There are a lot of approaches to this, and I discuss several of them in "Beyond Software Architecture".
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is always hard to leverage a "No", what is really needed is to explain to a customer why he/she does not need a feature. If you go with the expensive card they might pack up and go to someone else, and if you say just that it is too complicated they might think of you as incompetent. It really does get hard some days.
 
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
Branko, it is certainly true that sometimes a customer asks for something that they don't really need, and that you can show them why.

However, I must reiterate that the job of a good product team is to sometimes say "No" to a feature request that isn't in their best interest. This is very hard for product teams, and product managers, but the ability to say "No" and chart a strategic course is a critical skill.
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Luke,

I think there's plenty of value from techniques that you have devised.
I can see that they are simply mechanisms for focussing the mind,
a lot like some of the creativity tools proposed by Edward de Bono,
and the ASIT inventiveness technique. I personally have benefitted
from using this methods in the workplace.

BTW tongue in cheek, have you considered running an expt with 2 groups.
One composed of human staff and another of a gang of chimps. It would
be interesting to see who comes out with a better solution ;o)
regards,
Mo
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is very hard for product teams, and product managers, but the ability to say "No" and chart a strategic course is a critical skill.

I have found that one of the most useful "tricks" to achieve this is the "yes, but ... not in this release" technique. Most projects I have worked with have accumulated a collection of such "floaters" in the feature list - ones which are always there, but never quite make it into an actual release.

Strangely enough, though, sometimes after a few releases and the resulting changes of direction, it actually becomes reasonable to implement one of these features (or at least, something like it).

An example from one of my own projects is Java syntax highlighting in my Wiki implementation, Friki. When Friki was first released, several early adopters asked for Java syntax highlighting (or at the very least, marking a block of code as exempt from the normal Wiki text conversion). At the time this made no sense. The requisite code would have dwarfed the rest of the Friki codebase, brought in all sorts of external dependencies, and set a dangerous precedent by "special-casing" a certain class of content. So I always replied "no" (or maybe "not yet".)

A few versions later, and for all sorts of reasons, the Wiki text processing had migrated out from a direct implementation in the code, to a runtime configuration of a general-purpose transformation engine. One almost unexpected benefit of this was that adding special processing of certain types of content became an add-on with zero impact on the core code, and could even be implemented by a knowledgeable end user with no rebuilding of the application needed. And guess what, one of the first such user extensions was Java syntax highlighting, which can be seen in action in the Java Ranch FAQ.
 
(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 is very hard for product teams, and product managers, but the ability to say "No" and chart a strategic course is a critical skill.



Yup, it takes some fiber to say "No". It also helps to have a clear vision of the product that you can express well enough to illustrate why something just doesn't fit. One goal of my current system is to influence many fairly independent groups of users toward common processes, practices, status codes, etc. Top management supports this part of the vision so that we can hold it up as a reason to resist customization for a new group.

At first blush this doesn't apply very well to Frank's technical reasons for no syntax highlighting, but his vision was to keep it simple. As long as syntax highlighting didn't fit that vision, it was a "no".

Without a clear direction like that, "no" can feel completely arbitrary.
 
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
This reply is for Mo Sayed.
Mo, one of the key differences between Innovation Games and techniques like de Bono's Lateral Thinking is that Innovation Games are about working with groups of customers to better understand their needs. de Bono's Lateral Thinking is a very powerful and useful set of tools focused on an entirely different problem: helping you creatively solve problems.

The two techniques work great when used together. Use Innovation Games to better understand your customers, the problems that they need to solve, and the various reasons/motivations for solving these problems. Then, use Lateral Thinking techniques to creatively find solutions to the problems you've identified.
 
mo sayed
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Luke,
Thanks for the reply. The point I was trying to make is that when faced with a question, many people will provide the most obvious set of answers. Attempting to move on from this is usually difficult, and most people will experience the 'blank-mind' state, where no further progression is made. I believe that mind-focussing tools such as de-bono's method and your techniques provide a mechanism to enable continuity and flow of thought, thereby preventing stagnation of thought and ideas.

regards,
Mo
 
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
Mo -
In that case we're in strong agreement -- both Innovation Games and Lateral Thinking help keep ideas flowing. In fact, I've found that once you get customers starting playing a game, they can be hard to stop!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seriously, I don't think in a commercial situation there is often a reason to say "no". It is almost always possible to put a price tag on a feature that would make it economically feasable for you to actually implement that feature, isn't 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
The only reason I want our folks to say "no" is to enforce standards. If one user group out of 30 asks for red blinking text, they're going to get "no". I hope. We haven't held the line on this kind of thing perfectly. There is if (usergroup == "001") in way too many places.

But I really like the planning game practice of literally putting all the story cards in sequence down the table - do this one first, this one next. We put a waste basket at the end. The customers themselves move a fair number of cards right "off the table" into there.
 
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
Ilja, it can be the case that you can put a price tag on a feature, but the strategic and often unknown implications of putting this price tag on a feature that warrants the cost can really be putting off to customers. Instead of a "Thank you for your feature request, but here is why we are choosing not to do it (aka, NO)", they perceive the "outrageous" price as a willingness to negotiate and a poor vendor if you don't.

In one example I was the VPE and Product Mgt for an enterprise system written on the MSFT stack. A potential customer wanted us to port our solution to a Java/Oracle/Sun stack. I started with "No, supporting multiple platforms is simply not part of our strategic plan."

They persisted, and after consulting with the other execs in the firm we agreed that preparing a quote for the port would be good. It could, after all, close this deal and allow us to sell to other customers who preferred that technology stack.

My dev managers and I estimated the cost to be ~$17M, when we modeled the full cost (dev hardware, training, QA infrastructure, support infrastructure, tools, oppty cost of spending time porting instead of adding functionality the current product, etc.). A very high price. We didn't expect the potential customer to spend this amount, especially since our normally configured system was far less.

The potential customer was not very happy with our answer, because they felt that we were forcing them to bear the entire cost of the port, instead of (as they felt it should be done) amortize this cost over the potential available market.

Not a good choice, because the rest of the market was buying our MSFT solution. Sometimes it was hard to sell, but we certainly didn't lose any sales because it was MSFT.

So, instead of a crisp "No" we ended up with muddled negotiations. I've since confirmed through other experiences that being crisp is often better than slogging through painful negotiations.

And, oh, by the way, the exercise was rendered meaningless when the potential customer purchased our MSFT solution. Which really drove home the point of one of the principles of agile: focus first on business value.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Luke, thanks for the interesting story!

Originally posted by Luke Hohmann:

So, instead of a crisp "No" we ended up with muddled negotiations. I've since confirmed through other experiences that being crisp is often better than slogging through painful negotiations.



Mhh, I'm not fully convinced. Why couldn't you also have a "crisp price tag", simply refusing to participate in those painful negotiations?
 
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you mean by "crisp price tag"

Gian
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"This is what it will cost, and this is why. No, it isn't negotiable."
 
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
Ilja, I can only offer my experience. If your experience is different, then I would certainly support you using the approach that you've found successful. As I've outlined, my experience is that having a clear strategic direction, which includes a definition of what you're *not* going to do (e.g., what markets you're not going to pursue, what technical platforms/standards/etc you're *not* going to support, etc.) substantially increases your chances for success.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Luke, I highly respect your experience - in fact I'd like to learn more about it. It's in discussing our differences where we learn the most, in my experience.

I can see how having a coherent vision of where you want to go is important for success. It's certainly my experience that simply going everywhere your customers point you to leads to a system no-one understands or wants to use.

On the other hand, I also wouldn't want to let new opportunities pass by. It's also my experience that doing things that weren't part of the vision, even things that didn't look important when we implemented them, actually opened new markets and opportunities.

I guess that's the reason why a simple and draconian "No" sounds too simplistic to me. Well, I guess simply putting a price tag on everything is simplistic, too. :roll:

I guess my main point is that we should also be open to new possibilities, and to trying to solve our customers problems in innovative ways that other (potential) customers might also benefit from - even if it wasn't part of our vision. Our vision needs to be agile, too...

Awaiting your comments...
 
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
Ilja -
Clearly, it is impossible to disagree with the concept that you should be continuously interacting/collaborating with and/or listening to your customers. Heck, that's what Innovation Games is all about -- providing you new tools that help you do this. Indeed, because the games provide access to "What you didn't know you didn't know", you'll often be faced with tough questions about what you should, and shouldn't do. Sometimes these answers will still be "No", and, at other times, you'll do as you suggest -- adjust your vision to include new information.

Because this is the Agile forum, I trust that (at least) this forum will agree that this is the responsibility of the product owner (aka product manager for software products). If they are doing their job well, they'll be integrating these new data into their vision and roadmap (for details on how to construst a good roadmap, see "Beyond Software Architecture").

If you've been a product manager, then you know what I mean. If you haven't... then perhaps giving that role a try might be the best way of all to get the benefit of this experience.

Hope that helps.
 
reply
    Bookmark Topic Watch Topic
  • New Topic