Episode 6: “Always pass on what you have learned (AAN)”

Episode 6: “Always pass on what you have learned (AAN)”

I have to acknowledge and thank my predecessor at Vocus, Tom Sykes , for a number of things but one I reflect on often is the format and run sheet for our weekly team meeting.

When I started at Vocus, getting the weekly team meeting right blending personal engagement, professional update and recognition was high on my priority list. Looking at the format as left to me by Tom, later refined by André Hamman , I could find in no way to actually improve it.

We start every meeting with personal engagement through a “theme”. This is a topic for each of us to discuss, maybe putting up a background on Teams to bring our spiel more to life. In my short time leading the most talented and attractive product team in Australia here at Vocus, we have had some cracking themes. The recent compulsory team homework of watching “Hot Fuzz” followed by discussion of favourite cinematic moments was one to remember probably only surpassed entertainment wise by “what would be your plan to survive a Zombie apocalypse” where, disconcertingly, escape for some did not involve taking their family members with them ...

Anyway, what I am blogging about again.

Oh yeah... recently we had a team meeting theme “what do you consider your biggest professional achievement and biggest professional failure or regret?”.

Frank Sinatra style, I have had a few, but for some reason I settled on the launch of Telstra Application Assured Networking (AAN) as an example that I think ticked both boxes. The ultimate purpose of this post, (I will get there eventually) is to “doyen” you with my key learnings from the launch and ultimate demise of AAN.

Once upon a time,

After a rocky but ultimately successful first decade of the new millennium being involved in the launches of TPIPS, GWIP and Connect IP, our Telstra team pondered “what next?”. This was not a painful exercise but rather one performed with the full bellies of revenue and profitability that good decisions in the prior ten years had afforded us.

Like any good product management and sales team (I was in a sales evangelical role at this point so massive callout here to product lead David Grima ), we thought we should be guided by what our customers were asking for and also by what the analysts suggested the market was hot for.

Back in 2010 (as btw I think still is the case) the market was very keen on network or communications as a service, that is, the ability to flex network resources, e.g bandwidth and QoS, to meet business application demands.

This was the second time I had been involved in such an initiative. In the late 90s, Wideband IP Bandwidth on Demand blew I think many in the market’s minds (big nod to you here my friend Mr Ian Stanley ), but ultimately I think “the knob” may have come unstuck due to similar reasons as AAN. My goodness though, in 1998, that capability was phenomenal ...

So, we toddled off and by 2013 we had launched AAN. We keyed into the premise that application performance in a customer’s enterprise network was critical and fundamental launching, by routing customer traffic paths via an intelligent IP Edge (no on-premise CPE/probes etc required, cool), AAN Reporting:

Even just offering reporting, value was being delivered. For example, finding out that a person at a legal firm was draining bandwidth playing Starcraft ... In AAN reporting, we even provided voice quality packet analysis, ah, the good old days when users cared …

We quickly followed up AAN Reporting with Phase 2, AAN Policy Control which let customers schedule increased bandwidth to selected applications such as video conferencing, or alternatively block unwanted traffic, such as social media, so they could get exceptional performance from their most business-critical applications.

We feverishly promoted the value of turbo events which allowed customers “to increase bandwidth for selected applications at selected times – reducing cost as you only pay for the bandwidth you use”. Citing the Starcraft example, we highlighted also how you “could set up discard events to block selected applications from your network, for example, YouTube and social media applications”

This was all supported by a service helpdesk where our trained professionals could provide training, reporting assistance, application signature and configuration support.

Awesome, a career highlight undoubtedly. We delivered what customers were asking for, what could go wrong …

