Electronic Payments: MVP - before & after...practical considerations.

Wikipedia defines a Minimum Viable Product (MVP) as a “product with the highest return of investment versus risk”. The underline assumption here is that it is a business ready product. There is another definition which we get to hear often enough from startups in the early stages – which is more of a MP with the V missing – I don’t intend to make light of this issue, but rather bring light to the fact what increasingly early stage entrepreneurs with early formation of ideas want to show a non-business ready quasi product (for investors or proof of concept reasons etc.) – to showcase base zero functionality without really building or designing a traditionally defined MVP.

Why am I writing about this? Just so that I can share some common experiences on what possibly is a good way to engage a software technology partner (like us – yes I know, it’s an old habit) to meander this journey together from taking a concept to the MP stage and then to the MVP stage and beyond.  

In electronic payments over the last few years we have had a surge in activity around the use of technology to add value to a consumer’s experience within the realms of payments as well as commerce and we have had multiple requests from prospective customers to build such a product which loosely lies in between the spectrum of MVP and MP. Just to set the paradigm right, let us look at a broad architectural framework which represents well a scenario of typical payments, loyalty, prepaid and consumer financial services. For this you might want to look at my earlier post with a traditional payment gateway architecture here.

In most cases, systems at a generic level would follow the transaction path through one or more acquiring points to some kind of a transaction format neutralizer then to the central heartbeat of the system (the payment gateway or the transaction switch) then to the backend processors/authorization end points and back with approval.

The attached diagram – depicts the characteristics of what each phase would look like.

Team formation would need to have strong alignment with the payments and retail business-technology space. We have seen most success when the teams are building a MP with an eye out on the MVP. Typically, this would mean that we have a broader set of requirements at a functional level defined as a super set. It is not imperative to do this, but in the absence of a defined functional requirements document there is a risk of not getting your priorities in order. Also, at this stage if you do need to pivot then linking dependencies and changes off of a functional requirements document make the whole exercise trackable and more efficient.

 Like most cases in the start-up world – every scenario is different and demands a unique response, the attempt here was to capture what we are hearing at the ground level when entrepreneurs are taking an idea to an MVP stage and beyond.

Mustafa Shehabi | [email protected]