Startups, Software and the Vision Thing

Dietrich Kappe, Tuesday, September 9, 2008 @ 4:44 pm

If you can dream it, you can do it.

-- Walt Disney

You have a great idea, an idea that is going to transform an industry. You've turned a venture capitalist's head with your presentation and now you just need a software development firm to translate your vision into reality. This is where the trouble starts.

If you move in startup VC circles, you see enough of these deals go sideways or never get off the dime. Investors see hundreds of thousands or millions of dollars plowed into software development without a usable product or service coming to light. Fingers are pointed; tears are shed. For every success there are a half dozen failures. Why is that?

In my experience it all comes back to that word, "vision" as in "translate your vision into reality." What the heck is vision? If you've ever cracked a book on software project management (or just general project management), there's usually a section about having a project charter and a vision statement. As a young developer I would wince and turn to the next chapter. After all, I thought, isn't vision the same thing as what you're going to build? Isn't scope or, more basically, a list of things your are going to build, the same thing as "vision?" Why blather on in consultant speak about vision statements when a more concrete and practical project description could be had?

And this is where the trouble starts. If you don't have a clear idea of what you are building but have a bright and effective development team, you may still come up with a plausible list of things to build. You'll crank along, iteration after iteration, turning out software -- that is, after all, what a good development team does -- but you are likely not developing the right software.

Poor Vision: Are We Building a Spreadsheet or a Word Processor?

Poor vision is not the same thing as bad vision. You may have a very clear idea of what you want to build but it may suck, like the company that wanted to build a laptop software management suite based on cc:Mail in the face of the burgeoning web. No, poor vision means that you have a poor or incorrect notion of what you want to build.

Hopefully most of these ambiguities have  been cleared up by the heartless venture capitalists, but just in case, let's do an exercise. Answer the following questions about your proposed software:

• Do you know who your customers are? Not just traders, but day traders above a certain trading volume in options and futures.
• What is your value proposition? Why would someone actually use your software? Don't use "wonderful" or "joy" in your description.
• What specifically will your users be doing with your application? Don't use abstract verbs like "collaborate" to describe their actions.

If you can't put together a one or two paragraph description of your software that answers these questions, you just have a cool idea, not a vision. As a friend of mine likes to say, "that's crap...it's not something you can develop software from."

At this point you may be scratching your head and wondering what kind of idiot would launch into development without a good vision. It seems so obvious. The truth is that coming up with game changing business ideas is hard work, and in conceptualizing the business opportunity, you may fail to articulate a precise vision. Whatever the reason, software project launching with poor vision is all too common.

Poor Vision: The Version 2 Problem

There are other types of vision problems beyond a lack of clarity and focus. One common case is the "version 2 problem." This is where the stakeholder just focuses on the "new" things that are to be present in version 2 and ignores all the hard work that has to be recapitulated just to get them to where version 1 was. Asking the question "what are we building?" should lead you to realize that what the stakeholder is expecting is enhancements to version 1, not a complete rewrite or redesign. The why are they talking about a "version 2?" Ideally this should lead to a discussion that clarifies vision and expectations.

Poor Vision: Integrating the Wrong Systems

Poor vision isn't just limited to custom software development. Sometime the job calls for customization or integration of existing software packages. The vision problem here is that sometimes stakeholders will look at the feature list of an application and the fact that it has an API and conclude that tweaking the beast into your ideal solution is a piece of cake.

Here the solution is simple: make the stakeholders get their hands dirty. Force them to use the system in question -- no, vendor demos are not enough -- to accomplish some non-trivial tasks. This exercise, combined with an analysis of the power and expressiveness of the API, should resolve any vision dissonance.

The Perils of Agile Development

Poor vision is a problem that can strike any project and any method ("methodology" is the study of methods, right?). Agile development, however, is especially susceptible to it's chaotic effects. Why is that? The great strength of Agile development is that teams start developing and delivering software right away so that the client-developer feedback loop can operate early and often. If that feedback is useless -- as it is when you have poor vision -- the Agile development process can turn into a meandering mess, with features being scrapped, redeveloped and re-redeveloped.

How do you avoid this trouble? Simple: if your vision is poor, don't develop software.

Software development is a surprisingly expensive way to do product definition.

Waterfall, by comparison, is marginally better in this regard (but worse in most others), since the right thing to do in the face of poor vision is to not develop software until that vision has been clarified, and waterfall is excellent at not developing software until pretty late in the project.

That's not to say that you can't get stung by poor vision in waterfall projects (and stung by a number of waterfall's other shortcomings), but you've got more of a chance to catch the problem before expensive developer teams are deployed.

Fixing Poor Vision: Product Definition

The best way we've found of fixing poor vision is by going through a product definition phase. It can still be iterative and agile, so don't worry that you're slipping into a waterfall requirements phase. Just do some of the user research and product conceptualization up front. Use wire-frames and the like rather than code to spitball ideas and narrow in on a definitive product concept.

I'll have more to say on product definition in subsequent posts. For now, I hope I've convinced you of the importance of having a clear vision if you expect to succeed with software product development.

Related posts:

1. Ten Keys to Successful Software Development: #9: Respect the Process
2. The Five Deadly Sins of Software Development
3. Are We Engineering Software or People?
4. Agile Software Development and the Lazy Client Trap
5. Software Development and Wasted Motion

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment