Starting with prototyping? Wait

By jumping straight into prototyping, you reduce or eliminate strategic outcomes.


8 application development model wireframe

This article was first published at CIO.com, Jan 30, 2018

Obsession with prototyping

Many teams use what they call a “kindergarteners’ approach” to come up with as many ideas as possible. It is a quick and fun way to experiment. To help with such prototyping, teams use tools ranging from paper napkins and sticky notes to 3D printing and computer simulation. To inspire ideas through prototyping, organizations provide teams with work places that range from the merely colorful to the arguably weird.
Prototyping works for almost anything from coffee mugs and everyday products to digital technologies. Agile methodologies recommend prototyping.
Most importantly, prototyping can produce good results. Regardless of the “product,” design is important, and prototyping is an important design technique.
So, the question is not whether prototyping is required. The question is when.

When is the right time?

You are prototyping something because you have already decided to implement it. So some selection (or discovery) method was probably used.
However, if you want your tech initiatives to translate organizational strategy into outcomes, it’s important to know a couple of things:
  • In the traditional software development world, for example, collecting requirements is considered discovery. If you come across statements like “Develop the right tech,” the suggestion is to get the right set of requirements. If discovery is limited to this task, you are missing some crucial things.
  • Traditional tech selection involves ineffective methods, such as selecting a tech merely because some competitors have it.
Today’s initiatives, whether involving a traditional software application or digital tech or business transformation, need a strong new discovery method. You need to first focus on discovery before moving on to design and prototyping.

Start with discovery

Design/prototyping could be the wrong thing to do if that’s what you’re doing first. Don’t design anything before you know it has “strategic potential,” that is, a reasonable probability that it is the right thing to work on in the first place. Ignoring this suggestion could be a huge business risk and might turn your project literally into a kindergartener’s project.
You need to start with discovery, but what’s discovery in today’s initiatives?
  • Discovery is first and foremost the finding of a “reservoir.” Like a reservoir in the oil industry, a reservoir in strategy translation is a set of processes that when purposefully redesigned can eventually generate strategic outcomes.
  • The second most important discovery activity is finding strategic tech. Prototyping doesn’t help discover strategic tech. In fact, no amount of prototyping iterations can show whether a proposed tech is strategic. You may still be spending time and money on what we should call a “dry hole” — a tech that does not contribute to organizational strategy, akin to a well that is drilled but has no oil. Shockingly, nobody appears to ask a simple question, “How do we know whether the tech we prototype has strategic potential in the first place?”
Discovery is crucial because a wrong thing is a waste even if it were nicely designed.
Interestingly, if you do strategy translation, prototyping is what helps you discover the right technology.
If so, what are the prototyping approaches available? Well, you could pick from one of three commonly used approaches: iterative, parallel or a combination.
In iterative prototyping, you will create one prototype (or design option, if you will), check it for strategic fit as well as for other characteristics that are important, and then improve it. Based on level of fit, etc., you will then repeat the check and improve tasks.
The second prototyping approach is about creating two or three design options at the same time, then checking the options for fit, etc., and finally picking the best.
The third prototyping approach is basically the second approach done in an iterative way, that is, by repeating the check-and-improve tasks for each of the design options. The third approach is often better. For example, if you create two design options at the same time, you can perhaps borrow ideas from both and come up with a third design option that is a lot better.
I mentioned that in strategy translation, there are two major discovery activities. The first major discovery activity is finding the reservoir, while the second major discovery activity is finding the right technology to implement (or purchase). It’s when you “transform” the reservoir that you discover the right technology.
Transformation is innovating and redesigning through prototyping. Transformation is not traditional process innovation, which lacks technology expertise. Transformation is also not traditional tech development, which lacks business focus.
Today, transformation is an activity that blends various tech and non-tech elements purposefully to achieve an organization’s strategic objectives. Such an integrated effort identifies what tech elements to implement (or purchase).
The discovered tech elements could be used internally or by customers or others. It could be a single piece of tech or two or more tech elements. It could be a traditional software application or today’s digital tech or some combination. An important point here is, tech discovery happens from within a reservoir, which is already predicted to have the potential to generate strategic outcomes. This sequentiality ensures that organizations don’t invest in wrong or non-strategic technology.
Have you finished discovery using a systematic method? Then it’s time to design/prototype. Going through a strategy-driven discovery-then-design approach ensures that your initiative is strategic.
This article was first published at CIO.com, Jan 30, 2018