What I learned as a CPO of a growing team from 4 to 140+

Lukas Hurych
14 min readMay 13, 2020


Things were slightly different when there were just the 4 of us then they are today (140+). I talked to the customers about their pain points, I did the A/B testing, we built the MVP from ideation to delivery in one small room of 20 m² in under 3 months. I’ve tried to summarize the lessons we’ve learned and what hurt us on the way — mainly in the area of product, strategy & team.

I got inspired by a conversation with a friend of mine (Product manager), we were talking about all the struggles we are going through, how our views on different subjects have changed over time — product, strategy, teams, objectives, and many other related topics. And it came to my head, that we take a lot of things for granted, but it’s not like that for everyone.

What is your endgame?

What has completely changed is our thinking about product strategy. In the beginning, we were focusing only on growth and we were building a product with value that was supporting this objective. We were also more thinking in terms of what is now and maybe what is in the near future (just a couple of months from now). But we didn’t really plan our long-term strategy & vision.

When we think about product strategy now, we always try to think ahead and work backward — go from the future, and related company-level objectives, and all the initiatives (problems to be solved) that we can do.

We are all clear on where we want to be (what’s our ambition for let’s say next ~5 years) and why are we doing it (what’s our purpose).

Fighting in cold blood over priorities

When I ask fellow CPOs, and Product managers “how do you prioritize and decide on what to build next?”, I always get the same laugh and similar answer “don’t we all want to know?”. It’s not an easy task, especially in a hyper-growth stage, when you are trying to balance growth, profitability, and other business objectives in a healthy way.

It’s always a tough process to balance our priorities, especially when on one side there is growth (customer engagement), on the other side there is profitability and revenue (customers happy to pay for the added value), and from another side, there is credit/fraud risk, and compliance also pulling into different directions. Deciding on what to build next is not an easy task, and there is a lot of inputs and insights that we consider — from a simple cost/benefit analysis to detailed data analysis where we try to find stories, or when we talk to our customers (face to face in deep interviews or for example via surveys or other experiments mentioned below).

Our roadmaps and backlogs get easily messy when we see all those problems that we can solve. We think it’s healthy to once in a while (once per quarter or half-year) basically start over. We do a total clean up of everything, and we get back to our objectives, and strategy to see if we are still on track, and everything is aligned as it should be.

Aiming for impact with Strategic roadmap

We don’t use roadmaps as a tool to commit on launching something in 11 months, 21 days, and 3 hours, but as a tool to understand how different initiatives are aligned with our business strategy, teams, and objectives, and if the story makes sense as a whole, and if we are really able to do this. We use it to see if we can work backward from our high-level objectives to deliver.

Sample of the definition of our objectives
One of our older roadmaps that helps us keep all teams aligned & in sync

We spend a lot of time in the Product discovery stage, you can find a couple of examples of how it helps us make smarter data-driven decisions below. We can better understand the impact we are aiming for. At the end of the day, this whole process gives us more than just a feeling and we can then see if we’ll be able to achieve the objectives we’ve signed up for.

Our strategic roadmap contains only objectives / bigger initiatives. Prioritization, discovery, and management of individual pain points, and features are up to the specific team (and its PM).

For the large objectives, we have (once per quarter) an all-day workshop with the whole leadership team to create alignment among us and bring all the valuable insights to one table. There we agree on the objectives we’ll be focusing on next, and we can start the discovery of what kind of problems we want to solve with specific initiatives.

We don’t want our teams to live in isolation and that’s why we all rally around the roadmap so everyone can understand why are we doing things and can have a say in the whole process from the beginning. And not just in the context of their “mission”, but in the context of our whole company and our product strategy. For example, with all the teams we do this on a bi-weekly basis.

Data-driven & customer-centric without bullsh*t

It’s not an easy task to build a full analytics/BI stack that’s not suffering from data fragmentation and is not biasing your data insights and stories. When talking to teams in banks and other organizations, it’s really problematic to achieve this level of detail and build everything up from one customer.

Our current data analytics setup is fully revolving around our customers and their stories (we call it customer profile) to help us understand different behavior, and how can we help our customers.

We’ve learned that average metrics will take you to hell. We’ve been victims of this in the past, we were focusing on increasing the conversion rate of our onboarding process from 40% to 60% but nothing was happening no matter how many experiments we’ve run. Only later did we find out that we were in the “average metric trap”. We were not looking at our customer segments and their individual behavior, we were trying to influence a metric that had a range of 7–85% depending on the specific customer segment. And our experiments were influencing different customer segments in a different way, but at the end of the day, the average remained the same.

