svpg
FREE newsletter

Subscribe via RSS

Subscribe

Tag Cloud

product discovery management product management company culture product portfolio planning product development process product strategy product owner innovation great products marketing user experience design product marketing scrum agile project management prototype testing engineering product development high-fidelity prototypes

Browse by Date

  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • HOME
  • Services
    • Product Management
    • Product Marketing
    • Technology
    • User Experience
    • Public Workshops
  • Articles
    • Index
    • Blog
  • Clients
  • Resources
  • Company
    • Team
    • Manifesto
    • Contact Us

Visiontyping and the Hands-On Executive

Posted by Marty Cagan on February 25, 2009

Tags: visiontyping, concept prototyping, high-fidelity prototyping, portfolio product planning

In my last article on Inspiring Product Leaders (see www.svpg.com/blog/files/inspiring-product-leaders.html) 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/blog/files/high-fidelity-prototypes.html). 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.


  • Product Management
  • Product Marketing
  • Technology
  • User Experience

© 2009 Silicon Valley Product Group. All rights reserved.