Ideas and more ideas

Success is great. But failure can be greater, if you take the lessons! This is not to say failure is not annoying! It is annoying. Yet when you fail, you learn. You learn how to fail, and how not to fail. Better still, failure gives us lessons on how things should have been done, had we known better. Being in business school making armchair analysis gives you an air of invincibility, but getting into the actual act of managing projects, running a business or setting up one is a different ball game, which provides hard lessons. I call it a university of hard knocks. Here is a typical story of failure, from which I learnt lessons on what to avoid in my subsequent ventures. This account emphasizes two approaches relevant to executing projects, namely the agile approach, as contrasted with the waterfall method.

My first e-commerce project was in fact motivated by my business school research on retailing business models. At the time, Amazon was rising. So was Rakuten, the largest e-commerce business in Japan. The question on my mind was, why not explore that in Africa? I knew there were some known knowns, known unknowns and unknown unknowns in such a venture. For example, I knew the existence of retail businesses in Zimbabwe meant there were retail customers. I also knew there were no online payment options, and it was necessary to set-up one. I also knew there would be delivery hassles, among many others hiccups. In short, there was no e-commerce ecosystem. I was also clear about the business model to explore. I also knew I had to bootstrap the start-up, given lack of venture capital. But there were other things that were unknown to me at the time, the agile approach to executing such a venture. Had I known better, I would have executed it differently.

With my friend Mansour Ali, we mapped the project plan in his apartment in Fukuoka. After years of doing projects in banks, making sure there was a project plan prior to starting a new project had become second nature to me. Where is the project plan? Who is the project owner? Who is the project manager? What are the steps to the project? Which group of activities go first? What is the critical path?  These were key questions I sought to address first. It was all a silo and compartmentalized mindset acquired from previous experience running banking projects.

I was the project sponsor, Mansour was the project manager working on the platform development. I was to fund everything necessary, implement the project in Zimbabwe and lead the deployment, stakeholder management and business development. With hindsight, our approach was a typical waterfall approach: build the online marketplace, add as many features we deemed necessary as possible till it looks great, perform an internal test of the platform, then sell the platform to existing retailers so that they can sell their products to a broader audience online, find a payments solution and figure out how to execute delivery, then launch, and succeed!

The entire process took several months. It was complicated by the fact that we both had to work full-time on our other jobs. Mansour ran his other business while I worked separately elsewhere. It was worsened by the reality that he sometimes traveled halfway around the world to Oman, where he was developing a car exports business. Each time he traveled there, he would stop working on the project on account of internet controls in the host country. As the key developer and project manager, this caused serious delays. This complicated the waterfall approach we took as it took very long to launch the end product, an multiple merchant e-commerce marketplace.

Pazimba.com homepage

After over 9 months of working on the project, and an investment worth several thousands of dollars in time and money, we launched the online marketplace in the last quarter of 2014. We got fairly good media coverage in key technology websites and daily newspapers. At that point we had a handful of very good merchants in the country who signed up to run virtual stores on our platform, including a well established book publisher with a very rich catalog going back several decades. Getting merchants to sign up turned to be a complex task. It was a long pipeline that involved travelling across the country to make presentations to each of them. In each case, we had to explain the features and benefits of running a web-store. What became clear was that most of them vaguely knew about e-commerce, but had never thought about using the internet to sell their products. In general, they were not convinced they needed to have resources set aside to run a web delivery channel. This started creating several unknown unknowns we had never factored in our waterfall development approach. Though we got some merchants to sign up alright, the biggest unknown unknown was that we had to do much of the work ourselves because merchants neither had the time no human resources to either update their own catalogs or processes deliveries. This left us running from pillar to post to cover all the gaps. The work was tedious. Finding a delivery solution was also not easy. Fortunately, unlike other African countries, like Nigeria, Zimbabwe has an effective postal address system. We therefore partnered Zimpost (the national postal service), which delivered packages reliably at a low price. The price was low at the beginning, but was changed upwards a few weeks later. We did not have enough critical mass to negotiate the price downwards. All these dynamics were unknown unknowns.

After a few months working on the venture, it became obvious that we were bleeding money. Mansour was getting disillusioned. It became clear that we has to scale down the project. And we did. It was not necessary to continue bleeding more resources.

Pazimba.com marketplace

The question is what should we have done differently. It became clear several months later that Zimbabwe was just not ready for e-commerce. What were my assumptions, that made me proceed anyway with the project in spite of all its blind spots? I had proceeded because I believed that Henry Ford’s quip, “If I had asked people what they wanted, they would have said faster horses,” would be turn out true in our case. So we did not engage the market as we as necessary as we proceeded to implement our solution, at a huge cost.

Yet we could have done things differently. How? Had we been more agile in our deployment, we could have seen sooner, at far much less cost, that there was not much light at the end of the tunnel. How? Had we followed the agile lean start-up approach, we could have tested our idea before proceeding all pistons firing to implement it. We could have tested our assumptions and hypothesis first by engaging merchants/retailers to assess their appetite for online delivery channels. In addition, we should have sampled potential buyers first, to validate our assumption that they would somehow use the solution. We knew that buying anything online had not grown on our potential customers, but we assumed our efforts would change their behavior. We should have validated those assumptions through an agile approach. What else could we have done? Had we established some level of appetite from customers and some merchants, instead of spending months building a fully fledged multi-merchant e-commerce platform, we should have built a thin minimum viable product off commercial templates to prototype and validate our assumptions. We could have done this by setting the prototype platform one one merchant to gauge the potential interest from consumers.

As it turned out, we did not, at great cost in terms of money and time. Lesson: always implement any venture or project in agile fashion. Validate your assumptions, figure out how to prototype and deploy a minimum viable product, and be sure its worth proceeding before investing huge amounts of money that are irrecoverable way later.