The CLEAR Method: Solving with Process vs. Solving with Product

Several years ago, my college friends and I decided to take our adoration of Big East basketball to the next level and join a fantasy sports league.  The only problem?  A fantasy sports league for college basketball didn’t exist.

As fate would have it, we started the league through Excel (which was a familiar tool for my financier friends).  Over the course of the first season, we learned that transferring files back and forth was a pretty lousy experience.  Plus, it was a lot of math.  Plus, it wasn’t cool.  So we went all 21st century and brought the league to the cloud.  Being the only Computer Science major in the group, I stepped up to build out the site.   Over the next year, the website evolved and eventually my customers – again, some of my best friends – clamored for trading functionality between teams ("I’ll give you this players for these two players").  So, I spent several weeks between seasons building trading into the site.  By the start of the season, the functionality worked beautifully.

The next year we processed one trade.

In hindsight, it would have been zero-effect to the league had I delivered this message to my friends: “Feel free to trade players offline over email or phone or carrier pigeon, etc.  Let me know the details and I’ll process the change by hand.”

In my professional career, I often come across forks in the road where the product team needs to weigh two options: building a new toy vs. the vapid act of manually performing the same task.  For instance, should we offer that deep dive around analytics or have Operations compile the report ad hoc?   Should custom billing options be permissible through product or done manually by Finance?  Do we build that really neat integration point or just rely on the customer to transfer the data on their own?

Below are five factors I’ve found to be helpful when making this decision.  I conveniently acronymized this into the C.L.E.A.R. method.  Hopefully, this method will bring clarity to your product decisions too.

Cost. Of course, cost is a (if not the) big driver here.  First, there’s a development cost to building the feature.  Then, there’s a cost to maintaining the feature.  Finally, there’s a cost of potentially removing the feature from your product in the event that it doesn’t work out.

On the flip side, manually completing the same task isn’t free either.  Resources are needed, training will likely be required and there’s always the opportunity cost of what the organization could have done with the same resources.

Learning. How understood is the problem you’re solving?  For a product in its nascent stage, the customer needs may need some fleshing out.  A manual process in this case is more malleable to experiment with it before it’s built out in code.

In the same vein, customer demand is another metric that can be learned manually before building it into the product and utilizing resources toward potential throwaway work.

Experience. Will the manual process be transparent to the customer or does it affect his/her experience?  If the latter, what percentage of the customer base would feel this pain and how often?  Of course, teammates are as valued as customers and their morale needs to be considered.  Will performing these tasks manually sink the spirits of whoever is tasked with doing the work?

Agility. The key to iterating on any product is a team’s ability to effectively iterate on a product.  Realistically, roadmaps are jam-packed with new features, improvements, tech debt, nagging bugs, etc.   These demands are driven by the market, management, investors, analysts and the sales rep who needs a feature because … well … they already sold it.  If you’re planning on utilizing a manual process for the short-term, then be realistic around not getting back to productizing a manual process as soon as you would like.  Automating manual work can often can be deprioritized when a process is perceived to be working just fine.

Risk.  Finally, and perhaps most important, how much risk is involved?  If you’re relying on human hands and eyeballs to manage sensitive customer data (for instance) then maybe it’s worth productizing rather than building risk.  If you’re leaving critical workflow items up to a customer, manual intervention might be a better option.  Make sure your bases are covered and that the organization is covered in the decision you’ve made.