A Minimal Approach to Creating Supply Chain Software

Business leaders, from entrepreneurs to in-house technology innovators, have long succeeded by creating “minimal viable products” (MVPs), a concept introduced by Eric Ries in his book The Lean Startup. The core idea of an MVP is to create a lean version of an innovative new product while minimizing cost and keeping timelines short. That enables the product to be quickly validated by real customers in live environments. Unfortunately, tech experts often don’t understand or misapply the MVP concept, falling into traps that are hard to get out of.

Many innovators and their financial backers worry that a minimum viable product will have too many limitations. That doesn’t have to be the case if leaders stick to the principles of eliminating wasted time and cost whenever possible. While the product’s objectives might be “minimal,” that should never mean settling for a broken or half-baked software that delivers less than the full idea.

Although the ultimate vision for a new supply chain application might encompass a dozen or more entities, don’t try to have your product start there. Develop an initial scenario to prove out success by boiling down the number of players to a minimum — for instance, shipper, carrier and receiver. By starting with this thin slice, and getting it to work from one end of the supply chain to the other, you can cost-effectively prove its value. Later on, you can expand to cover the ancillary parties and millions of exceptions.

I saw one such innovation project fail due to too much attention to exceptions and variations. During my tenure at the supply chain startup Zengistics, we connected with a national truck rental firm that had spent five years on a supply chain collaboration solution that never shipped. When we showed the truck rental firm a very similar app we developed, they couldn’t understand how we created our production version in half the time. While the ideas were similar, ours reached the market in time for commercial viability while theirs foundered.

Measuring Whether the MVP is Viable

There’s an amazing the diversity of opinions from executives about what “viable” means in an MVP. Creating an MVP doesn’t have to mean shipping a product that’s on life-support. It should mean you are developing and delivering the product that’s required to delight your core target customer. Viability can be defined through success metrics in many different ways:

• Through feedback, retention, usage and engagement from “friendly” customers, validating product benefits that currently aren’t available in the marketplace.
• When a business generates enough sales revenue to recover development investment.
• When there’s a win-rate indicating product and market fit, even when marketing can only reach a limited number of prospects. 

Success, as defined by any of the above measurements, means committing to developing a fully functioning software product that satisfies customers’ expectations of software quality. That means achieving a delicate balance between high value and minimal cost.

In business, our minds are often occupied with an end result expected in the distant future. Having a grand vision is great, and can ultimately guide your organization to solve some of the world’s most important problems. Yet even if you have the money to invest in building a ton of features and capabilities, you have the complicated management challenge of coordinating a large team. Also, quality control becomes more difficult as the scope of your product grows. Twice as much software code usually means more than twice as many bugs.

Develop a First Commercial Version

Executives who are confident that they have a new product idea that can succeed in the marketplace need an MVP suitable for commercial viability. To avoid the negative connotations of “minimal” in your MVP, set your sites on developing a first commercial version (FCV).

Your FCV will need to pass some tests of reasonableness for a product for which customers will pay real money, and expose their business to the risk of use. Expect these issues to be sorted out between your financial backer, software architect, business analyst and executive sponsor before serious dollars are spent or lines of code are written. Following are some considerations to address:

• Platform and standards conformance. Use a single well-accepted core platform for your MVP to contain development costs and ease customer acceptance.
• Security. Customers expect controls such as data encryption and double-factor authentication.
• Simple log-in. Use existing identity services from the likes of Facebook, Google or Apple.
• Performance. You might not need lighting-fast response times for commercial success with your earliest customers.
• Lack of bugs. Pre-determine how many defects, of which severity, will be acceptable for release, and plan for development cycles to resolve them.

There are also attributes that you should consider keeping out of scope, in order to save development effort and time-to-market. You might not initially need:

• Universal appeal. Keep focused on the core users and use cases and leave the outliers for later.
• Scalability. Your MVP will probably be used by few customers in few locations at first.
• Multi-platform support. If it’s a mobile app, choose iOS or android; if for desktop, either Mac or Windows — not both.
• Multilingual. Don’t worry about being politically correct. Start with your own language and country.
• User testing. It’s nice to have, but takes time. Use your MVP to learn from real clients what they think, like, and need.

The bottom line is to eliminate complexity to avoid being stuck with a runaway software project. My rule of thumb it to “Keep Things Super Simple,” and leave the exceptions for later. While your solution should work from one end of the supply chain to the other, the key is to get it working, ship to customers and let the marketplace vote on its value.