From Capitaine Train to Memo Bank: lessons from a Product Manager

In 2017, we decided to embark on a wild ride: launching a new bank for Small Businesses without taking any shortcuts.

At the time, the team working on this new project was mostly made up of former employees of Capitaine Train, a train ticket sales site acquired by Trainline in 2016. As we were starting from scratch, we took the opportunity to quickly integrate the best takeaways from that shared experience and to improve upon the rest.

In terms of Product, Captain Train had a pretty impressive reputation in the start-up ecosystem; it had a strong, user-centric culture that focused on delivering a smooth user experience in pixel-perfect interfaces. The team was composed mainly of talented engineers and customer service experts who were committed to making booking train tickets quick and painless.

As employees of Capitaine Train, we were lucky enough to be able to use our product every day. One of the real strengths of the company was that members of the tech team (which accounted for almost half of the company) were daily users of the product. It was really easy to get into users’ shoes and to understand their pain points.

However, from a Product Management perspective, there was room for improvement:

• The culture of Capitaine Train had been defined by engineers, developers; the notion of product, and the role of product manager, were adopted along the way, afterwards. Historically, the company had been mostly driven by engineers; the product management function came into play late in the game. Many efforts were made to carve out space for this role, but there still could have been a better balance between the product team and the tech team.
• There could have been a standardization of the delivery processes to improve velocity and internal visibility (with bi-weekly sprints & clear product objectives for example). Development cycles and clear product objectives could have helped.
• The prioritization of product features could also have been more structured (by using a basic complexity ⨉ customer value ⨉ business value framework). For example, we could have considered the complexity of each feature in relation to the value it brings to the user or the company.
• Breadth and depth of data use: the company was mostly driven by customer feedback (qualitative analysis), but lacked product decisions based on data analysis (quantitative analysis).

Needless to say, when you go into business banking, it really shakes up the rules. Nobody on staff is a direct user of your final product: neither engineers, product managers nor company executives. Insight comes from customers and market analysis. To state the obvious: it’s especially important to make decisions based on facts and not on intuition.

The number of product stakeholders is multiplied. Internally, you have several employees with diverging (and sometimes conflicting) objectives: risk managers, compliance officers, engineers, salespeople, designers, accountants, customer support; Externally, you have several entities with diverging (and sometimes conflicting) objectives: banking regulators, financial partners, customers, product partners.

The multiplicity of topics doesn’t help. The scope of the work is enormous because not only do you have to provide tailored solutions for the aforementioned stakeholders, but you must also find a way to differentiate yourself from competitors whose offers tend to be much more advanced.

The banking industry is complex and everyone needs time to understand its rules and constraints. This leads to longer staff onboarding: tech newcomers attend banking training sessions and banking newcomers attend tech training sessions.

In this situation, finding the right people is critical because they can save you time and drastically improve your team velocity.

In this chaotic context, there is a clear need for an orchestra conductor, a Product Manager, to align all the various parts into something harmonious despite limited resources. His role is to make things happen, despite the constraints weighing on the organization. An orchestra conductor has little more than a tiny stick and a unique perspective; a Product Manager only has the latter!

When working with stakeholders coming from companies where IT and commercial sections are separated by 10 floors, you cannot get anywhere without first giving credibility to the Product Manager role. Its presence helps avoid the sequenced, segmented operation that characterizes siloed organizations.

In our case, this has been the topic of a company presentation and is now part of onboarding for new staff.

Collective thinking

In the banking sector, the amount of information available is scarce and interpretations are rarely straightforward. Therefore, it is highly unlikely that you could resolve whatever issues you are tackling by yourself. You need a high-functioning collective intelligence in order to find the best solutions in the most efficient manner. Without confrontation of viewpoints, there is no salvation. This requires dealing with people with very different backgrounds and helping them work together towards a shared goal. You can facilitate this by setting clear objectives, defining a common language and communicating frequently on each team’s progress.

Here’s what I wish I’d known before becoming the first product manager of a young bank for professionals.

Be confident

