When building enterprise software products, the most important influence on how that product is built and delivered is whether the team building it understands customer context and has customer empathy.
To better understand this, let’s first discuss the difference between customer context and customer empathy.
Customer context is the set of conditions that define what the customer can and can’t do. That context changes over time and is never static. Internal pressures that can modify the context include leadership changes, profitability, reorganization, and large scale historical successes or failures, just to name a few. External context modifiers can include changes in regulation, changes in customer expectations, changes in the competitive landscape, etc. It’s unlikely that customer context changes quickly. Instead, it changes slowly over time. Context is empirically assessable, but understanding the impact of context customer behavior isn’t necessarily easy. Take a look at industries like defense, health care, and financial services, and you’ll understand exactly what I mean. There are a huge number of regulations that define things such as where data can go, who has access to it, what records need to be kept versus discarded and so on. The conditions that define what a customer can and can’t do in these industries are as complex as any, which have a drastic impact on context.
Customer empathy is having the ability to understand how the customer feels within their context, and consequently, what behaviors one might expect from a customer due to their context. Typically, the ability to truly empathize can only be acquired by having played the part: patients who become doctors. Some brilliant people defined the technical and operating architectures at places like Netflix and Facebook, but they got to do so in a ground-up fashion and their emotions and behaviors are not consistent with the emotions and behaviors of those in technology inside a traditional, more heterogeneous enterprise. Those coming from a web-scale only background have little empathy for the context and conditions of their peers in other industries.
Mapping to customer context is critical for adoptability, scope, and value creation. Software that doesn’t map well to customer context tends to be impractical to implement, or can function only in a very narrow scope. Both of these outcomes knee-cap value potential. Usually if a product fails to map to customer context, it’s because those who built the product lack customer empathy. The product builders don’t understand the customer’s inherent and hard-to-transform conditions, and they build software for the expected end state rather than software for the journey to the end state.
Product builders often predict a future customer context without acknowledging the current context. I can tell you from history that’s bad math. The customer won’t buy it as a long term, sustainable solution. How do you build a company that doesn’t fall into this trap? Hire the right people.
It turns out that building a team with people who have empathy is the most important thing one can do. You must find teammates who have customer empathy or a keen, learned understanding of customer context. This team should have the ability to build software that is adoptable in-context by the customer, resulting in meaningful and immediate value generation. How do you build a team with empathy in enterprise software? You have to be part of a community that has customer empathy as an inherent quality.
This is one of the reasons why Apprenda is headquartered in New York and has a large office in New York City. The density of Fortune 1000 customers in this area is unparalleled. The labor pool is filled with people who have customer empathy because they lived the context. They know what to build. Our DNA is the customer’s DNA.
At some point, we were the customer, and we hire many people who spent time in the customer’s shoes. It gives us context and empathy, and it helps us build products that don’t live in the lab, but instead, live in the context that defines the customer’s reality. In my opinion, there’s no other way to build enterprise software and no other place to do it than New York.