Mobile Money as a Startup

I read a post recently on the GSMA for the unbanked blog titled 

Mobile money technology: not easy, but why? - 

http://mmublog.org/blog/mobile-money-technology-not-easy-but-why/

My response to this post is below and it ideally should be a blog post of its own and that is why I have put it here:

This is a very interesting post and the perspectives provided in the comments even much more interesting. It is good to hear the views of competing providers, customers and those who are actually in the arena and are in charge of getting mobile money platforms to actually work.

As consultants working closely with several MNOs and a number of partners on a lot of Mobile Transactions projects, the diversity of scenarios we have seen and the reality of what is possible and not makes me have more respect everyday for consultants and all players in the arena working tirelessly 24/7/365 on one of the most transformative initiative the emerging markets has experienced.

I always boast to people that in terms of having actual experience in the field deploying, implementing features and providing day-to-day operational support, we probably have put in more hours in the last 10 years than any single entity in the world. I think based on our experience I have earned some credit to address the areas you stated in the post and provide some suggestions.

My thinking is that each MobileMoney project should be treated as a startup in their own right, the principles governing all other startups from consumer web to enterprise must apply. Startups can be on their own or also be initiatives within larger organizations like the tax applications project at Intuit or Mpesa with Safaricom and MobileMoney within MTN.

Startups are initiatives that exist under conditions of extreme uncertainty but they exist to scale while providing maximum value to the customers and stakeholders.

There is no cookie-cutter remedy or “one-ring” to rule them all, as requirements or situations will always differ. One product or MNO cannot rule them all but same principles can govern them all. Those principles should be the principles enshrined in the “Lean Startup Movement” made popular by Eric Ries

My thoughts on the post are below -

Throughput and reliability:

I think as elusive as this may seem, both can be achieved but it requires painstaking attention to detail and teamwork. There are demands from all parties and expectations that have to be managed as you go along but the key is carrying everyone along and making the goals very clear from the onset.

This is never an easy project and nobody from vendors to internal MNO champions should ever give the impression that the goals will be achieved overnight just by putting a bit of code in place. As I always tell everyone this is not at all like “installing Microsoft office on your computer”. Sadly that perception is prevalent.

Customization:

This is where “Lean thinking” is very important.

 

According to the Lean Enterprise Institute:

 

“The core idea behind lean thinking is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources. A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste”

 

Understanding and applying lean principles on both sides (vendor and operator) will reduce as much waste of effort as possible.

From what I have seen, sometimes the operators really want to start small and get the low hanging fruit but when they get into the arena the realities are different. Problems from user inertia over previous assumptions to competitive pressure or even high demand can change the scope very quickly. This is where Change Management and Project Management are very vital but Lean Principles and methodology even more of an imperative.

It is important to know that having all the features in the world on a platform will not guarantee widespread uptake and from the vendor perspective a product can also die from over customization.

A well-managed project must anticipate all contingencies while having a robust roadmap. Managing multiple versions of a product or agile development is the current reality of the world we live in today and as much as we may wish it to be simple it will not be. What is most important is knowing the features that will provide the most value to your customers and implement them first while putting all the others on a realistic roadmap.

Iterations or pivots will occur as with any startup but they must be as a result of strategic imperatives and not whims or fears.

Planning for peak is costly:

This is the very reason why Mobile Money or other Mobile Transactions initiatives must be treated as startups because they exist under conditions of extreme uncertainty. Everything is speculative with a startup and it is a risky venture but it exists to conquer uncertainty and conquer it must.

Startups will not survive if they don’t scale and scaling should be anticipated and ability to cope with large transaction volumes must be in the DNA. If that capability to scale quickly is not in the roadmap then the project was doomed to fail or experience all the classic signs we see in most implementations today.

Dependencies:

This is where the argument of airtime and money is important.

A long time ago (about 10 years) we worked on an airtime vending and transfer project with several dependencies. We had a platform that would rollback a transaction if any connection to the dependencies failed and really struggled with 3rd party dependencies. This airtime-vending project was built way ahead of its time with money transactions in mind because it was part of the bigger vision of one of the most visionary CIOs I have ever met and one of the most reliable vendors in the market. Airtime and money can be treated the same way if the vision is bigger.

A lot of the issues with other dependencies have to do with people. Sometimes it is with change control management or issues with philosophy. The philosophy of supporting airtime transactions is sometimes very different from supporting mobile wallet/payments transactions in most operators but it really shouldn’t be.

With airtime an individual or at most two suffers effect of downtime but for wallets or payments this is magnified, as there are more players in the value chain. Losing ability to transact with your wallet is like losing a physical wallet with everything inside.

It is important to have this at the back of the mind when planning for support and response times to downtime. Watertight SLA’s with vendors or 3rd party service providers are an absolute necessity but most importantly pro-active support is crucial. Downtime must be anticipated even before they occur and all possibilities must be considered from sunspots to anchors cutting off submarine cables.

I have seen projects almost die because the SMSC was not stable and messages were not delivered, prepaid platform not optimized or even simple things like DBA and network connectivity issues. There are many reasons for a project to go wrong but the most important philosophy to have on projects like mobile money is “leave no dependency behind”. That is our philosophy at Swifta.

One way to go is to have as many dedicated resources as possible this a very costly option but inevitable eventually when you reach a certain level of transactions but it is best to plan ahead.  Another step is to have a better understanding of why those dependencies don’t come to the party and take pro-active measures. That is the principle behind “leave no dependency behind”. It requires a lot of coordination and team effort to pull this off but it is possible.

People:

This is where we have excelled. We realized from experience with supporting airtime platforms the importance of the “team” over the “individual”. A well-balanced team with diverse experience and expertise supporting a platform is in exponential magnitudes more valuable than having a few people managing a platform that is expected to scale.

Smart vendors and operators know their limitations and know when to outsource the implementation and support for projects when it comes to scaling across geographical boundaries or within a large market with potential to scale.

I remember a very memorable quote from Hannes Van Rensburg the CEO of Fundamo, he said “sometimes some operators who implement Mobile Money platforms are like airlines buying maybe the latest Airbus A380 and putting a classifieds advert on Craigslist looking for pilots or walking on the street and looking for who can fly the plane”

We have a team of 31 consultants dedicated to mobile transactions projects implementation and support and that is what we do and don’t sell products. We have also been able to ensure that the entire team works on each and every project as one entity. We also have a philosophy we believe in, we leave no dependency behind and we have never been part of any failed project.