Version 1 Software: Don’t Go Chasing Waterfall

I’ve been managing software development projects since the pre-internet digital dark ages. Over time I’ve seen software development process change as much as software languages and tools. (Maybe even more so — the Python language, first released in 1991, is in the middle of a data-science-driven renaissance.)

It’s been fifteen years since I last used a waterfall software development process. You might think the last place you’d find that kind of “legacy” process would be an early-stage startup, but I still see startups (as well as mature companies) being pitched waterfall contract proposals by outside contractors to develop “Version 1” go-to-market software products.

If you haven’t been doing software development for more than ten years, you may have never done “waterfall” development (or even know what it is). Regardless of project methodology, most software development follows a sequence of steps that look something like:

1. Define product.
2. Design product.
3. Develop and test product.
4. Deploy and maintain product.

Waterfall methodology refers to planning and scoping all of these steps at the beginning, then executing each step in sequence. The workflow cascades in one direction, like a waterfall.

Except when external constraints don’t allow an agile approach (a government RFP process, say, or a large, hidebound enterprise), I have consistently seen better results through an agile approach: iterative, incremental, customer-conversation driven. Doubly so for a startup.

Agile looks something like:

1. Define product.
2. Get initial customer feedback via mock-ups, prototypes, etc.
3. Incorporate customer feedback into design of product.
4. Develop and test product.
5. Deploy product and measure customer response.
6. Loop back to #3.

Tip: For existing products, substitute “feature” for “product” above. For brand new software, version 1 of the product may actually be an incomplete version “.5” that gets fleshed out through a customer feedback loop like the one above (more on this below).

A product conceived by an elaborate design process, but not validated by actual customer engagement and feedback, may hit the mark on some product ideas but will inevitably miss the mark on others. Under a variety of circumstances over thirty-plus years I’ve never seen it play out otherwise.

Several years ago I worked for a well-funded startup alongside very bright product managers, UI designers, and software engineers (several of whom went on to launch their own companies). Technically we were “agile” because we developed our software in sprints, but our feedback loop was internal.

Rather than validate core assumptions with actual customers, we developed a full-featured “stealth” V1 (Version 1) of our product, a healthcare portal, that launched with much fanfare and a hefty marketing budget.

With an all-star team and resources most startups can only dream of, we had every possible advantage. But because we did not include customer feedback in our process prior to launch, our product had about the same success as any other V1: some features resonated with users, but too many other features flopped. I joined this company at founding and saw it rocket to 300+ employees very quickly. It contracted back down to 20 employees almost as quickly.

Why Waterfall?

In the last ten years, thanks to Eric Ries, Steve Blank, and others, a lean startup approach emphasizing customer validation has become mainstream thinking in software development. So that begs the question: why do many software contractors still pitch waterfall projects?

Let’s look at software product development from the perspective of a contract development firm. They need to manage project scope to make sure they fit a customer’s budget with enough room to make a profit. That’s pretty hard to do if you tell the customer, “we’re going to try out some things and see how they play with customers; we’ll iterate on that until we validate the design.” So even “progressive” software contracting firms wrap modern product-design in a linear (waterfall) project process by proposing something like:

1. Full V1 design (user personas, user journeys, feature and workflow design, UI design, detailed SOW scoping). A thorough design phase like this, with UX specialists starting from scratch, can easily cost several thousand dollars.
2. Build V1 according to the spec defined above.

Whereas as a client what you’d really like is a project that looks like:

1. Do enough design (a lean version of the above) to define a “0.5” release.
2. Build 0.5
3. Get customer feedback
4. Refine and build 0.6
5. Get customer feedback
6. etc.

Working Around Waterfall

So what can you do to promote incremental, customer feedback-driven product definition and development in the construction of your software?

One option is to favor T&M compensation (time and materials, “paid by the hour”) over project-based compensation. T&M contracts are suitable when scope is uncertain, which it is when taking an “iterate until you validate” approach. It’s worth pointing out that an in-house team, if you have one, is effectively T&M.

Some contractors provide dedicated engineers long-term on a T&M basis, either augmenting your own staff or operating as a self-contained, dedicated team; that’s one model that can jumpstart a new software development effort into an iterative development process. Make sure your contract allows you to terminate early and quickly if the vendor isn’t performing.

If you don’t have in-house resources and you’re uncomfortable with the scope risk of a T&M contract, another option is to minimize the scope of your Version 1 project. Turn it into a Version .5 project, an incomplete version sufficient to validate your concept, and structure follow-on versions as separate projects. In addition to lowering your investment in un-validated product development, this approach incentivizes your vendor to perform to win follow-on work. To avoid misunderstandings, be clear about the incremental, feedback-driven approach you want to take with candidate contractors and make sure they’re amenable.

However you structure your software development project, validate the initial concept with as little engineering investment as possible (consider low-effort approaches such as mockups or prototypes), and continue to vet changes through customer feedback.

Don’t go chasing waterfall, even if you’re outsourcing, and especially if you’re outsourcing V1. Build customer-driven validation into your design and development process through an incremental approach. If outsourcing software development, make a phased approach a requirement for your contractor.

This post was originally published on WeWork Labs Insider.