The same applies to a portfolio view or the PnL, you think you might see stories in there but believe me that in 90% of the cases you should not be listening to them. It’s easy to make a judgment on why only 17% of customers are using a certain feature.

When you look at the portfolio, you think you understand your customers. For us, if we take a look at our whole cohort of customers acquired in 2017, we can see that we are breaking-even in ~14 months (not a real figure, just as an example). Let‘s say that this figure is really high and we want to push it down. But when we dig deeper, you can see completely different behavior for specific customer segments (some are breaking-even in just 6 months and it takes 3 years for others).

We want to continue with fast growth but in a healthy way, and not in a way of some big startups who are completely missing fundamental metrics and are betting on 200x multiples of their revenue. In my opinion, the fintech industry is really tough when you compare it to others like e-commerce, or B2B SaaS. Insights like these help us see behind the corner and make better decisions for the future.

Initiatives & data-driven business cases

At the beginning (6+ years ago) a lot of our decisions were based purely on a (slightly educated) feeling, we don’t do that anymore. We base our planning and strategy around objectives and initiatives (big problems to solve) that are supported by data-driven business cases and insights. In our approach to deciding on what to build next, we try to consider a lot of different angles and sources of insights. I’ll mention just a couple of them but I believe I could be talking for hours just about this topic. We also ask the question “How can we give value to the customer for which he’s willing to pay for?”. In the finance & banking segment, it’s usually expected that everything is for free — from current accounts to travel insurance.

Ghost door experiments are telling us amazing stories. One of the examples we like to do is launching different kinds of experiments to help us understand the actual customer behavior while also understanding their motivation. Recently we’ve launched a simple ghost door experiment, where we’ve added a button to our Transaction detail that was essentially doing nothing, it was there just waiting to be tapped and then we asked our customers a couple of questions to help us better understand their motivation. We’ve taken these qualitative insights and we’ve connected it with our customer-centric data analytics platform to understand the stories of our customers in-depth (who are they and how do they behave).

Ghost door experiment

From this, we are able to build a pretty strong data-driven business case because we were able to catch the user in the exact moment that we wanted. We know from experience that these kinds of experiments are telling us different stories than directly asking customers in surveys (big difference between what customer says he/she will do and what he/she actually does). Of course, we use surveys as one of the customer insights gathering methods, but usually to validate hypotheses based on previous experiments or user interviews. I’ve seen a lot of business cases that were mostly based on a lick of a finger and looked kinda credible, we don’t want that.

Sometimes it’s really hard to gather relevant insights when you are focusing on retail customers, it’s hard to segment the customers. When we do user testing & interviews, we usually hear 24 different stories from 20 customers on why are they using our app. But they are great insights to help us decide on what to build next and how to solve their problems. The ultimate target group is a segment of one, personalizing everything for every individual user and his/her customer journey and needs. We still have a long road to achieve this.

Feature flags are also a handy tool when we are trying to get more specific and deeper insights — on a limited number of customers or in a specific group of customers. You can get the best insight when the customer is in the natural context. And even the simplest version that you can build in a week can tell you a lot.

We spend a lot of time in product discovery, and we are trying to find the best ways to solve problems for our customers (and how to make sure we are building truly useful products that customers want, and not just nice usable features). I believe that in finance the biggest challenge is compliance & legal, how can you deliver the top UX while also staying compliant to all the laws (for example anti-money laundering is making our onboarding process more difficult for the customer). I am sometimes frustrated that things take much more time than anticipated just because of the regulations that we need to comply with. But if it was easy, everyone would be doing that, right?

Methods that we use in product discovery

We use a lot of different methods to gather insights from our customers, stakeholders, and team members. We put it together and we see the stories that can help us. For each initiative, we have a shared Google document that contains everything relevant including goals, big-picture view (how it fits into our strategy), description of the problem and solutions, legal requirements, and much more. We take it as a single source of truth that needs to be updated and we need to make sure that everyone understands it. Also, everyone can have a say in the process and we try to keep everyone in the loop from the beginning, so we eliminate all the surprise like compliance & legal coming up with something critical 1 day before the launch and saying “guys, you can’t launch this at all”. It’s much better to keep everyone in the loop from the beginning, we create products together.

Sample initiative description

From 4 to 140+

