To my knowledge, visiontyping was first introduced to the public after a Silicon Valley Product Group session, and can be read about in a blog post by Marty Cagan from 2009. Marty was using visiontyping at eBay. I may be wrong, but that's where I was first exposed to it. It was presented after a long discussion of the good and bad effects of executives who are deeply involved in the product management process. You can refer to his blog posting for background.

For me, one of the main tenants in effective roadmapping is to get stakeholders engaged early and keep them engaged in the roadmap throughout the life of the product. They like to think 'it' was their idea, and if you want support from your stakeholders, then this is an effective way to get buy-in. One of the principle stakeholders of most product roadmaps is the sponsoring executive. I've found that visiontyping is a method that helps focus this executive engagement. Regardless of how involved your executive wants to be, visiontyping is a great place to begin right after the product chartering session, and before the product roadmap is presented.

Visiontyping gives you the chance to do some initial politicking before discussing the initial roadmap. I don't know about you but I like going into a meeting knowing where everyone stands. I like taking time to research objections and gather data. There are very few things I hate more than to be forced into making a decision before I've had a chance to look in to it a bit, yet, this is what happens in most roadmapping meetings. I'm exposed to new concepts, and I'm expected to make a decision.

Well, the visiontype really helps address this. Using the visiontype, the roadmap clarifies things, things that I'm at least familiar with. How did I become familiar with them, because the product management team respected my opinions enough that they provided some high-level initial exposure to these concepts so that I could do a little research if I wanted to. That initial exposure was the visiontype.

All the stakeholders can and should play a part in constructing the initial roadmap, and the use of visiontyping is a method that enables this. The question came up recently as to where, if anywhere, could visiontyping play in Agile processes. The answer is simple when used as I do, in tandem of the roadmap. If your Agile process uses a roadmap that is. If not, then I'd suggest that visiontyping becomes the roadmap, much like a point is the smallest iteration of a line. Just how much additional roadmap you use depends on your iteration size.

Now, Marty did a good job answering the initial 'What is a Visiontype?'. Its use has expanded a little since then, and while the term is still predominantly used in software innovation processes, hardware has been doing similar things with pretotyping. The name comes from a slightly longer version pretendotyping, based on the primary activity of pretending, which differentiates this practice from pre-prototyping activities like surface modeling. You want to pretend as much as possible while learning to appreciate implications you might not have initially thought of. This insight helps when you go into the activity of constructing an initial product roadmap.

So, after the product charter has been defined, and you have an understanding of the business drivers and success criteria, you go into a visiontyping mode. In fact the entire product management team will. At first, they'll be running around with imaginary products trying to simulate in their heads how an anticipated customer might use the product. As you can imagine, they develop a lot of humor at the expense of others as they pretend to access information from imaginary applications. Just what stakeholders you get involved at this point in time depends on their level of involvement and personality. The next step in your visiontyping is to share sketches. This is where you share with each other what you've begun to visualize in our pretending games.

Sketching, PowerPointing, and illustration tooling is normally the next step where all stakeholders become involved.  We provide time for at least one iteration of sketch modification prior to our roadmapping. Then, when we get to the roadmapping stage, we have much more constructive participation than in methods without visiontyping, and entirely avoid the Spanish inquisition experienced in other environments. Consensus is accomplished much sooner, stakeholder support stronger, and decisions much quicker.