Cross Department Collaboration For Product Managers In A Scale Up

Hi, guys. My name is Abrar Akhtar. So I'm here to talk about cross department collaboration in start-ups. So let me just tell you a bit about the start-up. It was mentioned briefly. So what we do is basically the tinder for investors. This is kind of the quick way of putting it. So we match start-ups with investors on a matchmaking platform where investors, if they're interested in a company, they swipe right. If they're not interested in the company, they swipe left. So we work with VCs, angels, we've got our first case actually in the Netherlands. So how this all came about for me is my background is in London, and I met a Dutch founder who had an events company also that used to match start-ups with investors physically, and he did that for about eight years. So he had a very good network of VCs and angels, and he said, OK, you know, I want to take this on online, you know, I can't be doing these events. You guys travelling around the world doing this and organising the events all the time, he says, OK, I'm done with that now. So, that was the idea. Ok, let's move it on to the app.

I moved over August 2017 and we launched the app on the App Store, on the App Store in April 2018. And I think it was just two weeks ago that we had our kind of really big success story in which a founder had raised 500k euros from our platform, from an investor. So that was a really good kind of a proof of concept for us at this point. So among other partners, we have some enterprise partners, people like the city of Rotterdam, other accelerators around Amsterdam. So we're really growing in the ecosystem here and then going to move over to other places.
So what does our team look like? So as head of product, we're very lean. When I came in, you know, there were three of us. We didn't really have any processes. We grew very fast in the first year and then we were like, OK, now we need to introduce some processes. It's not just myself and to outsource developers. And you know, we have now a whole team. So we have two designers, three front end developers, two back and developers and iOS developer and Android developer product owner, which is basically me, one data scientist. And some of the team is outsourced in China, and some of the team is in-house.

So, you know, we're dealing with different time zones, we're dealing with different types of communication and it's quite a large team. And we also got four different platforms. So we've got a WordPress platform, which just tells you about the business. Then we have an iOS app for the investors and an Android app for the investors and a web platform for the founders. So the founders have to go online and create their profile about their business. So kind of what the attraction is so far, how much they've done. So they can't really do that on the app. But for the investors, it's about kind of seeing deals flow on the go. You know, a lot of them that we speak to, they spend time going to events, you know, travelling and doing this and that. So for us, it's about a kind of deal flow in your pocket in a kind of a casual way. So it's about when we have a team like this and we create our own processes, we start from what it is that we need, rather than trying to take an existing process that has a lot of jargon. I mean, I read a lot of things, you know, data-driven product manager or customer value. I mean, to me, it just sounds like buzzwords that make a good kind of diagram in a presentation. So we want to break it down. What exactly do we need from each other? So we have someone who writes the copy for everything that comes onto the platform, someone who does the wire frame, someone who does the design, myself with the management and what's on the product roadmap, someone who's also going to find the bugs, you've got front end developers, we've got backend developers, and every single one of these things is dependent on each other.

So, if we don't get the copy, we can't launch the product. If we don't get the design, the developers can't start. If the front end, if the backend guys haven't got the endpoints, then the front end guys can't develop. So, it's like we're starting from this and we've got 10 people and we need to make it all flow. And that's basically the challenge that I have. And that's what we're trying to do. That's what we're trying to fix. So we've been trying to improve this over the last year because as I said, we grew really fast. And, all of a sudden, we had 10 people sitting there and we need to get them to flow and we need to manage them. And how do we do that? So the first thing was that we needed to really establish what our priorities were as a company.

So we split that up into little teams. So you get the sales team and you get the product and development team. So every quarter we sit down where I sit down with the sales and the CEO, the management. What do you guys want to sell in the next few months to your customers that we don't have right now? And, break that down into the next quarter and say, OK, this is what we want in the next four months or three months, and then we break them down again into releases. So two week releases, two week sprint plans. And that's where we have everyone who's involved. So we need a copy from someone in that sprint. We need design from someone in that sprint and then we need the development as well. So everyone sits in a weekly meeting. So we have a two week sprint. But then we also have a weekly update meeting where everyone sits down and says, OK, how is it going so far? Are you on track for delivering this in the current sprint? And then I also have the same conversation with the management and say, you know, because it was such a small team, everyone needs to be in the loop.

If we say to someone, if we say to ourselves, for example, for this client, we're going to have this feature ready in two week time and then you can go and sell it to them. They want to know a week before, is this on track? They don't want to know, OK, we said you were going to deliver it on this day, and now we have a delay. They want to know, like as soon as there's a delay, what's going on. So this is the way that we reduce the friction. So everyone's in the loop. So sales will say, OK, what are you guys doing? I don't know what you guys are doing. You know, you guys said, this is going to be on this day and now you're coming to us saying it's going to be late. So, you know, this is how we keep everyone in the loop, so everyone knows what's going on. And it's a lot of meetings, but really, it's not. It's a daily stand up and a weekly review with both sides. So it's not really a lot on our own and to keep everyone in sync and to keep everyone happy. It's really worth it, even though, you know, I hate meetings and, you know, et cetera. We also have kind of like slack updates as soon as someone's added a design to Zeppelin and everyone else can go in and review, et cetera, etc.

