Delivering Customer Success in times of Rapid Change

by Emily Rowntree, Head of Customer Delivery & Strategic Accounts at Trade Ledger™

Our agile delivery approach is built for, and excels in, an environment of flux

A dependable partner makes a world of difference during extended periods of uncertainty.

We know this first hand because of the specific market challenge we’ve chosen to tackle: developing a versatile platform that brings the Open Finance revolution to Corporate Banking. This implies working with banks and lenders under rapidly evolving conditions — our specialty.

It was clear for us from the beginning that delivering predictable performance under shifting conditions requires a strong, agile framework; and one that can enable full remote delivery if necessary (as now). So, as Trade Ledger™ grew over the last couple of years, our delivery methodology matured with it.

We wanted to share our experience with developing a sustainable and tested ability to get things done because, for the foreseeable future, the banking industry will deal with accelerated change the likes of which we’ve probably never seen before.

Weathering deep transformations and capturing the opportunities they surface also involves setting realistic expectations around how this agile approach works. This is why we’ll also break down common misconceptions along the way.

We hope our approach helps you discover a way to keep up and effectively deal with changing circumstances — and even thrive under them.

Short cycles, cumulative outcomes

At Trade Ledger™, we follow an agile approach to deliver cutting-edge Lending-as-a-Service (LaaS) technology to banks and lenders. First, we have a dedicated Customer Delivery function — a small but growing team spread between Sydney and London.

Internally, our engagements go through two distinct phases:

1. Design — a 4–6 weeks project whose outcome are validated prototypes and user journeys
2. Development — a 3–4 months engagement that results in iterative features that layer on top of our core product offering.

In recent months, as the number of engagements ramped up, we’ve seen a huge value in this design-driven approach to development. Here are some of the finer details.

Modular, design-driven product strategy

Our Design phase starts with Design Thinking workshops.

Over 2–3 days, our experienced Customer Delivery team facilitates a series of interactive workshops with clients using Design Thinking. During these sessions, we use post-it notes and whiteboards — or virtual equivalents if the sessions are online — to deeply understand the end-users’ goals and pain points. They also serve to gather requirements and knowledge from key members in the client’s organisation.

Based on these insights, we redefine problems and design user-centric solutions. But there are a lot more benefits to this hands-on method than is visible straightaway.

Create and validate solutions with real users. This approach gets end-users and other key stakeholders excited about how the project will solve their pain points. It builds momentum and makes innovation approachable.

Get high-quality results with minimal risk and no waste. The workshops get decision-makers to differentiate between must-haves (business critical features) and nice-to-haves (bells and whistles). The difference between what can be done and what should be done becomes clear.

Once the team aligns around clearly defined features to validate and implement, we move on to wireframing.

The Design team uses interactive tools such as Marvel to share ideas and drafts and capture feedback. Our customer receives a clickable prototype that helps them visualise all the elements included in the product and how they work together. This process makes it fast and inexpensive to accommodate feedback and make changes and it also guides both parties to bring the project to life.

Prototyping enables both us and the customer to get clarity on scope quickly:

• our customers can determine if the product features and flows meet expectations
• the Trade Ledger™ team can validate the requirements before they go into development and identify key areas that require additional research before implementation begins.

Along with wireframes, we also create a number of other artefacts around user journeys, such as prioritised recommendations and a service blueprint. We work these into a program plan for implementation whose goal is to align stakeholders on what and how Trade Ledger™ will deliver.

‍

‍

What’s more, the Design phase also makes it easier for large banks and complex organisations to engage in parallel activities that push innovation into practice. For those with cumbersome vendor onboarding processes, our agile approach means Design can progress while required sourcing, legal, and IT flows move alongside it.

User-focused, design-driven development

Turning business knowledge into scalable products for banking organizations is what we do during the Development phase.

These projects tend to unfold over a maximum of 3 to 4 months. In fact, we won’t take on a project that we can’t deliver in under six months. The reason that in, the digital world, the pace of change is such that if you’re not moving forward, you’re going backwards and 6 months is too slow for a project. We need deliver, learn and enhance.

