Prove Features Manually

At companies, we spend a lot of time using intuition to solve problems or increase revenue. But it is rare that these features, in their first version, end up working as we intuitively expect them to. Heck, some of them outright fail to produce the desired effects at all. If hindsight is 20/20, intuition is a far blurrier lens.

It is due to this fuzzy image of the future that software is often so expensive to build. Unproven workflows or incomplete requirements lead to costly mistakes. We build in support for usage patterns no one uses or features no one wants. When this happens, it frustrates everyone involved, from the customer to the coder and anyone in between.

In order to avoid this frustration, one of the best methods i know is to prove a process manually before you commit it to code. What does this mean? In many cases, a new feature can be emulated by a human on a select group of users. Want the system to send promo emails to users? Pick some and send those emails manually. Does the sales team want a swanky new dashboard? Build it in excel and pull the data yourself.

Some will argue that this will waste people's time. I cannot disagree more. This manual execution of a process proves two things. First, we get to see if the feature is actually going to be used at all. If none of those users responded to the promo emails, or sales people ignore the excel metrics, we have saved ourselves a great deal of time by not coding it first.

Secondly, and more frequently the case, this manual process works, but only just. During the manual run, the process will slowly evolve. Maybe users who receive the email keep asking the same questions and we need to rephrase the copy. Maybe the excel dashboard isn't showing the metrics sales people need. Maybe the dashboard needs to update faster or slower than we expected. The full breadth of these changes can actually be surprisingly wide. Welcome them openly.

Because at this point, changes aren't expensive. What we are really doing here is an in-depth form of requirements gathering. Normally, when a new feature is released and changes are requested, those changes then have to be: designed, prioritized, scheduled, developed, tested and then released. When change requests happen during a manual test, the only difference is the basic requirements given to the developers.

In rare occasions, you might even find that a manual process fits a "good enough for now" niche and coding isn't even necessary. This is the best case.

When people talk about the best developers they know, many cite that they "brag about the code they didn't write". This does not mean great developers are bragging about the 10 lines of code their "clever" solution saved them from writing. The best developers understand that a lot of problems can be solved without code or with clearly targeted coded solution.

But clearly targeted solutions are rarely seen through the blurry lens of intuition. Hindsight gives us a fighting chance at delivering real value, reliably. Which is good, given that it is our job and all.

tl;dr: Manually testing features before they are built is a great way to prove workflows and processes without wasting money on development time.