So it works like that as well. And this is a nice kind of framework similar to, you know, similar to what Rory did was, you start from the design sprint in the first stage, you've got to say, what's the product backlog? Then you go, then you start with getting some wire frames going and then you have some wire frames. And then once you have the wire frames, then you can give it to the person who's writing the copy because the person who's writing the copy needs to know what the design looks like, because otherwise they don't know how much copy they have to write and how the designer has it in their mind. So that's where we go through the whole process. So, you create the sprint and then you have a sprint review, you go through that process. But this is nice in theory when it actually comes down to it, it falls apart. So for me, it's all about people over process. If you have people that have multiple skills, then I like to let them take initiative on certain things. So if a front end developer who we trust comes and says, OK, this is the framework that I want to use with my experience in the front end, we said, OK, you go ahead, we'll give you the kind of autonomy to do that.

So it's all about it's all about the process. So, you know, if we go back here, I mean, we've got this whole process of design, but if you've got a very good front end developer who has some background in design that turns around and says, look, you know, for this particular feature, I can just take the initiative and I can go ahead without design, right? And we can leave the designer to work on some other things, because it's just a matter of adding an icon there. Let's not wait until the designer makes an update and then we come and approve it. Then we get the copy and then it goes into export, et cetera, et cetera. If you've got a front end developer, just get them to make the change and then we can see on a staging environment and then we can comment on that directly. So you can't do that all the time, but in certain situations, you need to know that this is the way to do it and the process is not the king. You know, you don't want to just go around and get the guy to write the icon just to go through the process. Just so then, you know, the designer feels better that, you know, the design has gone for him, and for, you know, for people to do that, you need to let go of egos as well.

And it also happens from my side that I'm talking to the business on what they want to build. But if I make a suggestion to them on what we should do, they also need to be open and say, OK, this suggestion has come from the product owner, from the head of product, and we think it's a good decision. So we're going to go with it rather than the guy who is making the last decision has the final say. So it really comes down to dropping egos, and it's all about the best ideas that should win and not the people with the title. So especially when you're in a small team, titles like head of product and CTO and head of UX, they mean nothing because there's only 10 of us. So, you can make yourself feel better about it, but at the end of the day, whoever comes out with the best idea, whether they're someone more junior, then everyone needs to be ready to take that on board, you know? I like to think about it, and I'm going to mention this layer, it's, you know, similar to a kind of sport.

I'm a big football fan and at the end of the day, when you have the best players on a team, you know they're going to win the game no matter who the manager is. And you see that with a lot of statistics. The teams that spend the most money that have the best people are going to most often win the game. So really, it's about picking the best people. And another point, because everyone is reliant on everyone, so, you know, we always like to say in terms of design, let's keep the design two sprints ahead of what the developers need because so many times you'll be in a situation where the design is late. For some reason, they need some more feedback. The developers are sitting there with nothing to do. Right? And that resource is going. That's time going. And then you're just like, This process is just not working. So then, OK, stop development for two weeks. Get the design ahead of the developers, and then we can have some kind of synergy going. Again, it's really just down to egos and people, and if someone really wants to have control over that process, like, say, me, for example, if I really just wanted to have the final say on everything I could do, but then people will think I'm an idiot and they won't want to work with me after that.

So, you know, if someone has a good idea, wherever it comes from, you just have to be open to it. And you have to go for it because people will trust it. It's all about trust. I mean, I need to trust that the CTO will make the right call on a tech stack or any kind of other third party service that we want to integrate that will say to the developers, OK, you guys have a look at this and you need to trust that decision. And then the developers also need to trust that we're making the right decisions on what it is to build what features are next for our users. And we also need to trust that the designers are going to produce something that is of value that's going to be intuitive. So it's all about trust across the whole process. And when it comes to the best ideas winning, the point is that if you can't convince the rest of your team on your concept, the chances are that you won't be able to convince the users either. So if you've got a concept, if you've got a feature and you pitch it to three of your team members and all of them say no because they don't understand what you're saying, the chances are the user isn't going to understand what you're saying, either.

So that's the first point of really validating your idea and getting it through the team. And as long as they're open you always have to watch out for people, everyone's got an opinion on everything. I can have an opinion on whether that icon should be moved there for design, and I can have an opinion on whether we should have this feature and I can have an opinion on what tech stack we should use, right? But at the end of the day, there's people that are hired with the expertise that you need to give them too. So when we're having a discussion across the whole team and there's always one person who's got an answer for everything, he's got a suggestion for everything. You know, you need to watch out for that because everyone can have an opinion on everything, but it's about what your opinion is based on how much experience you have to weather that opinion. And especially with these kinds of new titles, you know, you've got so many new titles, product owner, product manager.

