Building A Product Team: From 0 to 15

My name is Mike. I work at a company called Brankas. We're based in South-East Asia. We are a FinTech startup. So, what we do is we work in open banking in this part of the world who else is doing it really? There's nobody else that is doing it today over here. There are a couple of up-and-coming companies, which are sort of looking at this part of the world to build open banking. So, I'm the CPO at Brankas. Prior to this, I was working at a company called Zendesk where I was CPO there as well. I've been head of product for data companies and worked in the sort of hotel tech space. So, I've been around working on various different problems on different products and now in Singapore doing exactly that. That's a little bit of a background of myself and what we are today, I'm going to be talking about building a product team from 0 to 15. And so, this is something which I've done before, and I'm hoping that I can share some ideas, thoughts, use cases, and hopefully some takeaways at the end, which you can sort of use in your worlds across the world. So, we're going to talk a little about first 90 days, some of the learnings that I've had, what's important about a vision and North Star, then we're going to go into sort of the use cases specifically at Brankas around the iterations that we've had to go through over the past year. And so, just for some context there, I've been working at this company now for just over a year and we've already gone through 3 different iterations on our team. And that's been quite that's been forced in some way, at the same time, it's also not necessarily, it's just movement with the company and hiring and growth and all that. I'll talk a little bit about future improvements that we have planned. So, I'll be open to that and also finally, some thoughts at the end on what you can do to, sort of move ahead. First and foremost, let's talk about first 90 days and I'll talk in relation to what I actually did at this company as to how things needed to be set up. And just for some context that Brankas didn't have really a product team. They had like 1 product manager and 1 designer who sort of floated around trying to figure things out and it was a bit of a drive from investors as well as also the founders to find a CPO and so they hired me. And that's - really the first 90 days plan was sort of enacted upon. And in hindsight it was frankly speaking, it probably took less than 90 days to get to where what we're about to talk to you today. So, number one, set of vision. Set a vision. If the company doesn't have it, set a North Star. Number two, understand the current state of the organization and that means getting yourself stuck into the product. And finally, set-in sort of the initial priorities, not knowing precisely if they're going to be correct or not, it doesn't matter. Just get it done. So, what does that mean? First 90 days. Let's talk about the vision of North Star. Number one, your company needs to have a vision and if it doesn't then the founders and yourself as a head of product. Before you even start thinking about teams and all that jazz, like you need to set this. Be crystal clear as to what the vision of the company is and make sure that between yourself and the founders you're aligned. Now, some companies, they will already have it. My experience is that it's when usually, when you join a startup it's not really crystal clear because people are still trying to work out product market fit and all those sorts of things. And they may not see it as being a very important thing the reason why it's important is because with the vision itself, people are more easily aligned on what needs to be done next, especially if you're tying it to other things which we'll talk a little bit more about in the North Star metrics are the team goals and OKRs and KPIs and all that sort of thing but you need to be able to look towards something and get people something to rallied about. Number two, agree on a North Star metric of the company. What does the North Star metric? A North Star metric is a metric which you're trying to hit as an organization which defines success. At Brankas, that is the volume of successful transactions per month. Agree on this at all, if you can, at almost the same time that you come up with your vision, otherwise you're going to find the vision gets put in place and then people will just leave the North Star to which is actually the really important metric for the company sort of just all "we'll get to it, we'll get to it", and you eventually don't add before it, you've got an entire company complaining about what are we trying to do and that's something that you don't want to get yourself stuck into. Number three, do not start thinking about team structure as I was mentioning before. Don't think about team structure until these first two things are solidified and I have a very strong stance on this because when you are trying to figure out what is your vision, and when you're trying to figure out what is your North Star metric, what actually happens is that people start aligning thoughts subconsciously in a certain direction. You need that subconscious sort of a full process to be in place first before you go off and start structuring all your teams and whatnot. And finally, and this, I can't emphasize this enough, it's over communicating whatever your vision is, whatever your North Star is that you've come up with and over communicating this to your company all the time. So, for example, at Brankas, we have ESFs which is called the End of Sprint Fridays. So, we get together as a company, and sort of announced some of the cool things that we've been building or there are town halls as well where we're talking about like current status of of the organization. We continuously communicate, what is our vision? What is our North Star in the sessions? Because we have new people joining. We have people which are not always paying attention all the time. It's getting people into the habits, into the behavior of what is effectively the thing that we're trying to do, the thing that we're trying to do. So, that's what I would say is like for the vision of North Star, your first 90 days, what do you need to go off and act upon. Now, understanding current states, as I was mentioning before, this is one of the things that needs to happen and I'll give Brankas as a very clear example here as to what we had to understand is current state. So, when I joined it was just projects and products and things just like floating everywhere. And after deciding on what was the vision and North Star of the company with the founders it became crystal clear that in order for us to enable for digital financial services in Southeast Asia, in the open banking space, we have to work on what we refer to our two sides of the company. So, side number one is what we refer to as supply. So, on supply that refers to us working with, for example, large financial institutions, with banks. And it's a very project-oriented structure and it's not really conducive to a product mindset company if I'm going to be honest. But we have to do it because in open banking, building open APIs and all that sort of thing, it, what you'll find in this part of the world is that not a lot of banks have it. And they don't have technologies which are opening up to the FinTech companies to other businesses to connect to. They are very closed environments and in order to negotiate, say, for example, an access points for a private API, it's a negotiation. That's probably the best way to put that. Now, on supply side, we have project managers and they're looking after projects, which are normally on a timeline-based situation. Big contract comes in because an RFP for open APIs has been released by one of the banks and say Vietnam and we go in and we build in our architecture. With projects, after a period of time, they sort of get the scope decreases or you've completed the project, then it goes into a maintenance phase. It's a very different mentality to the other side, which is demand. Now, demand refers to basically us connecting to banks and aggregating all their services, their APIs into a single end point. So, that a FinTech company, a business, a startup, if they want to connect to multiple banks, they just have to go through one end point. And that's really the product side of our business. What that means is that on that side, it's all about, okay, how do we accelerate growth? How do we accelerate growth? And it also means that for our customers on the demand side, our merchants on the demand side, they don't have to think about connecting to every single individual bank. They just call one end point and they say, "Hey, Brankas, you deal with all the integrations" which that's basically what they're paying for is the pain that we go through with integrating with each of the banks which is also the work that we do on the supply side. So, supply: exposing services, getting that available, it has to be in place. And I have to say a lot of the things that we've done in the past for Brankas has been much more focused on the supply side - in order to provide for the demand side, which is how as a FinTech company, I want to plug in and so as soon as we set this like sort of mental structure in place, it sort of fits it like a glove for the company. Like people got the concept of media and I was like, Oh, a lot of people's response to that was like "Wow, finally, some like some mental constructs around what we're trying to do here". And so, when we, we talk, this is actually the thoughts, sort of the things that we say all the time. Let's talk about the first restructure as a result of setting the North Star, setting your vision and also setting up sort of the mental constructs around this. So, the initial structure really focused on product. Whereby we had already aggregated services across some banks, not many banks, I have to say a year ago. It's a very different world today but some banks in order to then provide for example, a funds transfer surface or a statement retrieval service. And so, what we did was we said, okay, like as a base where product managers need to be partnering with a tech lead and working on a specific product. And saying they have to focus on it before we have product managers which we're working on like 5 different things at the same time and when that happens. Yeah. Okay. You're moving things forward across many things but of course there's no focus attention to the detail, knowledge of a specific problem, a product and the problems that it's trying to solve. So, assigning a product manager to an individual product was sort of what we started to do after we had decided on the supply/demand model. Partnering them with a tech lead and understanding sort of the details as as to like what the the sort of technology stack that they were working on and understanding sort of technical directons is also important as well as also backend and front-end engineers. Now, these cross-functional teams. You know, we were trying to make a commitment at the time to say that, like you don't touch this team. This team is focused on this problem and solving it with this product. And so, that was the first step, that was the first step. And we did this across three of our core products. So, our direct products, which is a funds transfer mechanism, bank A to bank B. We also have another product which also sits on the PISP side, which is disperse where you can do a bulk transfer where say for example, you wanted to pay out payroll to multiple employees. You do that through our disperse endpoints and we connect directly to the bank to do that. And then finally again, a PISP products, finally on our what I would refer to as our account information service provider product. Our AISP product is statements and so that what companies can do is at the consent of the end user can pull transactional information directly from a bank accounts, for example, loan origination or they would like to use it for use cases like credit scoring and just understanding, for example, the purchasing behavior and income behavior of a particular end user. Each of these products then have a product manager, which we're looking after it with a cross-functional team which is operating so very traditional product team structure, I have to say and the idea here was that how we did that was because we were already in multiple markets. We tried to spread the cross-functional teams between different markets. So, for example, a product manager for direct is based in the Philippines, but we have developers which are based in Vietnam, for example, or in Jakarta or even in India and there's like, we tried to keep the team actually quite dispersed because from our perspective, we didn't want the team to suddenly start biasing towards the Philippines. If feature developments happened like as a product manager, as well as the developers, all based in the Philippines, you're going to find that they're going to start biasing towards just the customers in the Philippines. And something that we were trying to avoid happening. So, that gives you an idea there. Now, how does that then interact with these sorts of supply side of our products? Well, of our company projects. As I mentioned before service large banks. They are giant tenders that go out and we have to like when it's in relation to open banking, we go in and we execute on a project, which sort of it can be like quite a very aggressive timeline, especially in this part of the world. There is a difficulty with this and I'll explain the difficulties . The difficulty here is that, naturally you don't know how many projects throughout a year that you might win on tenders and you've also got a finite number of project people, product people, and developers, engineering staff inside the team. So, what happens? Well, we came across another large project, for example, we have restructured the team. What we found was that on our core product team on the demand side, developers were getting up to cross and what does that mean? Well, it means that the roadmaps, which are set by, for example, the statement product. We're not, they couldn't execute on those roadmaps. If a developer or a couple of developers got pulled off their team and sort of temporarily put-on projects. Also experience here is that it actually demoralizes a lot of people by doing this even though it's a necessity and we know it's a necessity as an organization that we have to do the split model because we have to build the infrastructure in order for the infrastructure to be connected to so, I mean, it's only natural where we have to do both. But how do you, like it was something that we had to sort of deal with over time, whereby how do we make sure that we still remain product focus knowing that the projects we're in that place but that being said, though, there was structure now. There was team structure and we had project teams operating on projects. We have product teams operating and products and all of a sudden, we started to ramp up and we got better at committing to deadlines. We got better at delivering better quality products because people were getting more in depth and we started producing new stuff faster as well. And by buying new stuff, I don't just mean new features, but I also mean brand new products as well. And so, this was effectively the productization of Brankas and this is when it really started. So, this happened in like I joined in January and we did the restructure, finished it pretty much by end of March and I think we all know what started to happen during that time period across the world, which led to the second restructure. So, the second restructure I'm just going to put a caveat in place here. So, building tech product is hard. I think most people on this call, whether in UX or design in research or product manager, engineers, you guys know this, I'm sure. Building tech product in emerging markets is very hard. Because you're not dealing with the traditional infrastructure that you get access to, frankly, speaking in more developed nations. You're dealing with infrastructure like I've mentioned before, things that we've had to build directly with the banks, directly with other large financial institutions. It's a lot of hard work. Building tech product in emerging markets during the worst pandemic in a hundred years: LOL is the answer it's about. And unfortunately, like we just happened to get the brunt of it when it all happened. And I'll be honest, we were nervous. We were nervous, the things that were happening at the time like we were thinking what a bank's going to do. Our like our company is going to shut down and like, all these thoughts sort of started flooding in. At first then the nervousness and anxiety then turned into like, okay, there are things that we can do, which we can control at the very least that's what we can do and so the second restructure meant we needed more focus. The pandemic meant completely remote teams. Now, we were already quite a remote company to begin with. So, people were already familiar with how to do this and that was okay. But we meant that offices, for example, in the Philippines, I was talking to the CEO and he goes, "do we even need an office anymore in Manila?"
And I said "Probably not" and he goes "Okay, let's scrap it". And so, we scrapped it like making like an entire commitment to scrapping pretty much all the other offices that we had across the region. I just said, guys, just work remote. It's like, we're already quite used to. Let's a 100% commit. But when you do that remote working style, you need focus. And so, we had to create this within the company. So, what would we do? We created one month top-down goals. So, the CTO, the CEO and myself, we sat down and we said, okay, what are we going to focus on to drive this company forward during what is effectively a period when people are feeling anxious. How do you remove anxiety? It sounds very dictatorial actually, what this is because usually you want to drive autonomy and you want to drive teams to sort of like come up with their own goals. But during times of anxiety, teams are not thinking about that first actually. And so, what we did was I took control of the autonomy and said, okay, we're going to come up with one month top-down goals and execute on certain things. Less teams, less teams means that more people focusing on problems that we know have a higher chance of success over others. So, even though creating these cross-functional teams, as I showed you on the previous slide having less teams meant that we're not getting rid of people by doing this. But what we are doing is we're creating more focus on the things which are most important. I'm going to bring in revenue. I'm going to keep this company alive. Because the pandemic it's unpredictable, it's still is unpredictable today. But back then lots of the places that we were working in Singapore, for example, had gone into entire lockdown and people couldn't move anywhere, traveling around. Vietnam had gone into entire lockdown. The Philippines and Indonesia was still running around and panicking and trying to figure that out. Finally, clear metrics. So, that we as an organization on top of the North Star these individual teams have clear metrics that they need to deliver. And these are very, very customer focused metrics. For example, the statement team would say, okay, we want 15 new customers live by the end of the first month of these goals. I'm just like being super categorical as to like these customers which need to be targeted so that the sales team goes, okay, I'm just gonna focus on these guys because I know that they're most likely to go live. The product knows the sort of features that going to be work on, worked on in order to go live or to get those customers over the line. So, clear metrics, what this meant was efforts disappeared from these teams generally speaking. We projects would, we had already operating it turned into a state of keep the lights on. Keep the lights on for those projects, but don't focus as a team on those projects any as much anymore, because we had a bit of a lull on projects, obviously, too because all the RFPs that had gone out were like a repo first voting these development projects and the current projects that we were working on had like sort of died off because people weren't interacting with as much. On the product side, we made some very, very educated guesses as to which products would drive the most traffic, the fastest and be more, most successful, so what did we do? We removed our disbursement product as of any form of priority back then. We remove the team from that and we reallocated the developers onto other products and we create focus on two products in particular. I've listed out here statements as well as also our direct products because from what we could see the use cases for those were crystal clear to our partners and we're going to bias towards the most volume. Remember the North Star metric that we said that volume was really important. And we said, if that's our North Star metric, then we're saying, and again, it's a little bit of a gamble. But based on the data we have already today that statements and direct we're going to be the most successful. Product managers then had to sort of reprioritised on certain things and developers, of course, had to then fit into new crossbones functional teams and we had to like there was a lot of shuffling around of people around to do this but what this led to really interestingly was that the statement product and a direct product went through a hyper phase of product developments and a hyper phase of customer acquisition. And we actually came out of like the different stages of the pandemic for a Singapore, for example, other parts of the Southeast Asia we came out guns ablaze and we were very happy. We had made this decision to go and go after one-month goals and be really specific about what we were doing and proving also to our investors that we can very quickly steer the ship even in times of crisis. And that was something that was a very, very important thing for us to do. So, after we had this one-month goal structure, we actually went through a phase of then winning a couple of really big projects with some Singaporean entities in finance. And what ended up happening was, as I was mentioning before the push and pull of developers between the product teams and the project teams but this didn't happen until October-ish. So, we had a couple of months of just like going after goals individually and that really actually changed the shape of how products are today at Brankas in a very positive light. So the third restructure was that these projects came in and we had to rethink going into the new year, what was the structure going to look like because what was ended up, what ended up happening was that product people and developers were getting quiet, I guess I would say the word agitated that they kept getting pulled and pushed around and going like, what am I actually doing? I don't care if you guys have got a vision. What am I actually doing? And how am I going to bring value as an individual to our customers. So, the third restructure. Pursuing autonomy, is sort of the phase that I call this, and we're still sort of undergoing - the restructure has already happened, but we've only just started with this autonomy. So, people had joined us we, as a result of these projects we went on a hiring spree. We're still going through a hiring spree at the moment. So, with more people becomes harder to sort of direct people in a certain direction. That was also, as I mentioned before, feedback from the company knew we needed to do it because we needed to create more focus again but give more autonomy as part of this. Functional versus cross-functional teams. We had to create a functional team layer. I'll get into that in a second versus a cross-functional team layer because the amount of work that was starting to pile up was building up. We had one customer as a motivator as a fact of the second restructure, we had one customer, we are now starting to win more projects because people were coming out of the pandemic and going rest of the world's not going to sleep. Let's keep moving forward. And finally, we did something pretty cool, so we implemented product canvases for each of the product teams and this sort of kick-started the autonomy of goals which I'm going to share a little bit about how each of the teams did this. So, functional and cross-functional teams. What does this mean? Well, we looked at the the projects that the new projects that had come in. Okay. And we looked at also the products that we wanted to work on as a result of acquiring customers after the hyper-focus phase, what we had to do was sort of split between cross-functional and functional teams. So, cross function I've already talked about. You've got a product manager with a tech lead or a team lead they have backend/frontend engineers depending on the products that they work on. And they also have we were starting to hire more QAs, believe it or not Brankas in its earlier days didn't even have QAS and then we were like, Oh, people were using our stuff we should probably test it. So, we hired QAs to come in and help with that. But cross-functional side just meant teams were getting bigger but they needed support from functional teams, which we didn't really have at the time. And we were actively hiring for quite aggressively throughout towards the end of last year. So, the design team, what's cross-functional. They're split between projects and products and sort of centrally managed and under a design lead. We have a UX research team and they sort of support the product managers on nuisance features that we want to go off and build and validate ideas, which sometimes the product managers will come off with and before it was more like, okay, I'll come up with the idea. Let's just go off and implement and not a lot of validation has happened. And the reason for that is because you're just doing first and begging for forgiveness later. Now, that you have more people and you have more customers, you gotta be a little bit more thoughtful about what you need to implement and what's going to be most beneficial to our customers. And then finally tech and product. So, we are an an API first company and it's really important that we get out API documentation and we write it up so that it helps with the onboarding of our customers but also there's the contents components of like how our products work, because now we've got customers coming to us. Sales teams need to know how the products work and where do they go to? Well, before it was just like as a product manager, if this thing works in this particular way or not, now you can probably imagine that was a very time-consuming exercise for the product manager to do that for a growing sales team. So, having a bit more structure on an internal knowledge base, as well as also external knowledge base meant that less of those conversations were happening. So, design, research and tech product, they split themselves across the project side and the product side. On the product side, the individuals are sort of assigned to certain products, but like they can't say like 1 designer is assigned to 1 product, we don't have that sort of flexibility at the moment. And we haven't really had a need to do that yet either but like, what it also does is that because the designers are always excited about working on new stuff, it gets them sort of involved with like all the different things that are happening within the company. And for example, it makes it a lot easier to communicate the design system and ensure that people are in line across the different teams on this design system, for example. What we also did was that we applied what I refer to it as a product canvas. And so, towards the end of last year, building into Q1 this year, what I asked the teams to do was to come up with, okay, so we have a company vision, we have a North Star but for each team to also have their own team vision and their own team North Star. So, the reason for that is because let's say for example, our statement, product, pulling transaction information, it's solving a very different problem to our direct funds transfer products. I mean, statement doesn't move any money around versus our funds transfer product does. So, it solves for very different use cases, very different problems in the market. And so, what does that mean? It means that they've got their own thing to work out and so coming up with a team vision means that they can rally behind that particular vision and also, they have their own North Star metric because a North Star metric forward statement is very different to the North Star metric for our direct team or our integrations team or our dispersed team or whoever. After this was for them to come up with a goal - three goals, which they were going to achieve across the next quarter. Now, this wasn't top-down, this is different to the gold ones that were separate for. We managed to execute on those. Right now, we were talking about goals, which the teams themselves had to come up with and actively pursue. So, this is the embedding of autonomy. This took a long time and I would highly recommend if you're going to be going off and doing something less like this with your teams then expect three to four weeks easily. So, please give yourself time and set a structure in place for people to follow set deadlines and whatnot. I'm going back to our three goals. Each team has for each goal has a metric of success, which is assigned to it. So, it was very similar to the OKR model, but like I think that acronym has been done to death. So, I rather use words, which are much more easily understood by the team and for each goal that they have are steps to achieve up to five steps. So, that could be sort of features that need to be delivered that needs to mean sort of partnerships needs to be signed. But whatever it is each goal needs to have up to five steps that need to be completed. Sometimes some teams will only have one step. They need to do one thing in order to achieve that goal. But that one thing may take the entire three months to do it but like the point is that you are creating action items effectively across for example, our steps to achieve are tied to for example, for our integrations team are tied to epics that are within JIRA, we use JIRA. And so, what that means is then we can then tie that to the goal. And when we tie it to the goal, then we can say, okay, as a percentage completion, this is how much that particular app been done. And then therefore this team is this much closer to achieving this are Q1 targets that are their Q1 goal and that is a sort of blue box at the bottom there were stories sub-tasks slash action items, sort of sit. Now who owns the canvas? Well, it's the product manager. Because ultimately though the teams that are underneath them are not directly reporting into the product manager, they all held responsible for the success of the product. I mean, live with the product that you die with the product. If you're the product manager for our direct funds transfer product successes really comes down to like successful direct bank transfer transactions that are occurring. And therefore, at the end of the first quarter if, for example, none of the goals have been achieved then you're going back and saying, well, what's the reason for this? Did you over promise and what will end up happening in Q2? Because I did something similar as this too when I was at Xendit, you'll find that on in Q2 is that you go a lot of teams will go, wow, we didn't achieve a lot of goals. Maybe we need to really think about these in a little bit more detail. I'd be more realistic. Because people tend to get over promising with goals at the beginning later on when we start doing Q2 goals, they'll start thinking a little bit more realistically about what they're trying to achieve and that's only natural. I expect it to be interrupted. Cool. So, that's really the three iterations that we went through and we've just started sort of our Q1 goals obviously, and so far so good. Some teams are running a lot faster than others. And it's interesting to see the reasons why behind that it really creates some proper detailed discussions as to what people are focusing on and that's really important. Oh, and one other thing, which I didn't mention was that also, it meant that each team had to come up with a list of responsibilities, which they are looking after over other teams. So, there are always situations where in cross functional teams where responsibilities may cross and what the purpose there is to negotiate, who is responsible for what responsibility, sorry for what within a team and how is that defined within a responsibility manifesto but like other than that, like that's pretty much the official structure that we have. So, things that we are moving towards to improve. So, we have roadmaps they have fairly predictable, but now that we have goals, now we have things that we want to execute on. I am expecting for us to generate more predictable roadmaps. What I mean by better is that I want to make these roadmaps much more automated, more linked up. So, there are really cool products out there. Aha, Roadmunk there's a few others. We may or may not use those sorts of tools. I'm not a hundred percent sure, but what I would like to do is to tie what I was referring to before in previous slides, I'll just go back for a second what I'm referring to is like the steps to achieve on the stories and sub tasks. We can tie that directly to a roadmap and it's automated on the fly, built into a process which has become sort of behavioral for the product people within the team. Hiring more leadership is something that needs to start happening fairly soon. I'm not a fan of massively hierarchal structures and I try and avoid that as much as I can and I'm the first to admit this and I tell this to my team all the time is that unfortunately, I have a limit as to the number of people that directly report to me and I know what that limits is that the magic number is nine and I'm currently over that number and so I know that there are some people which I am definitely spending more time with and mentoring and helping and supporting over others. Not because I don't like other people, it's just because of capacity. You've only got 24 hours a day. Well, most people do anyway. So, that's something which we have to we have to think about is like, how do we hire more leadership into the team in the place that it makes the most sense, and the place that makes the most sense and then finally, and this is a difficult one is addressing problems relating to Conway's Law. Guilds is something that we're considering. I think other companies have done this before, so like Spotify, I believe done something similar to this but it's more about testing to see if these ideas work. So, what does Conway's Law? So, organizations that design systems are constraints of reduced designs, which are copies of communication structure of these organizations or in the words, when you start growing communication exponentially becomes more complicated. And on top of that the way product gets built within a company starts to follow these communication lines. So, for example, how does a front-end engineer in one team know to put in a certain design system in place based on other product teams and how do they make sure that everything seamlessly fits together and how do you keep that moving fast? And that's a HL question that people have been trying to address for the longest time and I don't think there is unfortunately a magic bullet to do it. However, what we're thinking about so again, similar to companies like Netflix or Spotify is building things like guilds. So, it means that you have cross-functional teams within cross-functional teams, maybe as a way to think about it. But what it really means is that say, for example design and front-end developers are working on so many different tasks, but they have a concept around the design system that they need to follow and they have processes, which they want to make sure are made as effective and efficient as possible in order to ship features on the front end as quickly as possible. From all the way from ideation and research and design all the way through to front end build. But the product manager is sort of sitting in between, but doesn't necessarily have to know about how, like these things are implemented. They just need from the product managers perspective, they're just going, just do it as fast as possible. I don't care how you do it, just do it. And so, guilt is one way of doing this. So, what does this mean? It means like setting up like a knowledge sharing session and doing this once every couple of weeks and saying, Hey, I'm going to show you something that I've done which is pretty cool. This animation, which I built, which you should probably use across different products because I think it makes the I don’t know, the UI more fun. Let's say let's call it that or they may be talking about like, sort of processes in order to make sure that they are holding themselves accountable to making that more effective. Now, I actually implemented something like this in previous companies. The great thing about this is knowledge sharing is very important. The problem with it is like, is it just a way to waste time one hour a week? Whereby you just get together and go, ah, talk about stuff. And then you don't actually remain focused on actually doing the actual fixing. Now, how do you tie a metric to this is very difficult. What you sort of have to listen to is the organization and the people which are involved and seeing if like these sorts of meetings, these sorts of get togethers are actually effective and making a better product. In this case, a better user experience for customers. So, that's sort of on the horizon for Brankas. So, these are some of the things that we're going to start testing and iterating on and seeing if they work, if they don't pull the plug, try something else. So, I'm just giving you guys some thoughts here. So, yeah, that's pretty much our journey what we went through. I just wanted to leave you with some final thoughts and I've sort of gone through this but really three key takeaways. Three key takeaways and number one, and I can't stress how important this is that founders must have a vision of North Star for the company. They have to, if you don't have that in place then everything else that you're going to do, you're just going to be doing it. But you're going to feel like that's you're peddling on a bike without wheels. And that's what it's going to feel like make sure there's alignment, make sure those hard conversations happen because sometimes I'll be honest, founders don't want to have these conversations. They don't want to deal with this because they're thinking. Well, this is - we just need to execute a build and then get things done and that's what sort of the reaction can be to that sort of mentality. Number two, when you first started to get stuck into products early, like yourself go and own a product like go, I had to do that myself. Like I was doing either at the beginning of when I started at Brankas because I was very tied into integrations work. Because I was sort of the building blocks of our customer facing products, understanding how our implementations were with directly with the banks and how we were connected. And just getting an optimizing that and understanding how that eventually a product manager took over thankfully, because that was starting to become unwieldy but I got stuck in at the beginning. You have to, it helps you understand what's going on. Otherwise, you're just making suggestions for team implementation, which don't really make a lot of sense. Number three is implemented team process and team structure quickly, effectively and efficiently. Why? Because as you seeing that's going to change anyway. So, it's better the devil you do rather than we don’t make some educated guesses away and B, don't be scared to iterate in the future because you're going to have to. Don't think that like, Oh, I sent like this perfect structure in place. It's never perfect. And it's going to be chaos anyway, especially in a startup. Just put it in place, knowing that you're probably going to change it again in three months from now and who knows you might come across another pandemic, which is going to sway your decisions in a certain way in the future, again, as well. So, that's all I have today. So, thank you very much for your time. I hope you are able to take some things away from this presentation if you'd like to have a chat feel free to reach out on LinkedIn fairly easy to find Mike Dickinson, Brankas, you'll see me there and yeah, I hope you found this useful. Thank you.