Would you like fries with that?

The Drive-Through

You drive up to the intercom at a fast-food restaurant.

“I’ll have a cheeseburger value meal, hold the onions and pickles, large fries and a root beer.”

When you order that value meal, 95% of the details are already known in advance: the burger composition and size, the slice of half-melted-quasi-cheese-food-product, the amount of salt on the fries, and the packaging that it will be delivered in.

Buying a custom web application or complex website is not like ordering a burger.

Requesting a bid for custom software is more like contracting a custom-built home. Any detail can be arranged just the way you want it, right down to the finish on the faux-wood floors (or would you prefer bamboo?).

Custom homes and custom software require a different approach.

A Custom-Built Home

A custom home might cost $200,000 or $20 million. You can’t pull up to the drive-through and say, “Hi. I’d like to build a custom home. It has to have 3 bedrooms, a high-efficiency 1.4 GPF toilet, an island fireplace and walk-in closets with French doors. How much will that cost me?”

Unfortunately, this is how many web application projects start. Starting a software project (or custom home) by talking about specific, unconnected details virtually guarantees poor results and unnecessary expense—no matter how skilled the builder is.

The problem is that there is no guiding set of principles that the builder can use to harmonize and prioritize features. Every single decision is going to be difficult and time-consuming because both the buyer and the builder are probably unclear about the real objective.

Start With a Vision

We spend a lot of time working with our clients to help identify software project “needs” versus “wants.”

We’ve learned through experience that establishing a clear vision is the key to correct prioritization.

A product vision should be short. It should describe who the target users or customers are, what the users need, how the product idea will meet those needs, and ideally, how to measure success. It is not a list of features. It is an elevator pitch that explains why you are building the product.

State the product vision explicitly. Write it down. Get buy-in from all stakeholders (especially the ones that tend to swoop in at the end). Use your product vision—refer to it often as you move through development.

Some excellent resources for developing a product vision include:

• Scrum Alliance article on Product Vision: http://www.scrumalliance.org/articles/115-the-product-vision
• “Design the Box” exercise (by Deborah Hartmann Preus, based on concepts from Jim Highsmith): www.agilethinking.net/sx/docs/Design_the_Box_Exercise.pdf
• Excellent article on Components of a Product Vision: http://productvision.org/blog/components-of-product-vision/

A clear vision helps start a project off quickly, and also helps control schedule and costs as the project progresses. If a feature doesn’t immediately address the vision, make it lower priority or get rid of it completely—it is a “want,” not a “need.” If you have remaining budget, you can always add it later (like that multi-tier redwood deck in the back yard).

A Case Study

A long-standing Foraker Labs client came to us recently with a project to automate part of their sales cycle by processing incoming requests for quotes (RFQs). The project had a limited budget and needed to be completed quickly.

On a project like this, it is tempting to start with questions like, “How should the RFQs be filtered? Where should they go? How many response scenarios do you need?” These are all secondary questions.

If we’d spent too much time on these issues up front, the project would never have gotten off the ground, or would have ended up costing too much.

A short phone call with all project stakeholders revealed the product vision: “We have a very smart staff member who spends a lot of her time responding to RFQs that need a limited set of fairly standard responses. We would realize huge business value if we could free up her time to personally respond to the best prospects.”

Understanding this vision made it extremely easy to prioritize features and build a product that was delivered on-time and on-budget. Instead of building a “full-featured” RFQ management system, we worked with the client to build exactly those features that would most free up the staff member’s time. The client may expand the system in the future, but the important thing is that we didn’t waste time and money building features that did not deliver business value.

What’s your vision?

We at Foraker Labs are happy to work with clients to develop a vision for a new project.

We hope that sharing our experience from the past 10 years may help others who are starting new projects, whether they are Foraker Labs clients or not.

We don’t plan on adding a drive-through window to our office any time soon—but we hope the practices described in this article make your next software order a success.