12 June 2017
Many good writers advise “show, don’t tell,” and so with software: construct enough to illustrate the most unique elements first as proof-of-concept.
When working with the principal of an organization such as CEO or Director of a division, various business ideas would need to be vetted. While one person would validate it by talking with potential customers, another question was equally important to answer: is it technically feasible?
These were companies that were often on the leading edge in their space or taking strides to get there– blue chip companies and upstarts less than six months old alike.
In a few instances, this principal would state the need for something that does A, B, C, D– go!
There’s a huge difference between what someone says they want versus what they actually need.
While “needs versus wants” is a topic in itself, our focus here is the difference between what you can articulate versus what you would specify once gaining benefit of having experienced the successful expression of the idea.
This introduces a paradox.
How can you properly specify something that does not yet exist?
How can you describe something that has never before been seen?
How can you explain a solution for which someone else does not yet know the problem exists?
Fortunately, once explained, the problem becomes apparent.
But sometimes the explanation itself is challenging.
Good writers have said, “Show, don’t tell.”
There are many facets to the explanation behind this. “A picture is worth a thousand words,” is one. Presenting an example can be an easier or more effective method for expressing an idea. Analogies, metaphors and other tropes can be efficient, even though there are limits to such comparisons.
With software development and making physical products, creating a prototype helps convey the idea of the thing such that feedback may be readily given. The developer can put the prototype in front of people, and they can point to something specific.
The intangible becomes real.
At this stage, experience has shown that the person making the original request can better articulate what is needed.
They can qualify previous discussions: confirm that this is the right path or change it based upon the new information of seeing the proof of concept.
This gives the means by which to suggest changes– actual not hypothetical, referencing facts not ethereal musings.
In the right circumstances, repeating this process accommodates releasing early and often. Several times, we went from concept to software deployed on production servers in 2-4 months, which in turn contributed significantly towards closing a deal with a substantial new client for an established company and venture capitalist approaching us at an early stage tech startup.
Echos of this approach may be seen throughout the product life cycle.
Producing user experience (UX) mock-ups is now common practice. This is an advancement beyond the earlier predominant approach of “build it and they will come.” Contemporary tools used for UX include images with hot-spots for mimicking clickable/touchable components. This permits evaluating how a person would interact with the interface.
This, in turn, makes for stronger supporting evidence that people actually understand your new design than by merely talking about it.
Do the hardest bit first!
The second half of this principle is that it’s important to begin the process with the most challenging pieces first.
If you’re going to fail, fail quickly so that you may more intelligently begin again.