How a Customer Crisis Ten Years Ago Helped Me Understand the Challenges of Cloud Service Creation Today (Part 1)
If you are already offering cloud services from your data center, or are starting your planning to do so, there are some key initial questions I’d advise you consider. And they’re not about the technical aspects of data center architecture! You find yourself asking “what cloud services should we offer?” and “How do we evolve what we offer today”. You may, post launch, also find yourself asking “Why is the take up to our cloud services not as big as we initially forecast?”. Before you say “aha – these are questions for service providers offering cloud services” .. I would argue that these questions are fundamental to enterprise and public sector organizations too – assuming that you intend to provide cloud services to your user community that help them do their jobs. Following one of my colleagues who blogged earlier that, with cloud services, “you need to think like a product manager”, I will assert here that there are some key lessons from product management that can help you in creating cloud services that are actually useful to your customer and/or your internal clients and stakeholders.
As you may have noticed from my previous blogs, I’ve worked in product management of both products and services for a while (since 1997 in fact, when I moved from software engineering into the “dark side” 🙂 ) …. so what lessons have I learned that may help you address the challenges of creating and defining new cloud services?
If you are starting a journey to cloud, offering services from your data center – either to internal stakeholders as in the case of an enterprise business, or to external customers as a service provider would do – you should find yourself asking “what cloud services should we offer?” … and if you are already offering cloud services, you may find yourself asking “why isn’t the take up to our cloud services not as big as we’d hoped?”
My story around this is very clearly etched in my mind: it really was a “light-bulb” moment in my product management education. I was at a meeting with a customer at their R&D labs.
It was the 4th or 5th such meeting around the product (which so happened to be an Element Management System (EMS) – a type of network management software application. I wasn’t directly responsible for this EMS, however I had been involved in one of the early requirements meetings. I remember watching as a senior product manager from Cisco, and a representative from the customer (who I will now call “the customer”, although later I recognized that he was only one), reviewed the Product Requirements Document (PRD) – the document that specifies exactly what the product should and should not do – and, page by page, signed off the document as being exactly what the customer wanted. I was relatively new to product management then, and wow, this guy was a senior product manager, this was an impressive process, we need to start doing this in my team, and this must be the way to do things .. and so on. I was impressed!
And so my lessons began ….
Anyway, time went on, and the product was developed and delivered, and since I was based close to the customer, I was called on to help when the product clearly wasn’t meeting the customer expectations. Sure, there were a few quality issues after the first release or two, but these were eventually ironed out. Yet the customer came back and reported that his operations team still weren’t using this EMS. We went through 3 or 4 meetings, where spreadsheet after spreadsheet of feature requests was brought back to us by the customer, with the consistent message – “if you could implement some of these features, we would use this”. And so it went on. And still they didn’t use the EMS.
Time passed and we were back at the customer labs, for another meeting. The primary customer contact had organised for us to meet the operations manager, whose team were the target users. The ops manager rushed in late, and what he said next really concisely communicated what he really needed: “Sorry” he said, “we’ve just lost an Internet PoP [Point of Presence, or Central Office] and our network is at risk of collapse from the sudden increase in web traffic. I’ve only got 10 minutes to spend with you, sorry for dragging you here. I really don’t like you guys”, he continued, “I can’t upgrade our network because of you”.
In one sentence, he described his problem. And the EMS, while it satisfied many of his “requirements”, didn’t solve his main operational headache sufficiently. The EMS did have some software download features to help with network upgrades, but they didn’t support the large scale operational procedures this customer used to upgrade their network in a robust and cost effective manner.
This was a key moment in my product management learning and experience – think customer problems first, requirements second – and indeed helped my team and I re-think our approach to the market completely (and subsequently devised a multi-award winning product for troubleshooting MPLS networks).
An additional aspect was the organisational divide between our main contact in the customer and the operations team. Basically these two individuals were in different groups within the customer, and to be honest, didn’t communicate very often. So we also missed the organisational silos that can – unfortunately – happen in large organisations.
This brings me to one of the fundamental lessons of product management – the “tyre swing” analogy below – which is as relevant to cloud service creation as it was to my example above. And I’ll discuss this more in part 2 of this blog!
In the meantime, if you want to find out more on Cisco Data Center Services and how we can help you develop and implement your cloud computing strategy, please check out our Cisco Cloud Enablement Services – and (of course! 🙂 ) have a read through some of my previous blogs.Tags: