From experiencing the problem, to building the solution: An engineer's point of view

Finding Product Market Fit

Companies form to solve a customer problem. Whether that is to innovate how loan finance happens or to disrupt the retail investing landscape. The primary focus of these startups is to prove they have Product Market Fit (PMF) early, rather than to engineer the optimal backend operation systems.

Manual processes are frequent and acceptable, as the focus on the small engineering teams is to build what the customers directly interact with. After all, without customers using your product the greatest automated backend processes will have nothing to process.

Once these companies prove PMF they find themselves in a fortunate position. They have a growing number of customers using the product, and these newer customers come with different expectations. The Innovators, those customers who joined early, come knowing there may be rough edges. The newer customers expect a more polished product. They require more streamlined backend processes.

The experience of an engineer

As an engineer I’ve fortunately been in companies that reach scale-up and beyond multiple times.

Eventually where once manual processes were acceptable, and manageable they soon become unwieldy, and more time-confusing. At this point the question is asked “what do we do?”.

First new hires are bought into the operation teams helping to perform the extra work, or perform tasks more frequently to deal with expectations of customers (e.g. processing payments).

The longer the problems that the operation teams face are left unsolved or neglected, the more workarounds and hacks these teams end up performing. These are often well-meaning, and a necessity by the teams in order to perform their job. However having seen these go wrong on several occasions, the impact can sometimes go unnoticed by the engineering and product teams for a prolonged period.

Eventually, engineering work becomes inevitable. A small team of engineers is taken from building domain-specific features to working on solving the problem of their operations teams. As with any in-house engineering effort, time has to be invested to first understand the problem domain the operations team faces.

If these teams are put together temporarily, knowledge and experience of the tooling they put in place eventually becomes diluted and lost as the engineers filter back into other areas of the business. This introduces further costs as issues arise and need fixing, or further work becomes necessary. With new, unfamiliar engineers entering the cycle.

Enter Payable - the solution

Having seen multiple FinTech companies follow the same journey, and problems, with their payment operations and reconciliation. When I was approached by Daniel to join Payable I saw the benefits to these companies immediately.

No longer would these companies have to put engineering teams together to solve the same problem. No longer would the operation teams have to put up with being a second thought to their product teams roadmaps.

These companies could make significant cost savings by putting engineers to work on the companies core product domain, have a leaner operations team and get their new products to market quicker.

Payable is a plug and play solution to manage your treasury payments, automate bank transfers and manage your cash better 🙌