Part 2 – How a Customer Crisis Ten Years Ago Helped Me Understand the Challenges of Cloud Service Creation Today
In part 1 of this posting, I related a real-life experience of mine, where I learned that customer problems were often a better source for product and service definition than formally stated customer requirements. I’d like to take this discussion further, via a concept in product and project management called the “tyre swing”. And I’ll make the case, as you think about the definition of new cloud services, or think about purchasing cloud services from a third party or indeed another part of your organization, that the “type swing”, and my experiences I outlined in part 1, should help you develop cloud services that are more likely to meet the needs of your stakeholders and/or customers.
OK, what is this “tyre swing” analogy. I first came across this in a class in software engineering over 20 years ago (showing my age here!). So it’s not new.
This is a classic diagram many of you may (should!!) have covered in software engineering and product management education classes, and it illustrates the mis-conceptions that can happen when trying to define product and service requirements. I believe this is one of the most fundamental lessons for any product manager – certainly in the case of my customer visit I described earlier, it was for me! The lesson is that all key stakeholders often have a different view of what the customer requires, or more precisely, needs. Indeed, even the customer themselves sometimes doesn’t understand what they really need. So …. what is my message to those of you thinking about what cloud services to offer your end users: really understand who your target audience is, understand what they are doing today that could be done better, and understand what problem you are solving for them when you define this new service. Consequently, you are less likely to have a service that fails.
My day at this customer was a clear example of “tyre swing” in action: the Cisco product manager had an opinion on what the customer wanted, the customer “lab guy” had a different perception, as did the customer operations manager, and again, I had yet another understanding. I’m sure many of us will have experienced these silos and disconnects in our working lives.
So … what are the key lessons from this story that will help you define next-generation cloud services that meet customer expectations and help solve their most pressing business challenges:
- Don’t just ask “what are your requirements” to a customer or IT business unit stakeholder – start off by asking “what business problems are you trying to solve and how could we help”.
- Try not to bias the discussion on requirements, or make implicit assumptions. Bazerman’s book is a good read on the subject of bias, and how things can go wrong, in managerial decision making. Everyone has a natural bias, and personal agendas – let’s be honest – are not uncommon. Such bias can influence our understanding of the customer requirements, and this is often the reason for so many variants in the tyre swing scenario. For example, a marketing person may think that some whistles and bells are key requirements (since they may help sell the cloud service), and an engineering manager may downplay some requirements (because other requirements are perhaps easier to implement).
- Be careful when you go to a customer and (first) ‘tell them’ what are the key features you are thinking about adding to your cloud service. Again this may bias the discussion away from the real customer need. So my advice is to listen first – ask the customer what their key challenges are.
- Don’t assume that your main contact into the customer is the true source of requirements. He (or she) may be, equally, he may be way off base and have his own misconceptions of what is needed. Make sure the target end user is involved in the requirements loop for your cloud service somewhere.
- Validate your requirements with the target user. This really means in my view, actual quantification of the benefits. “Cool” features don’t count as this quantification. So make sure your proposed cloud service feature really adds some value and helps the customer solve the problem substantially faster, in their environment, at lower cost, with the skill-sets they have available. Measure how your cloud service solves this problem, so that you have real proof points that your cloud service (for example) improves productivity by a significant metric.
In Cisco Data Center Services, we are not only focused on helping customers design architectures for cloud. We can also help you construct a business case for your cloud project. And – sometimes working with our excellent (my opinion, from my experience of working with this team) Cisco Internet Solutions Business Group, sometimes with our own consultants – we advise customers on how to define new cloud services, how to analyze their market needs, and how to understand the needs of their IT stakeholders. In fact, in a customer cloud workshop I attended earlier this month, the customer started to conclude that they should appoint a “Cloud Services Product Manager” to ensure they met their business unit needs. Cisco Cloud Enablement Services can help you from concept through design and implementation, into ongoing optimization and evolution. So please do get in touch if you need help to think through your strategy and service options for cloud.