In software technology, the “when to launch strategy” has evolved over the years. We have gone from a comprehensive approach (get everything you can dream of done before you launch) to launching software that is in a “test state” e.g. beta or pilot or what has been termed “minimum viable product” or MVP. Google launched Gmail in “beta” and kept that term on it for years!

This evolution is happening because we have come to realize that we can’t possibly know everything about how the software is going to be used, we can’t possibly imagine every feature the user is going to demand and the rate of change in the software ecosystems and our business is accelerating. The comprehensive approach is typically called the waterfall method of building software. You write complete documentation on every single thing you want to build in great detail, and then you hand the instructions off to software developers and wait a couple months or years. There are great risks to using this methodology in our current business and technology environments because so much is changing that it’s virtually impossible to write complete specifications for a future unknown state.

Accepting that you can’t possibly know everything is the best mindset to have when launching any software. Expect to uncover issues post-launch and then have a process for resolving them.

Rather than spending months and sometimes years building on untested assumptions, the consensus is that you should launch software sooner and then have a culture that can effectively deal with issues and resolutions. This is called Agile software development, where you build software in short “sprints” and then you release and continue to iterate. This is not easy. Most business cultures are scared to death to launch anything. This fear is manifested in a form of paralysis around launch. We assume that launching without every single feature the user might want will equate to disaster. Ironically, some of the largest software companies in the world are launching “unfinished” software on us every day.

How does this all relate to print software, whether it be launching web-to-print solutions, new print MIS solutions, or launching custom software solutions for your customers? The launch of new technology to any user community is risky and there is typically a lot of resistance to pulling the trigger on the launch. We detest the idea of finding something post-launch that we missed, we don’t like to feel failure. The culture has to change into one of expecting that we will find issues post-launch, not because we aren’t competent or didn’t work hard enough but because we launched sooner so we could get clarity on what the market is actually demanding.

Untested assumptions do not create positive business results, print software that is launched and then issues are resolved as they appear helps everyone focus on what is really important. Brutal prioritization takes over in a live system. Once you have an order flow from your web-to-print all the way through accounting you then understand where you should focus your attention next.

Transitioning from a legacy system is one of the hardest transitions to make because the default logic is that the new system should do everything the old system did and more. Most legacy systems suffer from feature bloat (more features than are actually useful). For most legacy systems, there is no actual tracking on what features are used and which have never been touched. Many printers are scared to launch a replacement to a legacy system, in the fear that one customer will look for a feature that is missing in the new system.

New solutions solve problems in new way; new solutions typically allow the user to do much more than the legacy systems because they can integrate with other business software and perform well in a browser based, mobile trending ecosystem. Don’t put too much weight on every single feature of your legacy system and don’t underestimate the resiliency of your users. Cloud based solutions are making changes constantly for users – people are getting used to a constantly changing software environment. Communicate clearly, offer help if your users want it, and then push forward without worrying about every last feature. Build a culture that expects issues and then has a process to resolve them without drama, blame, or feel of failure.