At Trade Ledger™, development is streamlined and iterative. We can get customers up and running in their sandbox environment quickly. Our development team deploys monthly releases to this platform, enabling customers to preview new features and test them with real users to get timely feedback.

Equipping Trade Ledger™ customers with this preview environment is a great way for us to get real-time user feedback and make customer-validated decisions which help shape our future product.

As their prototyped product features materialize, clients have a full overview of the process and play an active role in it. This bridges the common disconnect between customers and product decisions and avoids the risk of missed opportunities, long-overdue launches, or failed products.

Our Customer Delivery team helps Trade Ledger™ clients confidently navigate the stages of new product development with measurable results. To go into this process with clear expectations rooted in reality, let’s see the truth behind three of the most common myths around customer delivery.

‍

Customer Delivery myth-busting

Myth no. 1: “Iterative delivery means we can carry out User Acceptance Testing after each sprint.”

One of the advantages of the Agile methodology is the ability to deliver high impact items iteratively. Tight feedback loops are particularly important, especially in the early stages of product development. Getting new features in front of our customers quickly is crucial in fast-moving conditions such as the ones we’re currently experiencing.

However, iterative development doesn’t automatically imply that features are ready for User Acceptance Testing (UAT) right away.

As I mentioned, at Trade Ledger™ we deliver features to a preview system, where the customers can view, test, and provide feedback on them. At this stage, the features may still have (non-critical) bugs or may not be aesthetically polished. However, it’s valuable to get their hands-on feedback as early on in the development process as possible to help shape the feature with the right focus.

UAT comes later, when the product as a whole has been tested internally, getting it ready for the customer to carry out formal user testing to confirm acceptance of the product.

This may seem like a nuance, but it’s actually an important differentiator for setting realistic expectations with customers around the timeline of reaching the "finished" product stage.

Myth no. 2: “We have hot-desking so we are agile.”

This is a particularly persistent myth in many large organizations that don’t want to be labelled as outdated or old-fashioned. They often lack a true understanding of what it means to be agile, which leads to a scattered application of concepts.

The result of a part-agile part-waterfall organisation leads to confusion and a lack of buy-in from colleagues.

For example, customers that are new to agile or that have been disillusioned by vendor deliveries in the past, tend to want to know exactly what they’re getting before a project starts.

In many ways, this reluctance to iterate and flex priorities along the way goes fundamentally against agile principles. However, we understand where they’re coming from.

This is why, at Trade Ledger™, we introduced the Design phase as part of our core delivery methodology. We aim to strike a balance between delivering in an iterative, agile fashion, and adhering to large organisational requirements around governance and process. It still requires a mindset shift from customers and the ability to adapt, change priorities, and course correct. But, at the same time, it equips them with a close-to-the-finished product prototype quickly.

Myth no. 3: “You can’t succeed if you don’t have business analysts.”

At Trade Ledger™, we do not employ business analysts (BA), but we do have product owners (PO) on the team. In our approach, domain-specific knowledge, typically and more traditionally borne by a BA, is essential to the role of product owner.

Often, the roles of business analysts and product owners overlap. In my view, it shouldn’t matter how these responsibilities are segregated as long as our team is equipped with the skills and knowledge fit for the challenge we’re tackling.

For example, Trade Ledger™’s Product Owners often have prior BA experience, which they leverage in their role as they channel the customer’s voice.

Walking the talk

I don’t imagine our delivery approach at Trade Ledger™ is radically different from others. And that’s the point!

We’ve taken industry best practices, war-stories, and lessons learned to evolve the way we deliver projects. In a similar way to how we advise clients to be open to iteration and course corrections throughout development, we are also amenable to change our internal processes. Whether that’s refining our templates or redefining our workflows as the team grows, we aim to promote a resilient internal culture.

The one thing that remains unchanged is our ability to deliver high-impact, value-adding products to our customers and get things done.

‍