From Captain Train to Memo Bank: Lessons Learned as a Product Manager
Context
About a year ago, we decided to embark on a wild ride: launching a new bank for Small Businesses without taking any shortcuts.
At the time, most of our employees had already worked together at Captain Train, a start-up acquired by Trainline 2 years ago.
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.
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:
- 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);
- The prioritization of product features could also have been more structured (by using a basic complexity ⨉ customer value ⨉ business value framework).
- 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).
New game, new rules
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 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.
The orchestra conductor.
In this chaotic context, there is a clear need for an orchestra conductor, aka a Product Manager, to align all the various parts into something harmonious despite limited resources. 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.
In our case, this has been the topic of a company presentation and is now part of onboarding for new staff.
To explain this, we’ve put a twist on the classic Product Management triangle (tech, business and users) by adding a fourth angle — regulation. This makes a big difference because regulatory requirements add another layer of constraints to designing your features while leaving very little room for error.
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. 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.
Where to start
As the first Product Manager in a young organization, here is what I found useful:
Be confident
The amount of information that you don’t have is so vast that no one is expecting you to know everything. Be humble, but don’t be timid. 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. Trust in that, and spread that confidence to your team.
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).
- 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.
Start small, then go big
- 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. And repeat. For instance, we are working with a freelance designer and we were having trouble sharing the latest designs with the rest of the team. In this context, implementing Abstract was a no-brainer. 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. 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 and to educate each side (this article from Alan has an interesting take and is worth a read).
- 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
- Focus on the essential and keep in mind that you are not reinventing the wheel (spoiler #1: you won’t): sometimes doing the same thing but better is enough. 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 (spoiler #2: you will);
- Get estimates from your tech team and 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.
- Share your roadmap (ProductBoard is a great tool for that) and update it as you go;
- Create tangible delivery objectives and organize regular internal product demonstrations.
Short-term focus on long-term needs
At Memo Bank, we see ourselves as an industrial project and everything we do has a long-term vision.
We believe that anything that we take lightly now will cost us at some point. Thus, we will almost always favour quality, even if it is more time-consuming, over the short-term gains of cutting corners. This holds true not only for product decisions, but also in terms of processes and tools.
For instance, we try to avoid dependencies & intermediaries as much as possible. And we are not afraid to invest time in learning exotic but promising architecture.
Obviously, the trade-off is a slightly slower pace, but we believe that this investment will pay off in the long run. When the time comes to scale our operations, we will be able to accelerate rapidly and confidently.
If you agree with our vision and want to join a long-term adventure, we are currently hiring for several positions. Check out our website.
Originally published at https://memo.bank/en/magazine.
