You Can Build a Pilot of Almost Any Digital Solution in a Month

• Almost any digital solution can be piloted within a month by focusing only on the core "happy path."

• You don’t need full integration, admin tools, or scale—just real usage and real results.

• Pilots aren’t concepts; they’re live tests that deliver 90% of the benefit for 10% of the effort.

I'm not stating this as an opinion or a thesis—I'm stating it as a fact born from experience.

I realise this is contentious, so for context, it's worth mentioning that I founded a company on this idea called 3wks ("pilots in 3 weeks") in 2012. We successfully delivered pilots for over 250 engagements with 50 clients, many of whom were blue-chip organisations in media, education, finance, banking, and government. Everything started with a pilot, regardless of the project's size. I sold 3wks in 2017 (it floated in 2018).

When I say it's possible to pilot almost anything in a month, I mean we can build a solution that delivers most of the business benefit for a small number of users—within one month. Not the whole system. And it won't be useful for all users—just a select few. The benefit, of course, is that it gives everyone immediate confidence and generates early momentum, which is rare and highly motivational.

This holds true whether it's a 3-month standalone project with 10 users or an 18-month project involving 3,500 users integrated with 31 backend systems—though that seems counterintuitive, right?

I'm not talking about a "proof of concept." A pilot is genuinely used, on a small scale, often for a limited time. In my experience, proofs of concept are typically deployed in test environments and aren't used by line-of-business staff for daily operations—not even temporarily.

So, how is this predictably achievable?

I've previously outlined some techniques for "not building everything" in the Pilot, which helps focus on what to include in the pilot and what to leave out.

Here are some counterintuitive truths that make pilots so achievable, regardless of the final system's scale:

1. The "happy path," or primary use case, of a business system is a tiny part of the overall solution—and it's the only part needed to test the benefits temporarily and on a small scale. The remainder of the system deals with edge cases, which take significantly longer to design, build, and test. These can be tackled gradually later, provided we prove the happy path first.

2. Usually, we don't need to integrate the pilot system fully with existing systems. Humans can manually transfer data into and out of the pilot because the goal isn't integration testing—it's demonstrating the core functionality.

3. Administrative features, such as user-role management, templates, and reference data, are essential for a smooth, scalable system. However, during a pilot, these can be manually handled by developers, as scale isn't the objective. Building full admin capabilities early adds unnecessary complexity.

4. Creating simplified versions of essential features requires about 10% of the full effort yet achieves 90% of the benefits. This trade-off is ideal in a pilot since it quickly validates the primary benefit on a manageable scale.

I've outlined scenarios where pilots don’t really add much value, but this isn’t because building pilots is difficult—it’s because incremental completion doesn't add meaningful value.

For example, running a census incrementally is challenging as it's a once-in-four-years event. However, you could certainly build a simplified version—still better than IBM’s fiasco—in just a month.

If anyone's brave enough to try this, hit me up, and I'll help shape it, free of charge.

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.