As engineers and creators, we sometimes get hyper-focused on the final “utility” value of the work we do. In essence, the only thing that matters to us is whether the code does the work that the user wanted it to do, well enough. And this is our perceived value, what we define as the improvement in the operational efficiency of the process we are encoding.

‍

‍

It is true that ultimately, the value of the work we do, is based on whether it makes life easier in some way for someone. And that person is then going to compensate us for that convenience. For us at UniQreate, being in the world of data extraction automation, this translated into whether we made it super-simple for our customers to just start using the product. They needed to be able to just upload a document and start the data extraction process.  And soon after, realize the benefit of getting high quality data that is ready for their business processes to use.

‍

In taking this view, we forgot that value in the real world needs to be translated into economies of cost, scale and profitability, for it to be used in decision making. A customer should not have to deal with the technicalities of a solution, just the economic advantage it creates for his business.

‍

As customers consistently pulled us towards this realization, it felt like we had been hiding away the true economic value of our own product. And we had forgotten where we hid it! (Just saying that for dramatic effect)

‍

Real Economic Value

‍

‍

Once this became clear, it was evident that we needed to highlight, in a fundamental manner, the economic value we were generating for our customers. The shift itself however, was not as easy as it sounds. In some ways, we needed to look at our product with a critical eye, the way a new customer would and evaluate it with the objectivity of whether it makes business sense or not.

‍

As creators of a product, this is sometimes a difficult thing to think about. We are so invested in what we have created that such a critical view of it may seem superficial or even unnecessary. We are also prone to fall into defensive thoughts; “my product makes life easy for my client, so that is what matters!” or “my product does what the client needs and it does it technically well”.

‍

So how do we avoid falling into these traps?  Well, the very first thing to note is that this critical view of our own product, is a virtual activity happening in our own thoughts.  Thinking these things does not immediately change the reality of our real world.  So let go of any inhibitions about digging deeper into the challenges the product creates for the customer (yes, in creating a solution without understanding economic value, we may inadvertently end up creating more complexity for the business of our customer). Remember that the deception caused by these inhibitions is self-inflicted.  All that is needed here is some courage and some faith.  To know that regardless of what we have built, there is bound to be some associated economic value and any exploration of it we do, will tell us how to enhance that value.

‍

Opening Questions

One thing that helped us is to imagine that we were a customer who had a problem to be solved and a limited budget.  How would we then look at the product?  Utility is a factor but beyond that there is a cost constraint.  What would we look for before we had to pay for it? What would we do if we decided to limit our budget and time even more to make a decision? How would we decide? Asking these questions as a mental exercise and articulating the answers helped.

‍

‍

Notice, how none of these questions are actual operational questions, they are all business questions that a decision maker would ask. Separating ourselves from the utilitarian view of the product helps clarify some of these ideas.

‍

So in our case, here is what we worked out for our product:

We asked ourselves, If we were a company in the business of dealing with data that needed to be pulled out of documents, what would be our main economic challenge?  We could either do it through technology or human effort.  Either way, there is effort required to understand the document structures and formats and also to transfer that knowledge to teams who can then complete the job of extracting the data. Effort implies time and cost expenditure.

‍

And how would we evaluate such a product?  Getting into little understood metrics of accuracy, precision, F1 scores, etc, which are great conversation pieces in an intellectual discussion, does not provide clarity on economics, at least not directly.  Would we be able to come up with a new metric that allows us to connect with the economic benefits of using the product?  How do we compare or assess other products in light of this idea?

‍

If we spend too much time just understanding these ideas of economics or technicalities, we would be unable to move forward with our own core business objectives.  How much time do we really want to spend on just identifying and on boarding a new product?  Especially when it has economic implications for our own time to market.

‍

So the real consideration is, what are the costs associated with the work of preparing the data for our use? It could be the direct tangible costs of technology, people, training and infrastructure. It could also be the intangible costs like the depreciation in the value of the data over time into the world outside. It could also be the cost of having errors in the data or in case we were able to detect these errors, the cost of identifying them through re-verification and fixing them. Such corrective measures could easily multiply the cost of actually getting the data out of a document.

‍

The economic value generated by the product is then the savings on the process costs that exist in its absence. The combined cost of technology (acquisition, setup, training), people (time utilization, skills, scaling), infrastructure (setup, scaling, maintaining), time (between document acquisition to data readiness), errors (detection, identification, investigation, remediation) and growth (cost of exploring a new data use case). If each of these aspects were brought down to its bare threads, the savings would be exponential. Simple calculations can attribute to this fact.

‍

Conclusion

This first iteration, although not perfect, yields a direction for moving forward. After all, users’ perspectives and worldviews may be different from our own. However, this “mindshift” in the way we view our own product also allows us to change our conversations with clients.  Asking more open ended questions, exploring the economics of their business rather than its technical challenges, Identifying value, rather than problems in the areas of the business where we are offering our solution.

These ideas then become a way of keeping these conversations going with the customer in a more mutually beneficial direction.  Knowing the customer is important but even more important is to understand how to enhance these conversations that help us know them in a value oriented manner. Having this new perspective to guide us in the product journey can be a really effective tool, if we can keep to the central idea of the mindshift - “Engineering for Economic Value”.

‍

#uniqreate #uq #dataextraction #economicvalue #knowyourcustomer #gettoknowyourcustomerday #dataextractionautomation #operationalvalue #mindshift #business #data #technology #customerconversations #productjourney

‍