MVP in action

In our piece discussing the Agile Minimum Viable Product Development Framework, we touched upon the paradox that sometimes occurs among startups: no matter how ingenious the idea, or how rampant the business problem it intends to solve, it can be tripped up by lack of a minimal, testable product. Here, we will narrate a real-life situation that recently played out with one of M3hive clients. Hopefully, it sheds some light on just how slim the margin is between favorable and adverse outcomes, and how pure determination so heavily factors into market success.

A number of months ago, we received an inquiry from a founder who was working on a highly disruptive approach to mobile payment processing. The idea: rather than tie a person’s phone to a credit card or bank account for mobile pay, instead enable an entirely new payment network directly within the telecommunications ecosystem. In other words, this startup had set out to provide an option for consumers to literally pay by a phone number, where purchases simply post to the customer’s mobile phone bill.

Consumer benefits were notable in that the model would excise bank accounts and credit cards from the purchase process entirely, bypassing the current payment establishment and its byzantine fee structures. It also removed the internet from the payment equation, thus improving authenticity and security. For telco providers, the initiative would conceivably open the door to new lines of business in banking and credit.

Needless to say, we at M3hive were ecstatic when we heard about the project. This company had landed upon a completely disruptive approach to solve a pervasive and wide-reaching issue in electronic commerce. However, it was only during our initial meeting that we discovered just how dire their situation really was.

By the time she came to us, the CEO was in a virtual panic. Despite being months into the product development process with another software development team, the company still had no minimum viable product (MVP) to show for its efforts, and was on the hook to deliver same to investors within 60 days. Our contacts were staring down the very real possibility of having to close up shop, despite feelings from everyone involved that the idea would have very real and material repercussions across the market.

Within a matter of days, our leadership team was able to diagnose the root cause of the trouble at hand. Since the idea was to allow mobile providers to process transactions directly with merchants, in similar fashion to the way banks handle wire transfers with other banks, a viable product would, at minimum, require basic connectivity between one telco and a merchant to demonstrate how transactions using a brand-new payment scheme would work. Unfortunately, this matter had not been the focus of the development team at all. Instead, it had been putting its efforts towards proposing a multi-tenant architecture that would allow telcos to onboard efficiently, something that we would consider as a nice to have. For us, being able to demonstrate a transaction between a telco, merchant and a customer was the must have component, and constituted the MVP.

Warning Signs

The issues we uncovered during the discovery process of this project are, unfortunately, not unique. Rather, they speak to common set of factors that are often not properly considered. Unfortunately, the oversights at this stage are the ones that most easily turn into weak links, eventually coming between a founder’s earth-shaking idea, and an MVP.

In short, at the outset of any product development activity, founders must first:

• Define what truly comprises the MVP
• Understand how the limitations of available technology may affect building the MVP
• Know the extent to which R&D will need to be involved, and the limitations of internal technical capabilities to carry out any required R&D activities
• Elevate the most difficult problem that needs to be solved, and tackle it first
• Commit to delivering an MVP within 3-4 months and test it in the real world

In the final analysis, this client was working with a build team that had never really secured a fundamental grasp of the use case, which meant it was spending development cycles on creating functionality that would not have helped the startup test and validate the hypothesis behind its core business idea.

From Zero to Product in 60 Days (and the success factors that took us there)

Once M3hive established that the MVP would need to hinge upon a telco connectivity ‘switch, we leapt into action to meet our first deliverable timeline: produce a working version that the client could show to investors within a 60-day window. This required:

1. Deep Industry Knowledge (prior experience and methodologies allowed us to quickly acquire)

Luckily, several elements were in our favor going into this project. The M3hive team had just come off a big engagement to build a web-based self-provisioning portal for one of the world’s largest, multinational mobile telecommunications operators. That collaboration required us to become familiar with virtually every customer service integration in use within the telecom ecosystem, so we already held baseline knowledge about the systems that would need to connect with each other in order to make the transactional use case a reality.

3 weeks into development, however, a bombshell hit.

2. Sense of Urgency

The client called us into an urgent meeting, where it revealed it had now agreed to deliver a market pilot, through which U.S. troops stationed in Kandahar, Afghanistan could use their mobile phones to purchase flowers for loved ones back home in time for Christmas. This meeting took place during the first week of November. It does not take a rocket scientist to see the mathematical improbability implicit within the unforeseen reveal of such an accelerated timeline.

Suddenly, we weren’t just on the hook to build the MVP. We were now simultaneously called upon to support a market pilot in a parallel workflow, with very real human emotional consequences tied to the outcome, under an even tighter timeline.

The market pilot consisted of an integration between 1-800 FLOWERS and the primary mobile carrier in Afghanistan: Roshan. When troops visited a dedicated micro-site, they would be greeted with a check-out button that prompted them to enter only their mobile number as the payment method, and flowers home would be bought and paid for from their mobile phone accounts.

3. Team Resilience, Grit and Dedication to Success

It took nothing short of total commitment on the part of the entire M3hive team, from executive leadership to our last staff developer, but we got the project done and heard from many happy servicemen and women as a result. Many said we accomplished the impossible, and we take great pride in what we were able to achieve.

When we say to hold us to a timeline and acceptance metrics, and it is on us to make them happen, this project serves as living proof of the grit and determination that feeds such an ethos. Here, we were challenged to produce not only an MVP, but also a working pilot application, and to do so under extremely condensed timelines and severe working conditions. (The offices of our telecommunication partner were literally located in military bunkers).

Truth be told, the whole thing was possible simply because we started with a clear sense for what the MVP would need to look like. Even if that’s the hardest question to answer, you cannot move on productively until it is. And when you are realistic about what is possible, and what is not, even the most daunting roadblocks cannot deter the will to succeed.