In my last article on Inspiring Product Leaders (see www.svpg.com/inspiring-product-leaders) I wrote about executives that are deeply involved in the company’s products, and I talked about how these are my favorite types of leaders for tech companies. Several of you wrote to me that you had such a leader, but you were
struggling to find ways to work effectively and contribute when the leader of the company is so hands-on in the product.

There are several flavors of the deeply involved executive:

1) Sometimes the executive has an idea and they just want you to get it built and launched. Sometimes they even tell you when it needs to launch.

2) Other times the executive has an idea and wants you to mock it up so they can get an idea of what it would be like before they make a decision.

3) And then in other cases, the executive meets frequently with the product team, sharing his thoughts and ideas, looking at prototypes and the results of user testing, providing encouragement and inspiration, and being open to new information and new approaches that move the idea forward.

In the first case, the result is usually all too predictable. When the product is just about ready to launch (typically the product is in QA and working builds are now available), the leader is able to actually see the product, and then he wonders out loud, often at high volume, where the heck this came from and what happened? You should recognize this as just another example of how hard it is to describe software with anything other than software.

The second case is a little better, but doesn’t leverage the power of the product team to come up with the best solutions possible, and doesn’t really help the product leader much either. Ideas rarely tend to reach their potential, and nobody is very satisfied with the process.

The third case is of course the path to the really compelling products, and the one that leverages the talents of the leader and the product organization.

The job of the product organization is to support the third scenario so well that the executive loves the process and gets addicted to the results.

The surprise for many product teams that operate in the first or second case is that this really isn¹t the way most executives want to work; it is an artificial consequence of the process.

So I thought I’d discuss one technique that I have found very valuable when working with hands-on executives, known as “visiontyping” (sometimes also called “concept prototyping”).

In general, when working with executives, the only safe rule is to never trust the hallway chat, the PowerPoint presentation, or the written document. The chances of these vehicles effectively communicating complex software is pretty close to zero.

The only thing I trust when communicating with company execs (and customers) is a high-fidelity prototype. This is because a prototype eliminates a tremendous amount of the inherent ambiguity. And the very act of creating the prototype forces you to think about the problem at a much deeper level, uncovering important issues that are otherwise obscured until typically during implementation.

Most of you already know that I feel very strongly about the value of high-fidelity prototypes (see www.svpg.com/high-fidelity-prototypes). A visiontype is
essentially a prototype, but with some key differences:

– a visiontype is not meant to be used as a spec, so it only typically covers the main concepts required to get the key ideas across; there is no effort made to be complete in any sense.

– a visiontype often happens very early in the process, even before an actual project gets started.

– a visiontype often goes beyond the scope of a single project, and is very often associated with a product strategy.

– a visiontype is a key tool for communication between the product team and the whole executive team.

– a visiontype can be a very effective tool for communicating a product strategy to the entire product team.

– a visiontype helps the executive to see both the power and the limitations of his ideas, often giving rise to new and better insights.

Visiontypes are also useful for other situations. Sometimes when you are trying to solve a difficult problem, you¹ll want to focus in on the key issues, and try out a few approaches. You can do this in a visiontype and test the concept with users. Once you¹ve narrowed down the big things, you can evolve your visiontype into a prototype with more of the functionality represented.

Sometimes product managers feel that they are the ones that need to come up with all the ideas, but this is a narrow and short-sighted view of the role, and in any case, this process of visiontyping not only allows for innovation by all parties, it encourages and facilitates this innovation.

Especially when a company has a visionary leader, it is the job of the product organization to help this leader to translate these ideas into actual products, to understand the benefits and the issues, and to move the vision forward into reality. Moreover, even the most brilliant executive will have plenty of bad ideas too, and this process helps to quickly separate the good from the bad, or “fail fast.”

I want to thank my friend Jeff Herman for his help on this article. I hired Jeff into eBay and he was one of their very best designers and then design managers for many years, and now he runs his own firm (www.jeffhermanconsulting.com) that specializes in helping companies with visiontyping.