Tag: Front ends

  • Why CDO’s last only 18 months

    Why CDO’s last only 18 months

    While working with one of the big five consulting houses on a project, they revealed data that the average Chief Digital Officer (CDO) lasts only 18 months in a South African corporate. Its one of the reasons why digital really battles to build momentum in companies and solving the problem is a tricky exercise.

    The lay of the land

    The first challenge is the lay of the land. Corporates will generally have legacy and disparate systems. Whether digital teams are fragmented across divisions or consolidated centrally, both scenarios come with inherent challenges. Then there is the challenge of whether to introduce new tech or rebuild old, dysfunctional systems. The former merely adds to the layers within the business and the latter task of rebuilding systems seems like a grudge project, which is hard to secure budget for.

    And practically as an executive, the CDO is often faced with a dilemma: how do they shift the needle quickly enough to show results before their CEO, the executive and the board start to get concerned about the pace of digital advancement within the company.

    In fact, its such a difficult exercise that the consulting house recommends to their clients that if they really want to build a digital business, they do so on the side from the ground up and then decommission the previous business and move people over.

    What are the options:

    The new tech option is about new systems. For example, new Marketing Tech like market CRMs, content marketing platforms, analytics layers and so on.

    Master data management, 360 views of the customer, targeted campaigns and all of these good things become all the rage.

    Then there is the rebuild option or optimisation. Let’s get self-service working properly and technology to reduce call centre costs. Let’s get ecommerce working properly and get the customer the option to buy online. Let’s improve delivery options to get the lead time of product into consumers hands down to a day or two or even hours.

    Let’s bring in automation into the business and improve business processes. Let’s reduce licensing costs with optimisation around software provision within the business as well as reducing cloud costs.

    All of the above are good things but come with their challenges. Cost reduction exercises are a once off exercise (you can only optimise so much) and new tech stacks or rebuilds of old scenarios invariably run over time and budget, leaving the CFO and possibly even the CEO not very happy with the CDO.

    What’s to be done:

    1. Start with the basics

    No doubt an unpopular choice, but thinking about the customer and how they experience the business digitally is key.

    Does the customer even know what your business is, after looking at the website for two seconds? Can they find something within three clicks? Does your search function actually work? Are the digital journeys optimised and clear? Do pages load quickly? Is the value proposition on product pages clear?

    Invariably there is often a gap between digital from an infrastructure perspective and from a content perspective, with the latter usually falling to the marketing department. This leads to tension when trying to address the above questions.

    2.Think about funnel

    From a funnel perspective it starts with how people are reached on the broadest level digitally, then how are they identified and retargeted to some degree, then how are they exposed to product in a regular way and coming down to conversion, how successful the business at drawing people all the way down the funnel and converting leads into sales.

    The simple reality is if digital can impact the bottom line in anyway, then there is going to be a lot of interest, but often digital is a necessary intangible.

    3. Build bridges, look after your teams

    Front end teams, integration teams, core system teams, architects, analytics teams, business process teams, strategy and innovation teams are often disparate.

    Siloes in corporate often result in people trying to deliver value within their locus of control with the budgets they have.

    Cross functional teams and projects are seen as nice to have’s but not ideal for reaching KPIs and securing budgets for the following financial year.

    However, digital never works unless the tech stack is well architectured and well-built and teams need to be able to work together to do that. Furthermore, digital teams will invariably have difficult problems to solve and the teams need to know their strengths, understand their teammates and have high levels of positive motivation to solve problems and get the job done.

    This means understanding what makes a high-performance team is critical and helping team members to look after their physical and mental wellbeing.

    Here are some characteristics for high performance teams:

    They have defined roles and responsibilities.

    They know others strengths and weaknesses.

    They trust and respect each other.

    They know their work fits the mission.

    4. Win the support of your executive

    If the CEO and CFO don’t believe in the CDO and their vision, their chances of not being part of the statistic are minimal. And if they believe in the vision it has to be one the CDO can fulfil on, not one where the targets are not met because of circumstance or dependencies on other teams.

    CDOs should never promise something they can’t deliver and need to work hard to get buy into what they are doing and why they are doing it. It’s a difficult road to walk but a necessary one for the sake of longevity and success.

    5. Innovate

    Innovation is a tough thing to get right within a corporate space. But when companies like General Electric reduced a projected decade long project down to several months and turned it into a multibillion-dollar revenue stream as described in the book, the Start Up Way by Eric Ries, then the case for innovation becomes clear.

  • Problems, Assumptions and the Maldives

    Problems, Assumptions and the Maldives

    Building products is a simple concept with a complex journey that often finds you arriving at a destination you never intended to visit.

    Think about the products many of us use today and the simple concepts they are built on: WhatsApp lets you chat to people and groups. Cloud storage lets you store things on someone else’s server. AirBnB facilitates staying in someone else’s home.

    However, behind all these products are sophisticated tech stacks, significant product work and well thought out user journeys. What appears simple is incredibly complex.

    In this post, I’ll talk about three areas you need to think about when building a product:

    1. What is the problem you are trying to solve?
    2. What assumptions are you making?
    3. Are you going to the Maldives or a hotel?

    The problem

    As Eric Ries says in his book, The Startup Way, validating ideas by talking to people to see whether they really have the problem you are trying to solve is the first critical step. Ries poses three questions to start:

    1. Do people actually have the problem you think they do?
    2. How do they approach that problem today?
    3. Is your solution a better alternative than what they do today?

    There are some more we could add:

    1. How quickly could I test this?
    2. How complex would the process be to build such a product and maintain it?
    3. How much money do I need to get the product up and running and then scale it?

    What often happens in business is that people ending up solving for problems they have in their business, not problems the customer has.

    To illustrate this, I remember the launch of the Windows Phone by Microsoft. HTC was licenced to build a phone called the Windows Phone and Microsoft tried out their tiled operating system (OS).

    At the press launch of the phone Microsoft gave us a long presentation on why their OS was amazing and then I picked up the phone in my hand and tried it out. After ten minutes, I turned to the person next to me and said, this phone is like asparagus ice cream.

    Why asparagus ice cream you ask? Because no one eats asparagus ice cream. Its like Microsoft was trying to sell the concept of asparagus ice cream to us. They were very passionate about it, but no matter what they said, it was still asparagus ice cream.

    Quite simply the tiled user interface was nothing like an iPhone or Android and people did not take to it because the OS did not solve a problem that people had.

    Ass of you and me (ass-u-me)

    Making assumptions is the downfall of many products. Ries asks the following:

    1. What assumptions must be true for the project to succeed?
    2. How much do you really know about customers’ preferences, habits and need for a solution like the one you’re proposing?
    3. What evidence is there that customers really have this problem and will strongly desire to pay for the solution?
    4. What is known about what customers really want from the solution?

    As the old saying goes when assume things you make an ass out of you and me. Below is a great way to deal with assumptions.

    In addition to this, when I was in Moscow on business once, a supplier we were meeting with refused to take on one of two projects presented to them. When they declined the second, we were flummoxed.

    Their answer was it would take too much magic to get right. Thinking we had suddenly entered a fantasy novel, we asked what they meant.

    They said if there were more than two pieces of magic (really hard problems with no obvious solution) then they would not take it on in principle.

    These kinds of mental leaps are often made in product development. Products with around 60% of the detail and some good planning often have a couple of massive unknowns which have the potential to become mission failure problems. They’re like icebergs, which may not appear that big on the surface, but under the water they are massive.  

    Off to the Maldives

    Defining the problem and assumptions are often wrapped up in how we think about product development. Talking to several clients who want products built, I was reminded about the concept of going on holiday. When people describe their favourite holiday destination, they often describe the area they love so much – like the Maldives.

    What they battle to do is describe the hotel, why their check in experience was so good, why they liked the room and the great bar down at the beach.

    These are in fact that nuts and bolts of what made their package deal to the Maldives so great, but unfortunately while the hotel business may look simple, there is a massive amount of investment, building, process and staff required to make the Maldives a great holiday destination.

    Building a great product requires understanding the problem you’re trying to solve, being honest about the assumptions you’re making and the amount of magic required and the product detail to make an effective product.