This article is a pretty short and potted history of probably five years of my professional life. Memories fade but some things I think I learnt, in no particular order:

  • Ongoing investment support for a capability that in itself does not drive significant incremental revenue can be fickle. Steve Combes and I often quoted an analogy, I think pinched from Christopher Cullan from Infovista, that AAN was like the small balloon we needed to pump air into to support the bigger balloon, i.e data and connectivity product revenues. Anyone who has defended or tried to justify something on the basis of revenue pull-through or churn reduction would understand what I am waffling on about here. Every time we needed more investment, it got that little bit harder.
  • Developing a digital customer experience for NaaS is not trivial and requires constant iteration and investment to meet ever growing expectations. The minute the technology hinders you or for other reasons you baulk at this imperative, the game is over. Even the most minute of deficiency or UX issue will turn your customers away. We lacked at the time the technology to make anything as slick as the definitive user experiences of today and this ultimately led to a request from customers “rather than a portal can you perhaps just give me more bandwidth to start with at the same price”. This one phrase was ultimately a bit of a death knell, read on …
  • Any type of restriction or limitation will hurt you. Fair to say that during 2013 customers and sales were very hungry/excited about AAN. Unfortunately, enthusiasm waned as limitations in terms of product and access types were revealed. Only available on the MPLS IPWAN product (not Internet) with policy control only available on Telstra Fibre access, customers felt a solution that only worked on a portion of the network was questionable in terms of effort and ultimately value. "Rather than a portal can you perhaps just give me more bandwidth to start with at the same price”
  • Charging was complicated. We could not easily explain how much customers would pay, and therefore save, by using the on demand capability. Another challenge with the business case btw with Finance was making large investments to allow customers to control their network to use less bandwidth and pay less. Facing out to our customers, quoting the product was problematic and we had to develop tools to show customers what they could save under varied bandwidth utilisation conditions. "Rather than a portal can you perhaps just give me more bandwidth to start with at the same price”  
  • Spend more time competitor wargaming. No-one followed our investment strategy, this should have been a warning. As we launched, we felt quite pleased with ourselves, awards and accolades of no monetary value ensued and we sat proud and confident that we had developed, as a core network-based capability, something that was going to be very difficult to match. Then, no-one really tried to match AAN in 2013, 2014, 2015, waiting, waiting, Bueller, Bueller. Still committed to the cause, I remember a sensational opportunity and use case that fit perfectly in AAN’s wheelhouse. A medical imaging customer needed to burst from 2M to 100Mbps after hours to upload high resolution medical images. With 100M on demand, the customer could do in an hour an upload that with 2M may not get done by morning. We lost the bid. A competitor came in and offered the customer 100M at our 2M price. "Rather than a portal, the competitor gave the customer 100M bandwidth at the 2M price"  

Would I launch something like AAN again?

Yes definitely, and some of the capabilities mentioned above are in our development plans here at Vocus. I still believe in NaaS offering network resource agility supporting ever changing customer application requirements 😊

So, are the enterprise products at Vocus better or worse than Telstra?

I have a fondness as you can probably tell from this article for my past at Telstra, but I do value my continued tenure here at Vocus.

I am going to sit on that one leaning to the Vocus side of the fence.

Both companies do certain things very well, and some things they both can do better. To get me out of jam here, maybe I will close a long article with the simple revelation that when I joined Vocus, I learnt in a matter of weeks how they managed to win business from much larger competitors. Vocus has a clear understanding that in delivering brilliant, simple outcomes, we cannot do everything. What we do however is done extraordinarily well: never underestimate the power of great people delivering excellent customer service.

Want to learn more about Vocus?. Come and visit us at vocus.com.au. Interested in joining me at Vocus where I can dazzle you more with my “doyeness” Check out our careers site.

Note/Disclaimer: Although acknowledging a few individuals who shared some of these journeys in the article, in my posting I have missed many more. Apologies for this. Thankyou all, what a great ride AAN was

Love the reflections Craig Mulhearn - I think we provided many SD-WAN like features from within the network which were ultimately superseded by ubiquitous bandwidth and SD-WAN offers that included so much more than application level reporting. Still love the old AAN reporting stories like StarCraft, Apple IOS updates and the syncing of their iTunes lol - what were they thinking!

Liam O'Brien

Strategy & Corporate Affairs Leader | Passionate about authentic leadership, the power of collaboration, and personal development & growth | Track record of delivering strategic impact | #AndARunner

1y

AAN - now there's a blast from the past!

Andrew E Scott GAICD

Global technology strategist and executive | CTO | Product Development | Innovation | Emerging tech | Architecture | Startups | Strategy | Advisory

1y

This is a fantastic example of trying to offer a solution that saves customers money by pushing complexity onto them. The many years of work trying to get traction for LTE Broadcast could serve as a similar case study.

Crispin Blackall

Experienced CIO/CTO/CDIO with over twenty years building and leading high performing teams through innovation, transformation and change (MBA, GAICD)

1y

AAN was one of the most challenging products we launched in the 6 years I was leading the Enterprise Product Engineering Team and working with leaders like you Craig Mulhearn & David Grima helped us overcome a number or the challenges and to deliver an innovative solution. Ian Stanley and the Transport Engineering team did most of the heavy lifting but there were also quite a few scars incurred along the way. It is a great experience to learn and share not just from our successes but from all our failures, challenges and the success - thanks Craig

Mehmud Sharif

Product Owner, B2B Pricing Digitization at Telstra

1y

Love your articles Craig Mulhearn! And thank you for a walk down memory lane. Brilliant product with premise that bandwith price will stay high "stronger for longer'. While AAN was trying to save money by optimizing use of scarce bandwidth, our favorite competitor was hunting market share by adopting "bandwidth abundance' strategy. Portion control meal plan vs All You Can Eat Buffet. Buffet won.

To view or add a comment, sign in

Explore topics