Over 60 retail technology executives attended the Thoughtworks Retail Roadshow in Melbourne, Brisbane and Sydney on the topic ‘Platforms for Growth’.
We've been looking at where retail and retail technology is going, and what a modern retailer will look like. We identified four key pillars that are challenging at the moment and many retailers concentrate on.
- Contextual Personalisation: Understanding your customer deeply, across all of their interactions with your business
- Product Insight: Providing visibility into detailed product information and associated metadata to help facilitate analytics and to provide customers with the ability to find the right product for their purpose
- Seamless Commerce: Reduce pain points for the customer through the purchase and post purchase process. Customers want to give you their money, don't make it hard for them
- Unified Inventory: A holistic view of your stock, where it is, why it’s there, and how to get access to it with ease
We have found that it is helpful to talk about building a platform, rather than implementing systems, and the Platform for Growth model is our representation of this concept. But what does it mean to think about a platform rather than its constituent systems? Rather than looking at the features and functionality that each of the systems offers it is useful to think about the capabilities that these systems offer. Capabilities could be catalogue management, promotional management, pricing, or customer insights. When you picture capabilities in this way you start seeing what outcomes the platform could bring to the business.
Rather than talking about technology businesses, which implies that the product of the business is technology, instead we to talk about tech-enabled businesses. Being tech-enabled means that for your business, high-quality technology is essential to achieving excellence in the key capabilities that are at the heart of your business. We see the Platform for Growth as the glue between technology that supports core business capabilities, the overall strategy of the business and the culture around technology delivery.
In certain situations looking at your systems from the platform view allows you to think about which capabilities belong in which parts of the platform and then aligning your systems to this new view. One example of this is a large, diversified travel business that had grown over the years through acquisitions. They wanted to think about themselves as a retailer, and try to tap into all the good things that retailers can do with product insight and owning the customer relationship. The challenge was that their business operated through a collection of systems that were focused on operating the complexities of their businesses, including running and maintaining assets, rather than focussing on selling interesting and innovative experiences to customers. This was limiting their potential. Their vision was to separate operational excellence and commercial product innovation. They planned to rebuild their technology organisation to unify their commercial approach across all of their businesses with a single, group wide platform for commercial product design and sales. To do this they needed to simplify their offerings, and then bring all the commercials surrounding these products up to the group level. The capabilities that they proposed to bring up to group level included demand management, pricing, and product packaging. Providing these capabilities at a group level would allow them to easily repurpose functionality across different businesses and combine products together in interesting new ways.
It’s a pretty big vision and a very challenging task to undertake
Retail excellence and best practice. Think about what it is that thing that you do, and do well, and what are the core capabilities you need to support that.
Our capabilities model shows two orthogonal themes, retail capabilities from left to right and technology capabilities from top to bottom. We have found the capabilities model is a great place to start when understanding where your organisation is at, and how you deliver your core business capabilities. These capabilities are likely to include a storefront, commerce engine, inventory and order management.
The first thing you can do is remove channel centric thinking. Instead of having multiple channels that are composed of each of these capabilities you can separate the channels by creating new store-front capabilities for different channels. Once you do this you will start to get some interesting advantages, commerce suddenly becomes something reusable, which means that the way you take payments suddenly becomes unified across all of your different storefronts. The same will apply for inventory and order management which will mean less integration between these systems across multiple channels which can be highly problematic and lead to errors and timing issues.
The Build vs. Buy debate
One of the big questions we get about capabilities and systems is how to obtain them. There is a trade-off to make between buying and building; as a general rule buying is constraining and building is expensive. So how much work will it take and how much investment is required to either buy or build capabilities, and how would you model this? It’s best to keep your thinking away from systems-level for as long as you can, and focus on capabilities instead. If you buy in a capability, you will be restricted by what the product vendor imagined you would want to be able to achieve. If the problem you are trying to solve or the capability you need has been commoditised, and there isn’t much additional value you can add in comparison to your competitors, you are pretty safe to buy the capability and save cost.
However if the capability is key to adding value for the customer and is one of your primary competitive differentiators, in terms of a service or product offering, then the expense of building the capability would be warranted. Even though building is expensive, it makes sense when the value added is high. The right approach across your capability map is to blend buying and building where each methodology is better suited.
Linking your technology strategy to your vision
To start, you need to have a company wide strategic vision. From this you can create some high level goals and then develop these goals into a set of strategic bets. Your teams should be empowered to develop a portfolio of products to build and then drive these through your procurement and management ownership groups for validation. You then release a bunch of products, very quickly, and measure the value returned from them. This approach helps turn big vision into small bets, rapidly releases of value, and gives you a high rate of change. You can then improve this slightly by using the Lean Startup approach; capture a set of interesting data points about what people are doing and how people are using your products and feed this back into your portfolio, your approach to product delivery, and then back into your vision. Iterate on this process to refine your product and approach to products over time. This method will build a culture of continual learning and improvement, which is a great thing.
But there’s a risk with this approach. Let’s go back to the example of the travel group that had a vision to sell interesting and innovative experiences to customers. If they were to take this approach of just feeding these new product increments into a product management group across many group companies for tens of thousands of employees, where would they end up? If a new product gives you 3% increase in revenue and you repeat that three times, what does it do to the complexity of your business when it occurs across a multitude of product teams? What happens to your operations? What happens to the cost of running the business as you keep driving small incremental products into your business? This is where a broader technology strategy can be used to make sure that you are always gaining efficiencies across your product portfolio. Your technology strategy is not about saying ‘this is what you should do’, it is about communicating to your teams how to utilise your existing engine of delivery, while taking feedback, in order create high rates of change safely, maximise efficiency and reuse technology.
A good way to solve the tension that naturally exists between technology strategy and product strategy is to seek alignment through vision. It’s about taking the business vision, break it down into technology goals and bets and then feeding the outcomes into a basic lean delivery and feedback loop. This is where the product and technology teams get to interact in meaningful ways. Going back to the travel group example, let’s say that a product team is trying to launch a new campaign. The technology team can act as the advisor and can look at elements of reuse, and make a requirement around developing a framework for the airline campaign system that will also be able to support co-campaigns with hotels, car hire, and other products. With the broader technology landscape the team is empowered to build their product, and offer this to an increased set of customers. There may be conflict. The product manager will want to build and release products quickly, but may not be thinking of the long-term implications. There are no easy answers, and it’s about getting people to talk, and understand how this additional work and time frame ties back to the overall vision of the business.
Culture - how to organise your teams effectively?
The definition of a retailer is a business that buys products from suppliers, and sells them to customers, adding value along the way. To do this in an efficient and responsive way the trick is to get the technology organisation to reflect this structure all the way along the value stream. You do this by creating small ‘product’ teams with defined suppliers and customers, and provide a set of services or products to these customers. This way of organising a business is often referred to as the Amazon Model. More and more UK and US businesses, particularly aggressive tech-focused retailers, are starting to restructure themselves to look like this model. It's a big change to make. Rather than organising your business around departmental capabilities and technologies, you should think about the culture you’re trying to create and the way in which you want to deliver technology. The technology decisions will flow from the new structures you put in place.
This model is about saying that your organisation and your technology delivery are one, and the same thing. The model often emerges in West Coast US technology companies. This model can often get reduced to being called an ‘API Strategy’, however API’s are generally an emergent side effect and not the goal. Many organisations say that they are following the Amazon Model, with microservices everywhere, however in reality there are horizontal layers of Enterprise services all served out of an enterprise service bus.
The core benefit of this model is to create customer focussed products however another benefit which often occurs is the ‘accidental business’ effect. Amazons AWS, one of the highest performing units in Amazon, was an accidental business. The structure of their technology organisation allowed them to simply sell this incredible elastic computing capability that they had initially built to fulfil their own needs and meteoric growth.
A few years ago we were approached by a US airline who were having issues with their check in process and customers were complaining. This triggered the decision to create a mobile app to perform basic check in functions. Fast forward to 2016, with the help of Thoughtworks, they have a mobile app from which you can purchase tickets, check in for your flights, view airport maps and more. This channel now accounts for 1.5% of the total mobile sales in the US which is a $100bn channel, this is all sales not just airline sales. In this example the platform and organisational setup allowed them achieve what we call an ‘accidental business’. The business that you didn't expect, that you weren’t trying to produce, that emerged as an accident from the serendipity of the right technology choices, the right culture and the right collaboration between technology and business.
Each team under this free market structure should includes 8-12 people, which maintains focus and reduces the need for excessive communication. The teams are responsible for designing, building, and very importantly, running a capability.
The rules are:
- If you design it you build it
- If you build it you run it
- Every team has complete autonomy, as long as they can meet their published service levels and conform to the contract that they have with other teams
- Every team works directly with their suppliers and their customers, most of the suppliers and customers are other teams within your business
- Product management will often be responsible for a cluster of these services
- The business can pivot and change direction easily
- You've got space for architecture and technical advisory, it happens in the whitespace between teams
- Empowered autonomous teams that are incentivised to make sure that things work
- Increased levels of focus in providing service to customers, both internal and external
- A structure that naturally evolves, if a team can't find someone to use what it does, the team will break and move on to other groups naturally
Investing in your technology infrastructure
You can think about your technology capabilities the same way you think about your core retail capabilities.
The technology value stream can be broken down into two main parts:
- Technology that supports the business, provides architecture and services, self-service data, and delivery infrastructure
- Technology that can be used to build new experiences, such as customer touchpoint technologies and experimentation infrastructure and telemetry.
For example, for any given customer touch point, the experiment infrastructure and telemetry value stream will capture data, understand what people are doing, collect that, and loop it back. The focus should be on how to decompose challenges down into small parts that can be then recomposed and build up.
Above: Peter Wolter, Head of eCommerce Technology and Solutions, Otto Group (German based retailer) sharing his company’s journey with Thoughtworks Retail towards creating a Platform for Growth for their business.
Strategy, culture, technology. The three key parts to think about how to build the platform. For Peter, the key to success was the ability to sit down with the business and have them admit that they didn’t know what they should be doing next. They didn’t know what they needed to do. Technology was then able to say ‘that’s fantastic, we don’t know either, give us a week, let’s build some small things together to figure this out’. It’s this ability to be able to say ‘we don’t know, let’s be vulnerable together’ which is powerful, because when we realise this then we can collaboratively refine our ideas and find the right way forward.
Where should you start?
As a retailer you need to be looking at what your core capabilities are, what you are good at, and what your teams are passionate about. You need to think about where you want your business and culture to be, where it should be reliable, and where you need to differentiate. Once you establish this, pick a project, put together a cross-functional product team around this initiative, let them explore and experiment and create an MVP, and then use a culture of evolution to find the right path forward. It’s about empowering teams to build new products and services, offering them up to customers, learning from their success and failures, and possibly find an accidental business along the way. Hopefully it generates $1.5bn billion a year. So be vulnerable, evolve and start small.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
