I was personally very happy to see in 2018 the development of the blockchain agenda. For example, what started as a joint venture between IBM and Maersk, seems to recently have made its pace towards a more organized approach to tackle the trade digitization agenda with Tradelens, which announced in August that they had 94 companies in its early adopters program [1]. Check out BitPesa, Trustchain… in other words, the market slowly but surely has been able to pass the techno hype phase and is considering the first real life value-add examples.
Taking a
step back from the last 3,5 years of #SWIFTgpi I think the same can be said
about cross-border payments: for long anchored in its traditional ways, after years
of both hype (blockchain), and innovative closed loop solutions (e.g.
Transferwise) plus the ongoing threat from retail market innovation and GAFAs
entering the banking market, the correspondent banking community came to a
point where something had to be done.
Here, everyone
can have an ambition, a happy idea, and it’s easy enough to get someone’s
attention: just compile a several buzz words in a couple of sentences and you
will hear “bingo!” from somewhere in the room. These days you can even have an
algorithm generate such ideas taking a finextra feed as input.
Yes, I’m
exaggerating and having the right ideas at the right moment can be hard and is not
that common. But the key to final success however, to “play(ing) it again Sam”,
is in something less thrilling, far harder and often overlooked: execution.
#SWIFTgpi
was recently addressed as “the biggest innovation in SWIFT’s 40 year history”
[2]. I wanted to double-click here on three key best practices and lessons
learned that made it a successful journey.
- Find the spark first (a.k.a. “Don’t boil the ocean”)
I still
remember the Action Selling training book from the sales days at Deutsche Bank.
In it it was mentioned that the size of your sale is determined by the size of
your existing relationship. What this means is that, even if what you have in
mind is a value-add next-generation frictionless interbank transaction banking
platform that will seamlessly enable banks to focus on new end-customer digital
experiences and revenue streams while removing all interbank processing
friction … boy that’s too big a vision, you will get nowhere if you sell it
like that.
Instead, sell the first stone with an ounce of value (a.k.a. the minimum viable product or MVP: how would you like to track your outgoing cross-border payments?), then develop a roadmap so you can increase value progressively and a “vision”, so you can further help sell your MVP.
Watch out:
- The above might sound simple. However, agreeing an MVP with 15 different global financial institutions with different objectives is not. First, assume that you will be misunderstood. It’s not really your fault, so make sure that you repeat your message enough times for everyone to understand. And yes, it’s your fault, so make sure you refine your value prop sentence until you see assenting heads everywhere when you finish it. KISS they call it.
- There is also the question of which one division (cash management, capital markets, treasury management, trade, etc) can represent an institution of thousands of employees. The answer is not so simple, since every division has different customers with different needs and will come with their unique angle, but if your solution requires integration, chances are that FI product management is a good place to start. Yet, the more you can make your MVP value proposition generic to all divisions, the stronger the buy-in from every stakeholder.
- Build trust (a.k.a. “Say what you will do, do it and say what you did”)
The key to long-standing
success in everything we do is in building trust from the start. Entire books
could be written on this topic. In our case, we worked very hard to gain that
trust every single day for 2 years. Proving that we could properly spec our
product was one thing: I remember undergoing several sessions of word-by-word
peer-reviews where every comma counted and where synonyms and approximations
were not good enough. What seemed to work well was to “plant a stake on the
ground”: decide internally what was the best approach, then present and defend
that approach in front of your clients, be on the listen side when better ideas
are brought in and always make sure that progress is made every time.
On this
last topic, we had once a workshop participant who made a wholehearted exposé
on what this participant thought should be done on a particular point and of course everyone
should agree. However, such proposal, regardless of its questionable value, simply
required that we revisited all the principles we had already agreed on. So, I
very calmly explained: “what you are saying is… that we should go back two
months, forget about all we agreed so far and start all over again ?”. The
point was quickly over.
Agreeing the product rulebook and specifications was only the beginning. After that we had to prove that we could manage the pilot community through the build, test and go-live phases, all the while working on our own deliverables, then you have to prove that the product is delivering the expected value, tweak it if necessary, then you have to prove that you can extend your user base and do so at a satisfactory rate. And, all the while, you have to listen to your user base as they may hit walls of their own and need your help and also keep a tight ship within your team as trust is lost with the smallest things.
Watch out:
- Basically everything: if your specs are not precise enough, then they will not be validated, or you will have testing issues. You can also sometimes have contentious points (you can only standardize those processes that have become commodities) where reaching an agreement in public might require several bilateral discussions to make sure that the limits are understood. And even if you do that, and you thought that everything was ready for the big day, come still prepared for the unexpected and … “be water my friend” [3].
- However, don’t be a paranoid android: the project might still crash because of other things (e.g. change in relationships, politics, competitive landscape, etc). Just make sure that your boat is fit and ready for the journey on an ongoing basis and that everyone knows what’s expected from them.
- Last but not least. Go far? Go together.
Watch out:
- Same as in life, different people have different objectives. I will not do here a psychology thesis but at the beginning of every project we can probably agree to set up two basic groups: a high maintenance group that is skeptical and a low maintenance group that understands and supports the project. You need both so, for the first, you will have to find a way to bring them in into what is being done. Usually here you can apply the same methodology as in the previous point: build trust, show that the project is achievable, claim & communicate quick wins.
- Once you have cruising speed, the key is not to lose team momentum. No father loves his children the same yet every team member will expect fairness and equity. Recognising achievements is also key, as these create a positive momentum within the team. Here beware of the dark side: as success is everyone’s child, some (whether in your team or not) will say that they tried too, claim success their own, someone else’s ideas’ theirs: make sure that that does not go too far without being addressed.
All the
best for your projects in 2019! Hope this was a useful reading. Please share
your stories too.
(c) Pedro Mullor, 2018.
DISCLAIMER: the views expressed here are my personal opinions. Content published here is not read or approved by my employer before it is posted and does not represent the official positions, strategies or opinions of my employer.
DISCLAIMER: the views expressed here are my personal opinions. Content published here is not read or approved by my employer before it is posted and does not represent the official positions, strategies or opinions of my employer.
References
Comments
Post a Comment