Cross Department Collaboration For Product Managers In A Scale Up

Abrar Akhtar at UXDX Community: Amsterdam. Video: https://youtu.be/2UIGSx7tx1I

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Tinder for investors, and how fundsUP came about

[00:00:10] Hi guys, my name is Abrar, as has been kindly introduced. This tech problem at the beginning is nothing. It's more scary when you're demoing to a potential client and your app crashes; then you're really screwed. I'm here to talk about cross-department collaboration in startups. Let me tell you a bit about the startup, since it was mentioned briefly.

[00:00:35] What we do is we match... we're basically the Tinder for investors, is the quick way of putting it. We match startups with investors on a matchmaking platform where investors, if they're interested in the company, swipe right, and if they're not interested in the company, swipe left. We work with VCs and angels, and we've got our first case in the Netherlands. How this all came about for me is that my background is in London, and I met a Dutch founder who had an events company that used to match startups with investors physically. They did that for about eight years, so he had a very good network of VCs and angels.

[00:01:14] He said, "OK, I want to take this online. I can't be doing these events." The guy was traveling around the world doing this and organizing the events all the time, and he said, "OK, I'm done with that now." That was the idea: let's move it on to the app. I moved over in August 2017, and we launched the app on the App Store in April 2018. I think it was just two weeks ago that we had our really big success story: a founder had raised their 500k euros from our platform, from an informal investor. That was a really good proof of concept for us at this point.

[00:01:59] Among other partners, we have some enterprise partners, people like the city of Rotterdam and other accelerators around Amsterdam. We're really growing in the ecosystem here, and then going to move over to other places.

The team, the platforms and the dependencies

[00:02:12] What is our team? As head of product, we're very lean. When I came in there were three of us, and 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 two outsourced developers. We now have a whole team: two designers, three front-end developers, two back-end developers, an iOS developer, an Android developer, a product owner, which is basically me, and one data scientist.

[00:02:44] Some of the team is outsourced in China and some of the team is in-house, so we're dealing with different time zones and with different types of communication, and it's quite a large team. We also have four different platforms. We've got a WordPress platform, which just tells you about the business. Then we have an iOS app for the investors, an Android app for the investors, and a web platform for the founders.

[00:03:05] The founders have to go online and create their profile about their business: what the traction is so far, how much they've done. They can't really do that on the app. But for investors it's about seeing deal flow on the go. A lot of them that we speak to spend time going to events, traveling and doing this and that. For us it's about deal flow in your pocket, in a casual way.

[00:03:29] When we have a team like this, we can 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 read a lot of things: data-driven product management, customer value. To me it just sounds like buzzwords that make a good diagram in a presentation. We want to break it down: what exactly do we need from each other?

[00:03:53] We have someone who writes the copy for everything that comes onto the platform, someone who does the wireframes, someone who does the design, myself with the management and what's on the product roadmap, and someone who's going to find the bugs. You've got front-end developers, you've got back-end developers, and every single one of these things is dependent on each other. If we don't get the copy, we can't launch the product. If we don't get the design, developers can't start. If the back-end guys haven't got the endpoints, then the front-end guys can't develop.

[00:04:24] We're starting from this, we've got ten people, and we need to make it all flow. That's basically the challenge that I have, and that's what we're trying to fix. 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 ten people sitting there. We need to get them to flow, we need to manage them, and how do we do that?

Quarterly priorities, sprints and keeping sales in the loop

[00:04:50] The first thing was that we needed to really establish what our priorities were as a company. We split that up into the teams: you've got the sales team and you've got the product and development team. Every quarter I sit down with sales and the CEO, the management, and say, "What would you guys want to sell in the next few months to your customers that we don't have right now?" We break that down into the next quarter and say, "OK, this is what we want in the next three or four months."

[00:05:23] Then we break them down again into releases: two-week releases, two-week sprint plans. That's where we have everyone who's involved. We need copy from someone in that sprint, we need design from someone in that sprint, and then we need the development as well. We have the 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?"

[00:05:50] Then I also have the same conversation with the management, because with such a small team everyone needs to be in the loop. If we say to sales, for example, "For this client we're going to have this feature ready in two weeks' time, and then you can go and sell to them," they want to know a week before whether this is on track. They don't want to hear, "We said we would deliver on this day, and now we have a delay." They want to know as soon as there's a delay what's going on.

