Evaluating New Market Entrants: or what to consider when you begin
Recently, on PYMNTS.com, there were a series of posts that have been tickling the back of my brain.
These posts, entitled Separating Fantasy from Reality in the Brave New World of Payments Innovation and Is It a Dud or Not: Views on Payments Innovation, provide valuable insight to those who are evaluating a new entrant to the payments market.
But, they are also useful if you are considering offering a new technology of nearly any sort…I greatly encourage you to read them and contemplate.
I have pulled a few small quotes from the posts that deserve additional commentary.
Rule 1: What’s the problem that consumers or merchants have that this new solution solves?
This question could, perhaps should, be extended to all technology.
What is the problem that is solved by the technology?
Whilst I could pontificate, at length, about how the initial problem set may not, in fact, be the ultimate utility (twitter anyone?)…the question holds. Traction is gained by solving immediate pain. Continuing to address the needs of the community may, or may not, change the usage patterns of the technology, but they are driven by successfully solving for a tangible problem.
Rule 3: If it is a platform that requires getting buy-in from multiple groups (like payers and payees) how are you going to get a critical mass of both sides and ignite the platform?
Platform theory and implementation is near and dear to my heart. But this question, ultimately, summarizes the core of any discussion regarding a “platform”.
What is the unique value that will drive meaningful adoption?
What is the catalyst that begins to spawn the network effect?
2. The solution must be flexible enough to work with many different variables and scenarios. (open architecture)
Ahhh…”open”. I’ve written about the term, recently, in a post entitled “Open” APIs: a definition. The statement above is so beautifully succinct that I may begin to use it more frequently (perhaps eliminating the term “variables”)…
“flexible enough to work with many different variables and scenarios”
3. It needs to be easy to utilize and function.
Easy, or simple, are terms that are often used interchangeably. And, yet, they mean completely different things to different audiences. To a Software Company, “easy” often refers to service consolidation and API complexity. In contrast, and what I suspect the statement above is referencing, is the user experience. This becomes wildly intriguing when adopting an API strategy. Ultimately, for those starting as a product company and then offering an API for their service, the question morphs from:
How easy is it to use my service with my interface?
-to-
How easy is it to leverage the service as rendered through an application built by another?
There is a solution to this, as it relates to employing an API strategy (payment API or otherwise), that merits discussion at some point in the future.
Also, there is no such thing as a ‘payments’ market. ‘Nobody wakes up in the morning and wants to buy a payment’ – Eric Sepkes. A payment (clearing and settlement) is a business process component which is necessary to enable a wider business process. Understanding the underlying need is part of knowing the target market.
“a business process component which is necessary to enable a wider business process”
That statement, in and of itself, captures so much that is important to understand regarding the payments market. For a Software Company, for a retailer, for a back-office, for an eCommerce business…the payment is ONLY a part of the business process. The exchange of currency for goods or services is, undeniably, an important part of the process…but it is, in fact, only a part.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…
August 2, 2010