This is a question that I often ask of my students in my Kanban System Design class. Sometimes we don’t really understand who our customers are and what they are asking for. We know we do work and provide some kind of service, but having a more detailed understanding of the nature of the requests and the purpose behind them will help you shape a better service delivery capability.
Many initiatives go directly to the “paying customers” of your organisation – those who buy your products & services. You may be introducing a new product or service, creating some kind of enhancement to an existing service or otherwise creating value that will flow through to revenue for your company. I used to think of things in terms of revenue or customer experience, however practically all of the customer experience items have an impact on revenue – whether it’s new revenue or revenue retention. These are often more straight forward – you get to understand who your customers are and what their needs are as it’s what your company’s purpose is based on.
There are some complications with this as well – oftentimes customers don’t necessarily come to you directly and request a new product or service. You product managers may be the source of a number of requests to develop new products or services. This is quite different from customers asking for things directly – the link with the “paying customers” isn’t direct – indeed you may not even know yet who they might be. The nature of these requests may be different in size and complexity ranging from a new product line, a new feature or capability for an existing line or some kind of minor enhancement. The workflow for these may also be different with different “learn” or customer feedback phases following release which link back with your product / services upstream flow.
Furthermore, there are other types of initiatives that often don’t fall into these categorisations. Two in particular are:
- Cost saving initiatives
- Regulatory / compliance work
Cost saving initiatives often are initiated through the CFO, a particular department head or product / service manager. In this situation, their purpose is going to be much different to your “paying customers”. That’s not to say you necessary need to forget your paying customers when you undergo this work, but the purpose and service delivery needs are going to be coming from a different stakeholder. Usually these things come into play because there is some kind of improvement that’s possible – you may be able to free up some capital to invest in other areas, you may also be able to free up people and resources to be able to serve customers more effectively. There are also sometimes circumstances where you may need to downsize or retire products that are no longer necessary.
You can start to see how these purposes and the way we deliver these services will differ from those for “paying customers”. For example, in the downsizing scenarios, privacy and sensitive information is very important because it may have an impact on your customers and staff if these aren’t handled in the correct way with the correct timing. An example of this that many of us have seen over the past decade or so is where companies with large retail footprints, such as banks and stores, reduce their physical presence and drive more towards online. This kind of approach is quite different than if you’re developing a new product or feature for a “paying customer” you might want to shout it from the mountain tops to make sure all your customers are aware of it.
Some cost saving initiatives are relatively straightforward, however others might be more complex. You may not necessarily know all of the exact causes of the cost impacts and what will be the change once you make improvements. You may need to consider some “upstream” work and come to understand where key feedback points might be to reassess the situation and make additional improvements. Thus exactly what your customers are asking for in terms of delivery services is not clear – they may understand the outcome, but not how to get there. You may also need to consider the workflow and feedback into the upstream once improvements are made, but still need enhancing to achieve the final outcome.
Regulatory and compliance work is different again. In the case of the regulatory work, there’s a government body with a particular requirement that needs to be achieved. Failure to do so may result in fines, penalties or even the cessation of the ability to trade in some cases. The relationship and requests are coming from a different group and the needs will thus be different. There may also be a legal, risk or compliance department that’s involved here within your organisation that’s driving the initiative. Once again, the outcome might be clear – make sure the organisation is compliant with the new regulations, but how to get there may not be clear. Two industries that have a lot of this kind of compliance work, finance and utilities, are often large complex organisations with a variety of teams producing various services to keep things running. Exactly which of these services may be impacted by each of the various regulatory requirements will differ based on the regulatory need.
Once again upstream comes into play – to understand which services are impacted. Keep in mind that the upstream will also impact downstream / delivery. Oftentimes in these types of organisations, there is considerable time taken in upstream to understand how to solve the problem, which may impact the class of service downstream if there are particular dates required to hit for a regulation. We often see more date driven work here – but that doesn’t necessarily mean all requests are “Fixed date” class of service. Once again, you need to understand the particulars of what the regulators are asking for.
As you can see, there are often different sources of requests that your organisation will service. Although not all of these are necessarily “paying customers”, you can no doubt recognise that many teams providing services will need to cater for the different sources of these requests. In each case they are the “customer” of those requests and you need to understand their needs and what would be “fit for purpose”. Understanding this in more detail will allow you to better design your Kanban system to respond to the differing needs.