I call myself a different thing every day, depending on who I'm talking to. So these things are new and the roles are overlapping as well. So as soon as you start getting hung up over your titles and you know who's doing what, then it just gets really messy. So it's just about what is the output and how can you all work together to do that? What was it? Yeah, so this is just another sign of how to communicate with someone, what you want. So for me, I could say to someone, you know, the user must be able to. I really like this example that I read that I could say to the designer, right, that the user needs to be able to download a file. And now that's up for the designer. That's my requirement for the product. But now it's up to the designers to say, where does that download button go right on the platform? Where is it the most intuitive? But then if I say to the designer, how can you add this download button and can you put it to the right of here? He's not really doing the job. He's just doing what I'm telling him to do. There's no creative input from him or her, and it's just kind of following all the same way as if I go to the management and I say, What are we going to build? And they say, we're going to build this and this and this.

And then I just become basically an admin person who's managing this delivery without any real say so. So you know, you've got to know what people do and you've got to give them the chance to do that. So here you have the kind of, you know, the roles are overlapping. My conflict comes with the business side of the management. I work really well with the dev team the UX. So we really get along well. We hear a lot of user research wireframes. I speak with a lot of our investors. I go and meet them. I also go along with the head of UX to have these conversations. So we're all understand what is needed. I mentioned sports, and I think really this is what stays in my mind. So, you know, it's people over process. I mean, you can have a great process and I can go today, I can go to Arsenal and follow their training process. But I'm not going to be a professional footballer, no matter how great the process is, But also on the other side, someone with talent will also fall apart without the process.

So like an analogy that I like to see from the example that I gave, which was, you know, if someone wants to take the initiative, someone has the idea, you let them do it. So for example, you know, a manager can have tactics of, you know, certain ways that a team should play. But if a player, for example, just takes the ball and dribble past two or three people and scores from 30 yards and hits in the top corner, the manager isn't going to say to him, you didn't follow the process that I said to you, you were supposed to do this, you were supposed to do that right? He's going to say, OK, well done. But then if that same player always tries to do that, then the rest of the team are going to turn around to say, OK, look, you did it once it worked well. Now let's follow the process. So that's all, there's a limit and there's a boundary to everything. So you need to let people have the kind of freedom to go in and express their ideas and have no bad ideas. And if someone has come out, if so, for example, if a designer or one of the developers comes up with a feature, that's great, you have to consider it and you have to push it through rather than saying, OK, you know, this is the developer and you know, you know, we're going to do the back, we're going to do the pipeline planning later.

We'll let you know. You know, that's the attitude of someone who will say, Hey, how about this feature? I will discuss it with you on Wednesday and kind of just kick it into the long grass, you know? But if someone wants to take the initiative, you've got to let the best ideas win. And they also always come from the most unexpected places. So, you know, the main thing for me is that you have to maintain integrity when you're doing it. It's very easy to build cliques when all of a sudden it was like the programming team was on a little side and then the management was on a little side and it was them against us. And I was in the middle because I was on a development team, and so I was getting it from both sides. And you can't seem to be like taking sides. So it's all about maintaining your integrity. And, you know, also taking responsibility because sometimes things go wrong. And when you've got so many different players, you can just turn around and blame the other person and say, OK, well, the user experience wasn't great or the development wasn't great or the design wasn't great, but you really have to say, OK, look, this hasn't gone well, and let's look at the data and how do we fix that? So, you know, that was really the key thing.

And there's a quote that is not showing up. But it's again from a football manager, so this is the analogies that I look at to look at a great manager, Brian Clough. So this is a player who loses your games, not tactics. There's so much crap talked about tactics where people who barely know how to win are dominant, so you can write about all the tactics in the world. You can write all the great processes with all the great buzzwords and all the nice diagrams and everything like that. But at the end of the day, if you don't have the right people that can bypass those processes sometimes and get what needs to be done, then you're going to go nowhere. So that's really the main conclusion is work out with those people how they work best and build the process around that rather than coming from, you know, some nice buzzwords and some nice frameworks and then trying to work backwards. So that's my main conclusion. Guys, thanks a lot.

Thank you, Abrar. Any questions from the crowd?

I have one. So you've been mentioning this collaboration within the team, with UX designers and also engineering. I'm curious. It's always the fact that the project managers know more details and they kind of like, have a wider overview, but also like they know the details. How do you make sure that this information goes from the product managers to, well, designers or to the rest of the team as well?

We use this analytics tool called Kebano, and that has a lot of the data that's going on in our product, the usage. So we have a Tinder style platform, as I mentioned. So you could see when someone swipes right with someone swiping left, how many users are using that. But then it's really all about our kind of weekly team meeting. So every time that there's any kind of update, we have those conversations. So we have a daily scrum with the developers and designers. So anything that's key, you know, there's only a few hours and because, you know, we work so close together, we're in a small office and you know, it's quite easy to share information, to be honest across us, because we're just working next to each other and we just literally like throw something at the other person and say, Hey, we've seen this. But yeah, I mean, we do have some kind of tools that we all monitor our data from and then we can if there's something that stands out, we can share that with other people as well.