[00:06:14] This is the way that we reduce the friction, so everyone's in the loop. Otherwise sales say, "OK, what are you guys doing? I don't know what you guys are doing. You said this is going to be on this day, and now you're coming to us and saying it's going to be late." This is how we keep everyone in the loop, so everyone knows what's going on. It's a lot of meetings, but really it's not. It's a daily standup and a weekly review with both sides, so it's not really a lot, an hour on each side. To keep everyone in sync and to keep everyone happy, it's really worth it, even though I hate meetings.

[00:06:49] We also have Slack updates as soon as someone has added design to Zeplin, and everyone else can go in and review, et cetera. It works like that as well. This is a nice framework, similar to what Rory did. You start from the design sprint in the first stage. You've got to say what's in the product backlog, then you start with getting some wireframes going.

[00:07:18] Once you have the wireframes, you can give them to the person who's writing the copy, because the person writing the copy needs to know what the design looks like. Otherwise they don't know how much copy they have to write and how the designer has it in their mind. That's where we go through the whole process: you create the sprint, then you have a sprint review, you go through that process.

People over process

[00:07:39] This is nice in theory, but when it actually comes down to it, a lot of it falls apart. For me it's all about people over process. If you have people that have multiple skills, I like to let them take initiative on certain things. If a front-end developer whose skills we trust comes and says, "OK, this is the framework that I want to use, with my experience in front-end," we say, "OK, you go ahead." We'll give you the autonomy to do that.

[00:08:13] It's all about people. If we go back here, 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 who turns around and says, "Look, for this particular feature I can just take the initiative and go ahead without design," we can leave the designer to work on some other things. It's just a matter of adding an icon there. Let's not wait until the designer makes an update, then we come and approve it, then we get the copy, and then it goes to export, et cetera.

[00:08:44] If you've got a front-end developer, just get them to make the change, and then we can see it on a staging environment and comment on that directly. 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 not that the process is king. You don't want to go around and get the guy to draw the icon just to go through the process, just so the designer feels better that the design has gone through him.

[00:09:12] For people to do that, you need to let go of egos as well. It also happens from my side. I'm talking to the business about 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 makes the last decision having the final say.

[00:09:38] It really comes down to dropping egos. It's all about the best ideas winning, and not the people with the titles. Especially when you're in a small team, titles like head of product and CTO and head of UX mean nothing, because there's only ten of us. You can make yourself feel better about it, but at the end of the day, whoever comes out with the best idea, even if they're someone more junior, everyone needs to be ready to take that on board.

[00:10:05] I like to think about it, and I'm going to mention this later, as similar to sports. I'm a big football fan, and at the end of the day, when you have the best players on a team, they're going to win the game no matter who the manager is. You see that with a lot of statistics: the teams that spend the most money and have the best people are going to win the game most times. It really is about picking the best people.

Design two sprints ahead, and trust across the process

[00:10:33] Another point, because everyone is reliant on everyone: in terms of design, we always like to say, let's keep the design two sprints ahead of what the developers need. So many times you'll be in a situation where the design is late for some reason, it needs some more feedback, and the developers are sitting there with nothing to do. That's resources going, that's time going, and 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 synergy going.

[00:11:06] Again, it's really down to egos and people. If someone really wants to have control over that process, say me for example, if I really just wanted to have the final say on everything, I could. But then people would think I'm an idiot, and people won't want to work with me after that. If someone has a good idea, wherever it comes from, you just have to be open to it and go for it, because then people will trust you.

[00:11:33] It's all about trust. I need to trust that the CTO will make the right call on a tech stack, or any other third-party service that we want to integrate, when he says to the developers, "OK, you guys have a look at this," and you trust that decision. Then the developers also need to trust that we're making the right decisions on what to build and what features are next for our users. We also need to trust that the designers are going to produce something that is of value and that's going to be intuitive. It's all about trust across the whole process.

[00:12:10] When it comes to the best ideas winning, the point is that if you can't convince the rest of your team of your concept, the chances are that you won't be able to convince the users either. If you've got a concept or 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. That's the first point of really validating your idea: getting it through the team.

[00:12:37] As long as they're open. When you have something like this, you always have to watch out for people who... everyone's got an opinion on everything. I can have an opinion on whether that icon should be moved there for design, 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. But at the end of the day, these people are hired with that expertise, and you need to give it to them.

[00:13:02] When we're having a discussion across the whole team, there's always one person who's got an answer for everything, a good suggestion for everything, and you need to watch out for that. Everyone can have an opinion on everything, but what is your opinion based on? How much experience do you have, and where does that opinion come from? Especially with these new titles: 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.

[00:13:29] These things are new, and the roles are overlapping as well. As soon as you start getting hung up over your titles and who's doing what, it just gets really messy. It's just about what the output is and how you can all work together to do that.

