How to think about priorities and resources in a fintech startup

Of course, all of these things are priorities. But, while Moov is doing big things, our team is still relatively small. There are only so many resources to go around, so we have to be thoughtful and strategic about how we’re allocating them.

This is something I think about a lot. In fact, it consumes most of my days, and sometimes my nights (and when I do sleep, hello trigger tuning). The real rub here is that many of Moov’s senior leaders have done this before and founded other companies. We’ve driven growth, added value to the industry, and built some amazing things. With all that experience, you’d think this would get easier over time. Sadly, it doesn’t.

That said, we’ve all learned a lot about what works and what doesn’t, and how to balance competing priorities. Today, I wanted to share how I think about prioritizing resources across the lifecycle of a startup.

I start by categorizing priorities into buckets: A bucket for products and features, another for reliability and scalability—you get the idea, a bucket for every area you’ll need to commit resources to. How you fill those buckets (i.e., what you need to focus on) depends on how far along you are in your startup’s lifecycle—or what phase you’re in. You can delineate the stages of your lifecycle in any number of ways, but I find the following four phases as a useful framework for where we’ve been, where we are, and where we’re going.

Phase one: I have an idea

I like to think of the first phase of any startup as the “I have an idea” phase. You’ve recognized a problem and have a potential solution. During this phase, you pour all of your resources into the product bucket because you just need to build something. This phase happened a few years ago for Moov. We had a North Star discussion, white-boarded what we wanted to build, and started working. In a lot of ways, this is the easiest, most fun phase. It’s all green field, wide open and new. A lot of startups might cut corners while they’re building in this phase—not because they’re doing bad work, but because it’s hard to know exactly where those corners actually are. For example, why make a config file that you can customize with each customer when you don’t have any customers? You just build, knowing that you’ll have to improve and refine things later.

The reality is that, during this phase, you just need to get something built. Just focus on building a relatively bare bones viable product. Let go of perfection because even your most well-intended, beautifully-developed phase-one product will become just a shadow of what you’ll build later. There’s no amount of sitting around, drinking coffee, and pontificating about what customers might need that will ever match the progress you’ll make after an actual customer tests your product and tells you what else they need.

Phase two: I have a customer

The next phase is arguably less fun. Product teams and engineers love to make shiny new things, but when you begin to work with customers, those clients and their users become your number one priority. A shiny new feature might have earned you those customers, but to keep them, every part of the product has to work—and they have to work all the time.

No one cares about infrastructure until they do—when it stops working. How often do you think about your power company or internet provider when everything’s working? And how quickly does that indifference turn into frustration and dissatisfaction when your service goes down?

So, in phase two, it’s natural to want to pour everything out of the product bucket and into the availability and scalability bucket. And you can do that, but it may serve you better in the long run to keep some resources in the product and feature bucket. Because the next customer, the one who boosts your revenue and increases your resources, might be looking for that one feature that you would be rolling out if you weren’t completely focused on scalability and reliability.

It’s a difficult balancing act. If you put all your resources into bolstering what you’ve built, you keep your current customers happy—and you pave the way to support more customers. But if you’re spending more money than you’re bringing in with your current customers, then building the next round of customer-attracting features has to be a priority, too.

I can’t really tell you how to get through this phase, because it really depends on your business. But I can tell you that, if I had it to do all over again, I’d spend more time focused on existing customers and less on sales. Revenue is great—it’s necessary—but unless you’re ready to grow really fast, spreading yourself too thin too quickly only jeopardizes existing revenue and relationships.

Phase three: I have more to learn

As you grow, your product can’t stay the same. Even if the version you launched with does everything you wanted it to do, your customers will find new use cases, technology will change, and opportunities will appear. You need to add and upgrade features.

Does this mean pouring half of the availability bucket back into the feature bucket? Or all of it? Or just a few drops? There’s no right answer here—at least not one that applies to everyone. You have to fully understand how hard your current customers are pushing your product, how high the demand is for your next feature, how long before you can onboard additional developer resources, etc.

Working your way through the “customer” phase, you’ll learn a lot. Back during the “I have an idea” phase, it was easy to make assumptions or fail to drill down far enough into what you’re doing or why you’re doing it. Something as simple as how you define a product or a process can have a huge impact down the road.

For example, most would agree that the term “transaction” is defined as “moving money from one place to another.” With that understanding, you can start building some fintech, right?

Well, you can. But the moment you introduce any kind of complexity into that equation, this simple definition proves inadequate. What if you add a fee to a transaction? Does that require a separate transaction? If so, how, where, and when is the second transaction initiated? How is it reconciled by all the parties involved? You have to get specific and granular in how you define everything and how you build around those definitions.

So, in phase three, you have to take a hard look at everything you’ve learned along the way and identify the holes in your understanding of your product and how your customers are using it. To address tomorrow’s needs, you need to look past what your customers are doing to what they’re unable to do—and figure out ways to make those things possible.

The ugly truth is that your understanding of your customers’ needs will always be incomplete—even if you’re an expert, even if you’ve been down this road a hundred times before. Technology will change, new use cases will emerge, and users will evolve.

But each new feature, customer, and use case will teach you something and make your product better. Take that feedback to heart and apply it to everything you do.

It’s also crucial to hire people with a wide breadth of experience—and to give them a voice. Our CEO and Co-Founder, Wade Arnold, has written a lot about this. I highly recommend you check out his thoughts on building an engineering culture and how we approach our roles as leaders. You have to respect the craft and the creative people you employ. Like your customers, they’re crucial to learning, growing, and making it through this phase of your business.

Phase four: I have a promise to keep

Once you reach a certain point, you have to do all the things. You need enough resources to keep all your buckets adequately full, or have to be savvy about allocating and reallocating resources quickly and effectively. Your new features should have scalability built into them. Your infrastructure should remain stable no matter what updates you release. And each new product should solve a real challenge or create a new opportunity.

But, while product, reliability, and scalability matter, you also need to make sure you’re delivering on something bigger than what you’ve built between your customers, your team, and your original idea. Even if you’re keeping all the plates spinning and feeling pretty good about it, do a gut check:

Does your product actually align with the requirements of your original idea? What are you solving for? What have you learned? Where have you drifted away from your initial idea—and why? Of course, it’s fine to pivot with changes; technology moves fast and you’ve got to be nimble. But what you’ve built by this point is more than an idea or a product. It’s a promise. Make sure you’re living up to it.

“Legacy” providers often get a bad rap, but I can’t wait to be that kind of incumbent, with a rock-solid customer base to whom we’ve kept our promises—and an infrastructure that defines what’s possible and that powers more than seems possible today.

Is it hard work? Of course. But is it worth it? Even more so. The team and trust that you get to build along the way are deeply rewarding. In a discussion of resources, your people are priceless. However you allocate your assets, remember this—that you can’t build anything worthwhile without a team that believes in what you’re doing. And you earn that faith by keeping your promises every day—to your vision, your customers, and, always, to the people that make it possible for you to turn your idea into reality.