The amount of information that you don’t have is so vast that no one is expecting you to know everything. You’re not here to have all the answers, but to ask the right questions. Be humble in the face of complexity, but don’t let it overwhelm you. You are supposed to be the team confidence catalyst, not a purveyor of anxiety. Do your best, communicate openly, and you will get there in the end.

Define the product vision

• To help you get started, take the time to find a framework that works for you: it’s not a natural process, and it requires a lot of thinking. However, when you get this part right, it truly pays off in terms of your ability to move forward quickly and with confidence (see previous entry).
• Talk to people. Meet potential customers, including both users and stakeholders as they are not necessarily the same person. For us, CEOs will be contract signatories, but their assistants may be our product users. We also built 2 Typeforms (one for business owners and one for bankers) to help us obtain market data and conduct interviews.
• Understand the company strategy. Speak with founders, read the business plan and get involved in strategic discussions. The more you make the company’s strategy your own, the better you’ll be able to translate it into concrete objectives for the various teams.

Learning to walk before running

Help people and find small ways to improve their daily lives: find the right tools, implement new processes (shorter and more efficient meetings are actually a process), share information, provide training if needed. Repeat as many times as necessary. For instance, we are working with a freelance designer and we were having trouble sharing the latest designs with the rest of the team. To remedy this, we set up Abstract, a collaborative design tool. Now everyone can contribute to the design process.

As I mentioned earlier, we have people coming from different backgrounds (mostly banking and tech) who have very different opinions on meetings. Needless to say, they have different views on the usefulness of meetings. As a gross generalization, I would say that tech people don’t like meetings and banking people are used to spending a fair amount of time in long meetings. It’s a real challenge to find the right balance between both. In a blog article, the teams at Alan propose an interesting alternative to meetings: the written note.

Don’t be afraid to spend time learning. In our case, we spent a couple of months building a prototype just to get our hands dirty. At first, the team was very reluctant to do this, but in the end it turned to be a great way to learn to work with each other and to start understanding how to build all our product stacks. An unexpected upside was the number of inside jokes that resulted from this exercise; those involved still have a good laugh about it today.

Build your roadmap

A few tips to get you off to a good start:

• Focus on the essentials. Keep in mind that you don’t have to reinvent the wheel to succeed – and no one will blame you if you don’t. Doing the same thing better is often enough to make a difference. In our case, the amount of resources (time and tech) required to reach feature parity with competitors is so high that it became a question of radical prioritization (which means saying goodbye, at least for now, to some of our favorite features). In order to be able to design our roadmap in this context of limited resources, we were forced to choose between two radically different MVPs. Inevitably, this led to long debates. In the end, however, the team was aligned with a precise objective, which in turn enabled us to start working on our MVP features.
• Sit down with every stakeholder to make sure that you didn’t forget anything.
• Get estimates from your tech team. Involve them in designing the roadmap as soon as possible, to avoid friction later (whether on a technical or an interpersonal front).
• Make room for last minute adjustments: start with key features and schedule every nice-to-have feature closer to the deadline.
• Once your roadmap is created, share it and update it frequently. Product Board is a good tool for that.
• Create tangible delivery objectives. And regularly demonstrate what you’ve been working on to other employees.

Short-term focus on long-term needs

We are building a bank, a real independent bank. Therefore, we approach everything we do as an industrial project, which requires us to look beyond the end of the current month. If we do not adequately consider a topic today, we will pay the price tomorrow, or the day after tomorrow. Therefore, we always choose quality, even if a passable solution could have sufficed in the short term and at a lower cost. We opt for the most demanding path, not only in terms of product, but also in terms of internal procedures and tools.

For example, we seek to avoid dependencies and intermediaries as much as possible, to remain masters of our infrastructure. This choice is not free, indeed, but it has pushed us to invest time in developing a technical architecture as exotic as it is promising.

It’s almost pointless to remind, but the choice of quality comes at the expense of speed. Favoring one means turning away from the other. Nevertheless, we consider our bias towards quality as a long-term investment whose dividends we will reap later on. When the time comes to scale our operations, we will be able to accelerate rapidly and confidently.