Say what you need, not how to do it

[00:13:52] This is just another sign of how to communicate to someone what you want. I really like this example that I read. I could say to the designer, "The user needs to be able to download a file." That's my requirement from product, and now it's up to the designer to say where that download button goes on the platform, where it's most intuitive. But if I say to the designer, "Can you add this download button, and can you put it to the right of here?", he's not really doing a job. He's just doing what I'm telling him to do. There's no creative input from him or her.

[00:14:32] It's the same way as if I go to the management and say, "What are we going to build?" and they say, "We're going to build this and this and this." Then I just become basically an admin person who's managing this delivery without any real say-so. You've got to know what people do, and you've got to give them the chance to do that.

[00:14:48] Here you have the roles overlapping. A lot of my conflict comes with the business side, with the management. I work really well with the dev team and with UX; we really get along well here. There's a lot of user research and wireframes. I speak with a lot of our investors, I go and meet them, and I also go along with the head of UX to have these conversations, so we're understanding what is needed.

The football analogy: talent, process and their limits

[00:15:17] I mentioned sports, and I think this is really what stays in my mind. It's people over process. You can have a great process: I can go today 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 on the other side, someone with talent will also fall apart without the process.

[00:15:42] An analogy that I like, from the example that I gave: if someone wants to take the initiative, someone has the idea, you let them do it. For example, a manager can have tactics, certain ways the team should play. But if a player just takes the ball, dribbles past three people and scores from 30 yards into the top corner, the manager isn't going to say, "You didn't follow the process that I gave you. You were supposed to do this, you were supposed to do that." He's going to say, "OK, well done."

[00:16:15] But if that same player always tries to do that, then the rest of the team are going to turn around and say, "OK, look, you did it once, it worked well, now let's follow the process." There's a limit and a boundary to everything. You need to let people have the freedom to go in and express their ideas, and have no bad ideas. If, for example, a designer or one of the developers comes up with a feature, that's great. You have to consider it and push it through.

[00:16:45] Rather than saying, "OK, you're the developer, we're going to do the backlog, we're going to do the pipeline planning later, we'll let you know." Sometimes you'll have that attitude: someone will say, "Hey, how about this feature?" and you'll say, "We'll discuss it on Wednesday," and just kick it into the long grass. But if someone wants to take that initiative, you've got to let the best ideas win, and they always come from the most unexpected places.

Integrity, responsibility and the conclusion

[00:17:04] The main thing for me is that you have to maintain integrity when you're doing it. It's very easy to build cliques. All of a sudden the programming team was on a little side, and the management was on a little side, and it was them against us, et cetera. I was in the middle, because I wasn't on the development team, so I was getting it from both sides. You can't be seen to be taking sides, so it's all about maintaining your integrity.

[00:17:36] Also taking responsibility, because sometimes things go wrong. When you've got so many different players, you can just turn around and blame the other person and say, "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. Let's look at where we are and how we fix that." That's really the key thing.

[00:17:58] There's a quote that's not showing up, but it's again from a football manager. These are the analogies that I like: a great manager, Brian Clough. "Players lose you games, not tactics. There's so much crap talked about tactics by people who barely know how to win at dominoes." You can write 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.

[00:18:27] But at the end of the day, if you don't have the right people who can bypass those processes sometimes and get done what needs to be done, then you're going to go nowhere. That's really the main conclusion: it's people. Work out with those people how they work best, and build the process around that, rather than starting from some nice buzzwords and some nice frameworks and then trying to work backwards. That's the main conclusion, guys. Thank you.

Q&A

[00:18:52] Host: Any questions from the crowd? No? I have one. You've been talking about collaboration within the team, with UX, designers and also engineering. I'm curious: it's always the case that the product managers know more details and have a wider overview, and they know the details. How do you make sure that this information goes from the product managers to the designers, or to the rest of the team as well?

[00:19:30] Abrar: We use this analytics tool called Cubano [?], and that has a lot of the data that's going on in our product, the usage. We have a Tinder-style platform, as I mentioned, so you can see when someone's swiping right, when someone's swiping left, and how many users are using that. But then it's really all about our weekly team meeting. Every time there's any update, we have those conversations. We have our daily scrum with the developers and a designer, so anything that's key gets shared.

[00:20:02] There's only a few hours, and because we work so close together, we're in a small office, it's quite easy to share information across us, because we're just working next to each other. We literally just throw something at the other person and say, "Hey, receive this." But yes, we do have tools that we all monitor our data from, and if there's something that stands out, we can share that stat with other people as well.