Test the business process before you build the software

The modern conventional wisdom in these days of on-demand resources and rapid-fire, iterative development is that the first priority for any application development team should be to quickly build a ‘minimum viable product’ and get it out into the field.

Whether it’s enterprise developers ensuring alignment with business need or start-ups demonstrating that a market exists for their wares, it’s imperative to get the application out of the development labs and into the real world as early as possible.

But even though today’s on-demand tools and fast-paced methodologies make it possible to quickly recode and pivot in response to market feedback, a technology-led approach is not always the most effective means of getting to the ‘MVP’.

Look, no computers

In an era when the emphasis is shifting towards delivering real-world outcomes rather than merely functionality, what matters most is testing the business process that the software is intended to automate. If you’re devoting all your resources to getting the software to work well, you may miss more significant failings in the end process that it instantiates. Therefore there’s an argument for delivering and fine-tuning the process using existing resources before beginning any application development.

For the founders of payroll processing giant ADP, their minimum viable product as a start-up long ago was to do payrolls on adding machines and deliver the results by bus. In those early years, they didn’t have access to computing until they’d reached sufficient scale to be able to invest in an IBM mainframe system.

But even when technology is easily accessible, sometimes it’s better to develop the business processbefore making your technology bets.

Tesco vs Webvan

Back in 1999, when Amazon was already becoming successful with its online book retailing model, a number of companies sought to seize the online market for home-delivered grocery shopping. Chief among them was Webvan, the San Francisco based start-up that CNET cited as the largest dot-com flop in history.

Webvan built out its infrastructure before it had proven its business model, spending millions on a fleet of high-tech delivery vans, signing a billion-dollar contract for construction of a network of high-tech distribution centers, and in classic dot-com style kitting out its offices with top-of-the-range computers, gadgets and furniture. The failed company shut down in October 2001.

Around the same time, I remember reading an article about how UK-based supermarket giant Tesco had set up its own online home delivery service. Tesco already had a long history of experimenting with online retail — wikipedia notes that it recorded the world’s first ever online shopping transaction from the home in 1984, in a trial in which customers used a videotex system to place their orders. So it already had some experience under its belt when it launched its web-based shopping service in 1996.

Customers entering their orders on the website at that time might have assumed a completely automated system lay behind, but that was far from the case. Instead, each individual order was manually printed out at an administration centre and then faxed to the local store, where an employee was relieved from shelf-stacking to collect the ordered items into a trolley and take it through a checkout before delivering it to the loading bay.

The canny retailer was spending no money on unnecessary infrastructure until it had understood and proven the business model. Today, online orders are estimated to account for around six percent of Tesco’s total UK revenues, which makes the online arm a roughly $4 billion-a-year business.

Not starry-eyed

These examples are helpful reminders not to get starry-eyed about technology until you’ve established the business need and actually tested the best way of delivering the desired outcome. You only have to look at the burgeoning fields today of social media and big data to discover hundreds of start-ups who are ignoring those lessons, trusting that the coolness of their technology is all that is needed to make an impact in the market. No doubt there are countless enterprise development teams making similar errors, most notably I suspect in the field of social media marketing.

The other reason for actually testing the process in the real world before you invest too much in building it is that you won’t establish the true market until people can actually choose whether or not to use it. I often see start-ups making this mistake — they get enthusiastic feedback from prospects about what the concept of what they’re doing, but once they finally get to market, nobody buys.

Sales guru Adrian Davis explains that having an elegant solution to a need counts for nothing if the need isn’t a priority:

Every business has more needs than it can address. Consequently, businesses learn to live with pain. What you see as a true need, your prospective decision-maker most likely sees as a tolerable inconvenience. Every year, organizations budget their expenses for the coming year. Part of this process includes items and part of this process excludes items. It’s not that the excluded items are unnecessary. It’s that they are not a priority.

His advice is to focus on helping customers achieve their goals. Or as Ray Wang once advised Dennis Howlett, “People are buying outcomes.” That sums up what every application developer and product manager should be focusing on, right at the start of the development process: what is the outcome I’m delivering? Then start testing the best way to achieve it.