There are many flavors of “enterprise” when we talk about it in the design world. A common flavor is one where the buyer is not the user. An oft given example is the employee of a large organization (heck a small one) seldom gets to choose their own application for how they manage their relationship to Human Resources.
Traditionally digital product designers have done a pretty good job of taking on contexts like this by observing how employees utilize existing systems, do usability testing of suggested designs, survey administrators and employees alike about their long term use of these systems, etc. All great processes and help bring quality to the designs we conceive and produce.
Ideas from Lean Startup have been seeping ever slowly into the world of enterprise. Mostly through misappropriation of terms like “minimum viable product” (MVP), or as a reinforcement of existing cultures that put cheap and fast over good and valuable. But at its core Lean is an incredibly powerful concept for any organization to take on. For me, the primary value of Lean is not the MVP, but what the MVP represents as a simple and blunt tool — instrumented learning as an organizational imperative. With that Lean’s focus on proving the “value proposition” of any suggestion in the market itself, aligns almost perfectly with the major framing of service design around the concept of value co-creation between service provider and service consumer. Further, value co-creation can only be evaluated through the creation of co-created and co-experienced prototypes.
On the one hand, Lean experimentation especially for Software as a Service (SaaS) software providers, or internal enterprise tool providers, makes perfect sense. I can create a hypothesis, formulate the create experiment, and run it in near real time against any subset of people without impacting all of my customers. If I instrumented my system well, I can even do these calculations against regions, market verticals, market sizes, etc.
Sounds great, right? It is pretty great, except for one thing — This actually isn’t often measuring the full chain of value being provided. I can find myself changing things that in the end don’t provide any value to those who require it — the businesses who employ the people buying and using these systems.
How can we know this unless we measure against the things that these businesses value? How can businesses value what we are offering unless they can understand the possible impacts our hypothetical systems can have for them?
The problem is that the “user” in the Human Resources case above is not actually where value resides. Nor is it with the administrator of the service itself. It plainly resides with the head of Human Resources itself. They own the metrics that determine value within the organization. In my world this gets even more complex as it does for many people who are working in infrastructural and utility level services, or in organizations that have an eco-system of value-added resellers or other types of partnerships.
So imagine you are a designer for an Information Technology (IT) product and service provider. You make computers and everything that goes with them such as software, storage, network appliances, and have done a great job so that they fit nicely together in data centers that you manage around the world. You also provide consulting services to help customers architect and deploy solutions — soup to nuts. What does the value proposition chain look like here?
The points of engagement
The Buyer: Usually is a Chief Information Officer (CIO) or Chief Operations Officer (COO) or similar type person. Value for them to put simply is to provide their internal customers IT systems as efficiently as possible. Their highest order or priority is usually measured in cost based. Notice that “value created” is not part of their value proposition because most often a CIO’s organization is 100% considered a cost center with no expectation toward creating value.
The systems they buy, develop, deploy are usually generic in nature and not meant to serve any particular single purpose. They need to be ready to serve all the business units and all the types of applications.
Central IT Administrators: Simply put make sure that everything central IT says they are going to be responsible for, runs. There are a host of people under this. Their main value measurement is usually around what is known as Service Level Agreements (SLAs). If they can stay within them, they are doing their job GREAT! the SLAs are negotiated. But they are considered highly valuable by both the CIO and the Business Unit IT Administrators.
Central IT application developers: Often even central IT needs to build and manage the services they make available to either everyone in the corp or as the platforms they make available to other business units. How these folks are valued and measure their own self worth is a tricky business. Every organization measures engineering resources quite differently and as for own self-worth it gets even more complicated.
Sometimes there are even “end-users” of what is created and thus we could end our value proposition chain here, but the chain still keeps going.
The Business Unit IT Administrator: They are the CIO’s primary customer. They are tasked to supply their lines of business (LOB) with the tools and system they need to be productive. They interpret requirements against what central IT administration makes available to them, or go to outside vendors if they are allowed to and sometimes themselves become the Buyer.
The Business Unit IT Operator or Developer: These will most likely be those who use any infrastructure administration tool the most. they serve as a link between the the system and those who are consuming it most directly. In essence, if we were to convert the system into a consumer project, these folks would be the producers of a consumer product.
Consumers: These folks quite honestly are the ones creating value for the organization. Despite the fact that they are called “‘”consumers”, it is why they are consuming that is most important. And in some way shape or form these people are either adding revenue or reducing costs or helping the organization do so in other ways.
But value doesn’t stop at the point of consumption …
Line of Business (LOB) Manager: the LOB Manager directs consumers and guides how their use of a system brings value to the organization. They are usually the front-line holders of the metrics that matter above them.
LOB Owner: Usually this person has a C in front of their title like CMO (Chief Marking Officer) or COO (Chief Operations Officer. Maybe they are a high level VP, like a VP of Human Resources. In the end, this person owns the success or failure perception of any given collection of IT solutions. They are in service to the part of the business that they own.
So in my mind this value chain looks like a parabolic arc where value understanding increases towards the bottom and value measurement and evaluation happens going up the other side.
In your enterprise organization, does your team understand the full value proposition chain for their offerings? How do you address the full chain of value opportunity, to value consumption, to value understood/achieved? When you’re doing experiments are you measuring the right part of the value proposition chain to validate if value is truly being created or not?
I don’t have answers to these questions as I’m trying to figure this out myself. But I do know that unless we answer these questions we won’t really be able to apply lean and similar hypothesis validation methods to the complex Enterprise.
We didn’t even get into contexts where Value Added Resellers and other types of partners are in the enterprise eco-system.
I would love to chat with others who are dealing with these types of complex value proposition chains about how we might develop methods (or maybe you already solved this) to validate hypotheses across the entire value proposition chain.