The payoff of a customer-centric approach to software and digital product design is substantial and long-lasting for both companies and their customers.
— Alan Cooper
In the previous post, I introduced a simple flow model and suggested that the most important part of the Software Development process is the part related to interaction with the Customer. I will continue to build on the model – let’s first add one small component to signify the delivery of finished product back to the Customer:
This is important because it identifies the relationship between the Customer and the Product Development team as bi-directional. In fact, if we put that interface under the microscope, we see what passes across the membrane:
In the diagram, we can see that the Customer conveys needs and requirements. In exchange, the Product Development organization provides capabilities (e.g., functionality) or designs of features (e.g., wireframes). As well, if this interface is working well, we expect a bi-lateral exchange of ideas and feedback. Lastly, the result (we hope) is the provisioning of something of value (normally the software’s capabilities) exchanged for something of value (normally money).
I call this the “Customer Membrane” – it’s the connection point between the Customer and the Development organization [1]. In the previous post, I made the assertion that if this process is poorly done, nothing else matters.
An essential deduction from this fact is that if something isn’t visible in the exchange at the Customer Membrane, then that “thing” is not particularly important. For example, if the team has decided to use an obscure programming language in the back-end of their cloud-based solution, this doesn’t matter to the Customer. If the team changes the tool they use to track their project work, this is not visible to the Customer, so it doesn’t matter to the Customer. So let me repeat this in bold print for emphasis:
The most important Engineering work is that which is obvious across the Customer Membrane.
There’s nothing I believe more strongly about the process of building software. It’s not that Engineering work is unimportant. In fact, the performance, reliability and usability of an application are of utmost importance (and in fact are normally vital Customer requirements) and these can only be achieved through good Engineering. But there are a lot of things that we concern ourselves with (and sometimes obsess over) that honestly don’t matter to the Customer.
In the next few posts, with just this much coverage of the model, we can analyze a few example project failures and see how they failed in the context of the model. So let’s continue in the next post with the first example. In the meantime, as always, I look forward to your comments.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] It’s like the cell membrane in that it controls the flow and bi-directional exchange between the company and the Customer.
Leave a Reply