First of all – please let me wish you, your family, friends, and colleagues a very prosperous, amazing, and exciting year 2023!

I’d like to start our conversation this year with something that is on the top of the minds of many CEOs and FinTech founders – fundraising and prolonging your runway.

Many FinTech leaders overlook substantial budget leaks and continue wasting precious resources when planning projects, and I’d like to show you how and where such unnecessary costs can be completely avoided.

The biggest mistake that, in my observation, drains precious resources is the bottom-up approach to project planning and project management.

Within a traditional project planning cycle, the project owner or the project manager meets with every stakeholder, gets the requirements, documents lead times and interdependencies, and then builds the project plan and allocates the tasks.

This bottom-up process has a built-in inefficiency in it because it is very difficult for the project manager to tell people from other departments that they don’t actually need a lot of resources in InfoSec or Compliance or Sales (because the project manager is not a narrow expert). There is some triage that occurs as a part of the project planning, but it will likely happen only when the project owner is very experienced and knows from their past projects what is really a must-do versus a nice-to-have for every important workstream.

The majority of FinTech CEOs or founders have been led to assess every project in the company based on a static dashboard or an exhaustive checklist of hard requirements. They feel like unless and until everything is green on this dashboard, they cannot move because it would be some kind of a breach with a lot of negative consequences.

What most founders want is to be able not to overinvest, not to over-prepare, and do things just in time, but they don’t know how.

When I introduce the concept of “just in time” as opposed to traditional “just in case” compliance, many FinTech founders initially misunderstand the concept and ask the question “what are the minimum requirements set that I need to comply with, and when is the latest possible deadline I need to do it by?”. This is the absolute worst possible question to ask, but I totally get it.

A better question to ask would be – “which risks and what actions can I take now to move this project forward?”

You can see that this is not exactly the same principle.

Let me give you one example, of why building the project bottom-up does not work for startups, where you don’t have unlimited time or other resources. 

Let’s say that the project you are planning is a new financial partner integration. You are going to have several workstreams, the main of them normally are Product/Engineering and Legal/Compliance.

• The engineering and product team will have to build the partner integration, testing, user interface, security features, and reporting capabilities. Unfortunately, they won’t be able to start working before all the due diligence, compliance approvals, and contractual phases are clear.
• The compliance team and the business development will normally lead the due diligence workstream. This phase can easily last several months, especially if your team does not know about the landmines hidden inside the compliance questionnaires and checklists that the partner asks you to complete. In many cases, you will be firefighting trying to satisfy the demands of your partner, coming up with the documents or the numbers or the diagrams they requested. You are likely assuming that since the partner is a bigger and more established company, they know what they need, and you are likely assuming that they really need everything they request. As a result, it may cost you more commitments and it will take longer if your team does not know where and how to push back. It is like trying to find your way out of a labyrinth without a map or compass.

At the project planning level, the compliance will report back to the project manager that they are waiting for feedback from the partner or that they are preparing the documentation for the partner, and everyone will have to wait. The project is de facto stuck, and your teams will assume that they will have to wait until the partner says “yes” or comes back with additional requests.

The biggest problem with this approach is that you are potentially ready to implement anything your partner asks you to do, without even trying to justify that another policy or another process, or another way of doing things is equally acceptable or compliant, but will take you less time and money to implement.

On top of that, you are building something with the sole purpose of “getting away with murder” today. Your next partner, next auditor, or next regulator can come in and kill everything you did thus far, and you will be back at compliance “square one” and face the necessity to invest in compliance or processes again.

In this case of our partner due diligence example, the difference between this firefighting and “just in time” compliance is that “just in time” compliance decisions come from a deep but simple analysis of what your business needs, which risks can it take now and how you justify it. You are pragmatically accepting risks and using a regulatory framework to support your decisions, and since this process is internally referenced to your specific risks and your business model, it can withstand almost any external inspections. You will not have to rebuild your onboarding flows, your reporting tools, or your transactional checks for the next partner.

Now you can probably realize why “just in time compliance” is much more efficient than firefighting and implementing something a random 3rd party told you to build. You don’t really want to be risking that your next partner, next auditor, or next regulator comes in and kills everything you did before.

Let’s still address the big elephant in the room.

You may be thinking: “But my auditors told me to implement these processes” “BIG4 advisors reviewed our plan and told us what to do” or “we would not be accepted by this bank unless we agreed to implement everything they told us”.

Yes, it’s true. There are always a lot of people who think they know what you should do.

But…

I hear it over and over again from my clients during their audits and regulatory inspections: “Last year we did exactly the same process, the auditors told us to do XYZ, and we followed their recommendation. Why suddenly this year this is no longer sufficient or compliant?”

I am sure, you can relate because the problem with relying on any authority figure is that they are forgetful, inconsistent, and can change their mind any time, and your business is not really their problem so they don’t actually fully understand it. But you are the one paying for costly mistakes, unnecessary processes, and lost opportunities.

If you don’t know why you did something last year or whether or not you should do the same thing this year because you have not yet built your own “just in time” pragmatic risk acceptance framework, you are wasting your time and money. Big time.

And I am not even talking about the risk that the partner will just reject you in the end.

We all know the unfortunate statistics. Very few FinTech startups keep growing, secure the licenses and partnerships they want, and are loved and praised by their customers… while most other startups struggle and run out of money.

• What you really want, given the time and money constraints, is a way to have a prediction around two questions: Will this project or a partnership or a product idea work at all, and what would be a “quick and dirty” way to test it within a matter of weeks before we over-commit and go all-in?
• Once we have tested and have some reasons to believe it will work and is worth investing in, what does the minimum viable project look like, what are the risks we are taking and what’s the next step?

In summary, the argument I am making here is that instead of testing the product that’s almost ready, after you’ve spent months building and integrating it, the testing of the product idea within the context of applicable risks must have occurred at the design stage. You have to test your decision to launch this product or this partnership before actually going and doing all the things – and almost nobody in FinTech has the discipline of testing their big-commitment decisions. No wonder, so many startups run out of money.

In my next newsletter of this series, I will show you how I discovered this “just in time” method and offer you a few striking examples from my PayPal days about how to plan and not to plan complex projects. I will end this special series by revealing my new method where I am going to show you how you and your teams can test your project plans or product ideas early enough without over-investing precious resources into things that may not work.

Stay tuned for more – and Happy New Year 2023!

Start listening to this content on the Compliance That Makes Sense podcast – Click here!