We're still building the “same” business as we had been more than 6 years ago, but my responsibilities, strategic view of our business, and day-to-day have completely changed. I was the first Product Manager, Product Designer, Product researcher, Front-end developer (sometimes also Back-end developer), Data analyst / BI person, Customer care agent. And that worked up to a certain point, but I had to start looking at things from different angles and perspectives to grow and develop the team around me.

I’m really grateful that we’ve hired an experienced person (Chief Growth Officer with 15+ years of experience in top-management in finance) that has helped us in many areas — from the team structure, managerial & leadership skills, to see a bigger picture, and much more. It was a big kick-start for us.

In the beginning, the product was features and backlog, and that was it. It slightly shifted into initiatives, but we were focusing only on building things that were good for the customer, and this has changed a lot, the product is something much more for us now. It’s a combination of a Customer-centric (and customer-first) mindset and a Commercial mindset. So not just building things that customers want, but for what are they also willing to pay for. As product guys, we are responsible for the whole picture, which is an extremely wide and challenging task.

Our whole team is the most important thing, and we are always trying to make things work better. Even after 6+ years, I have to say that every month, every week, and every day brings a new challenge and it makes us excited as in the beginning. And if I’ve learned one thing, it’s that when you think you communicate enough, you never do (you have to keep everyone involved from early days, for us, it’s especially true with our customer care team).

Product at Twisto

As already mentioned, the Product at Twisto is a really wide and challenging area. We are trying to gather everyone’s input and views to create a product strategy that makes sense. And a product manager’s job is not an easy job as they are in a constant grind in the middle of the battlefield.

Does the ideal team exist?

In my opinion, I think that the ideal team doesn’t exist and that it depends (our CEO will hate me for the words “it depends” 🙂). However, there are a few traits that we really value for every team and team member.

✅ People & interactions over processes and tools

I honestly don’t care if we use tools like Trello, productboard, and others as long as they help us achieve our goals; those goals can often be achieved with just a flipchart, marker, and a couple of people in the room.

✅ Full ownership & Autonomy

I believe that when we all feel that it’s our problem and we need to solve it, we can all pull in the same direction. And when a problem occurs and everyone takes up the ownership and is trying to solve the problem, it’s the best culture you can live in, definitely not the blame culture that works in a lot of organizations. You should also rely on yourself and on your team to make the right decisions, limiting the number of needed approvals that would just slow you down. We know that finalizing one good product (solution to a problem) means we need to come up with five others that will be rejected within our discussions. The setup in which people are not blamed for coming up with ideas that do not make it into our roadmap means they will not shy away and can propose the next great thing.

✅ Openness & no politics

When something is bothering you, let’s talk about it, and don’t spread gossip.

✅ No silos, no handovers, just one team that is working together

All teams should work together, there should not be any levels of management and handovers that are not necessary. And everyone should be involved in the whole process (especially engineering).

✅ Missions to launch and problems to solve

Not a tickets and backlogs culture.

✅ Fu*k seniority, listen to arguments

Maybe harshly said but we believe in listening to arguments and everyone at Twisto can have a say in the process.

✅ Responding to change over following a plan

It’s not always easy, especially when you committed to delivering something, but I believe it is more important to respond to changes in the market or in the environment than just sticking to the plan (which is what the waterfall product development methodology is basically suggesting).

This is how we currently structure our teams. However, we try to tweak the whole team & product flow pretty often to help us achieve our objectives, keep everyone happy, and follow our growth. We organize our teams around objectives and initiatives. For example, mobile apps are not a product for us, neither are areas like API (or GraphQL these days), onboarding flow. We are rallying around initiatives/missions that we want to deliver to achieve our objectives.

We still have a long way to go

We know that things are not perfect, but we are trying hard to make them as best as we can to keep everyone happy and to achieve our company’s objectives. I must say that I am quite happy when I look back on the development and personal growth we went through just in the last year. I’m looking forward to all the challenges that the growth will bring us, including my recent change of role from Chief Product Officer to Chief Portfolio Officer.

Thank you for reading this article as it was quite long. I hope you’ve found something useful and relevant to you. I could talk for hours about all the individual areas and the lessons we’ve learned, but let’s keep that for follow up stories. Are you interested in more detail on certain topics, or do you want to talk about it and share your view? Let me know in the comments or at me@lukashurych.cz, I’m more than happy to talk about it!



Lukas Hurych

Credo Ventures by day. Telling a story with music composition by night. Past: co-founded/CPO Twisto.cz, madebysource.com (now Avocode.com), abdoc.net. Pilot.