Building a bank with Megan Caywoodz

Megan Caywood was previously Chief Platform Officer at Starling Bank, one of the hottest start-ups in London and a leading challenger bank. Her focus was on the API strategy and Marketplace platform. Before that she was at Xero in San Francisco and Intuit who are featured in the Lean Start-Up book.

Since moving over to the UK on an Exceptional Talent visa, she has become a popular figure in the FinTech space and has been short-listed for several awards. She is currently Head of Digital Strategy at Barclays.

Impressive or what? We were lucky enough to sit down with her a couple of years ago and pick her brain! Here it is, an interview with the exceptionally talented, Megan Caywood.

Why do you think there has been an increase in the number of challenger banks and fintech companies?

What commonly happens is people use these terms interchangeably, but they're quite different. There’s Fintech, there are challenger banks, there's traditional challenger banks versus new challenger banks, and each of these means something a bit different.

You have banks without a banking license but they're just building the user interface on top of white card or bank core.

Then you have traditional challenger banks, which are people like Metro Bank who are new to the whole area, but have a traditional business banking model.

Then you have new challenger banks like Starling, Monzo, Tandem, Adam who are building a banking platform from the ground up, they're getting the banking license, as well as doing the new user experience on top with a new business model.

I think there's been an explosion in different areas because you see different needs, and a whole other area that's opening up is called infrastructure banking, where they're literally just building the platform for others to build banks on top of.

They have the banking license but they're not looking to be a bank. They just want to help others to build banks.

You usually see disruption in every industry except for financial services. But now it's opening up because of API's, new technologies that you can use, for example; you can use cloud hosting for the first time in banking, and that's just available as of November 2015.

As the regulator moves to a new space where they're allowing for competition, new technologies, which have really been used in banking for the first time. You’re seeing a lot of different people popping up wanting to meet this need.

How do you build a roadmap?

It really depends on the type of product you’re building and the type of company you're building. If you are building something that's consumer-centric versus business centric, that's going to be different and your processes will be differ.

Ultimately, what you're trying to do is understand the user journey for your particular product, and the unique problems that customers have when using it currently and then figure out how to differentiate within that.

You’re going to want to spend a period of your time really understanding those problems, and figuring out how you'll solve them uniquely well, and then break that down in to what you're going to prioritise.

Once you clearly understand the problem and how to solve it, then you can see the priorities that you need to work on. Then identify the date at which you need to execute that by because for some (especially within financial industries), you often have dates that will affect your product roadmap.

I used to work on payroll, and the fact is people rarely switch payroll products mid-year. If you launch a new payroll product mid-year it's going to fall flat. We had to launch specifically before 6th April.

Within the financial product you need to understand what you're doing, what the priorities are, and what are the external events and guidelines and things from the regulators that are going to affect your timeline, and work back from that.

In a highly regulated industry such as banking, what is an ideal new product development process?

When you're working on new product development within a bank you're going to have to build your requirements sets so that they ladder up to what the regulator has put in place and then work on testing those out with the regulator and prove that they're sufficient.

An example of that is within Starling bank, when you first receive your banking license you actually operate under restrictions for the first six months. What that means is that you can have a maximum of £50,000 in deposits. You can't exceed that until you've fully tested out all the systems that they've put in place to say that they need to measure these and go through pen testing before you can release.

What we do is we've gone through with a regulator, proved out these different systems and then once you've proved that out, they lift restrictions and then at that point then you can do a beta.

Your product roadmap really needs to consider in the timeline the government and regulation institutions and other authorities will place upon your product, and make sure you factor in those different timelines, as well as the traditional product roadmap.

How do you gather significant data on your product when you haven’t officially launched yet?

At university I did research into cognitive science and significant data in research. In a field like cognitive science it requires lot of data points before you can have any actual statistical significance.

When I started, what I found is that the golden number is eight. When you're doing user testing early on, set up some sessions with just a few people. And the common number you really need is eight to get good ideas and feedback.

This is great for understanding the user and the user journey and then being able to plan your design and development from there. Once you have launched and have a lot of users, then you really get into optimising and that's where A/B testing comes in, and where you’ll need a lot more users to be able to get the kind of feedback you're looking for.

What’s the best piece of advice you’ve ever been given?

I would say there's been a continuous theme. When I was at university I was told if you try to do too many things, and get involved in too many clubs, activities and classes, basically you're going to exhaust yourself and you're going to reach a threshold where your work quality will go down. You're a finite person, you can only do so much.

Figure out what your priorities are and only do those without getting too exhausted, or at least have a strong plan for how you're going to build in time to recoup in between all these different things that you're trying to manage and do.

When I started at intuit we had a lot of Brownback sessions and sessions with leaders, and I found it interesting that same feedback came back. But the way it's usually phrased within business is "don't be afraid to say no."

Often times (especially in your early career) people will ask you to do pretty much everything, and if you accept all of it, all of a sudden you're going to be trying to do everything for everyone, and something's going to get dropped in there.

You must be able to establish not only how to prioritise as a product manager, but when to say no and how to do that effectively.

What are the 3 best product management tools and why?

I would pick Google Drive, Jira and Slack.

The first being because Google Drive is very easy to collaborate on, and you don't need Microsoft Office. You can just use Google Docs, Excel and it's easy to share and collaborate on different documents together, and email is obviously going to be an essential need.

Slack hopes to replace email, but Slack is a great tool additionally, but it's more of a team collaboration tool and it's where everyone can have insight and the same communication channels. It's also just a well thought through product, that's well designed and created.

Jira key to any product development management process, so you can really co-ordinate across work and across teams, and long distance releases really well.

Asan is great and that can be free for teams up to 10. But I really like Jira and the sophistication built into it, I would start with that and get teams used to using Jira from the beginning.

How do you evolve a product to meet changing market needs?

As the market changes and technology changes, what you really need to do is to evaluate your product and how you can disrupt your own product and services to keep pace with change.

What we saw with the move to digital, is that a lot of companies were afraid to move to online, and that's because it changed their existing business model and that would disrupt their current revenue stream.

What you really need to do is to be willing to understand how is this technology and innovation changing the product that you're offering and not be afraid to disrupt that, and disrupt your current revenue streams by building out a product that challenges that.

What we've seen is companies like Blockbuster who didn't see the change coming with digital and that it would change the revenue streams and their current business model. Plus, they had tons of branch locations.

Now when you see a Blockbuster, it is usually an empty store, because Netflix came in and saw this change those are the ones who end up winning.

It’s not necessarily the “big that eat the small," but the “fast who eat the slow."

What you need to do is not be afraid to disrupt your own products. Even if you know that's going to nibble away at your own revenue, ultimately it’s a long-term gain and that's what you need to be willing to do in order to be successful, competitive and to remain in the market.

Lastly, what reading material would you recommend to other product people?

The main reading material I would recommend is called "The Hard Thing About Hard Things" by Ben Horowitz. He's a venture capitalist in Silicon Valley, but he worked with Mark Anderson at Netscape back when it was being started, and then he did another company called LoudCloud which turned into Opsware and talks a lot about the different challenges/struggles he faced when building a product and a company from the ground up, and how to evolve that as technology was changing as they were building their company.

It's a really interesting success story because they ultimately ended up selling it for $1.6 billion dollars, which sounds great but it took a lot of hard work and strategic thought around how you build and shift teams and change strategy to evolving market needs. It's a very good book that's relevant for anyone who's especially within a tech start-up.