Arne Kittler is full of wisdom when it comes to product. As former VP Product at Xing and now CPO at Facelift and Founder of Product at Heart, he knows what it’s like to have communication challenges in product teams and especially how to overcome them.
We are touching on many great topics and explored the importance of early alignment, setting clear expectations and more. I hope you enjoy this episode of the Product Comms Series as much as I did!
Key learnings
✅ Role Clarity is Crucial: Understanding and defining each team member's role prevents confusion and enhances collaboration and communication.
✅ Early Alignment is Key: Ensuring everyone is on the same page from the beginning avoids misunderstandings and misaligned efforts.
✅ Clarify Expectations: Avoid assumptions, as they lead to misunderstandings. Clear communication about expectations and outcomes is essential for successful collaboration.
✅ Documentation Matters: Structured documentation, like framework Arne applied at Xing, can significantly reduce misunderstandings and align team efforts.
✅ Foster an Environment for Questions: Encourage a workplace culture where it is safe and expected to ask clarifying questions to ensure everyone fully understands their tasks and objectives.
Arne (00:27)
I'm the CPO at Facelift. We are a SaaS company in the area of social media And I've been leading product times for quite a while already. So I've been with Facelift now for two years. I was at Xing for 10 years before in various product leadership roles and before that at a creative agency.
So I've always been kind of in context where it's all about cross -functional collaboration between people, where it's all about crafting digital things together that have an impact on the people that we build them for. And besides that, I'm also a big believer in the product community. I've long -time organized product tank in Hamburg, a meetup, and I run product at heart conference in Hamburg for curious product people together with my friend Petra Wille.
Jack (01:18)
Brilliant, yeah, so involved in many different topics and I'm sure you've got many experiences where communication maybe didn't go so tell us a little bit about one or two of those and what happened and what could have been done better.
Arne (01:37)
Yeah, I think, I mean, a lot of, a lot of when communication inside an organization doesn't work, I think a lot of that comes down to lack of clarity in various ways. And like one typical way, when you have a typical product team, I think role clarity is super important. If people don't know what to expect from each other, it's very likely that they will be disappointed or, you know, will not be able to collaborate, to communicate well with each other.
I think that's one important thing. Another thing that again and again comes up is this topic of early alignment. This is something that I've also written some blog posts about it and I've spoken at conferences and it's something that I really, really strongly believe in. And I mean, there's one very popular drawing from Henrik Knieberg in Sweden. Maybe some people have seen it. It's basically two teams like on two sides of a pond and they are asked to connect while crossing the pond. And in the end it turns out while one team digs a tunnel, the other team builds a bridge and in the middle they notice, oh shit, you know, we had different assumptions about what the others were going to do. And I think these things happen so easy because like a lot of people in collaboration inside companies, they kind of, you know, want to avoid conflict. They, they maybe want to avoid confronting their colleagues. And as a result, a lot of things are not really clarified well enough. And we think we've spoken about this. We think we have agreed on something.
And like a former boss of mine once said, like if, and I think that's not his quote, but taken from somewhere, if you assume you make an ass out of you and me, and yeah, it's a catchy phrase, but there's a lot of truth to it. So we have always, in my work, I always try to say, okay, like, are we really clear about this? Like also back at Xing, we had this framework called “Auftragsklärung”, which is like a whole canvas that we developed to clarify joint efforts together to make sure that everybody gets on the same page. And this comes also up to like even to stakeholder management. Like I remember one unfortunate situation that I had back at Xing like was 10 years ago or so, but they were like, we were happy we had released something new.
And then I was in a management meeting together with my colleagues and somebody was asking, okay, but how is it doing? Is it good or not? And then you could hear a lot of very different answers to that because we had not really defined for ourselves what good meant for us. Like, are we happy with the 2 % increase or do we want to double everything?
And there were very different opinions in the room like somebody says yeah, but I thought this would double everything and others were saying yeah, but I knew all the time it would just you know make a make a two point two percent increase So that's why I believe early clarification is super important. It is effort. It can also be a bit uncomfortable at times because you will may also notice that you have different expectations and what do you do?
You know, then you need to figure it out. But in the end, I think it really pays off. So that's my belief. If you want to have good internal collaboration, be it on a peer level, be it between PM and team, be it between PM and stakeholders, early clarification is superb.
Jack (05:08)
Yeah, that makes a lot of sense. I mean, I've seen so many cases of those projects where you get, you know, even 20 % through and it's like, wait, aren't we doing this thing or no, that's out of scope or, you know, everyone, even just the naming of a project, you know, either it gets a super technical name, no one understands what it is, or it gets a name that then people misinterpret and they think, oh, this is going to be, you know, the silver bullet or fix all of our issues.
Easier said than done, right? Getting everyone aligned. How do you do that? Are there some kind of straightforward steps that you would take? I mean, you mentioned this document or this process that you had at What's your kind of guideline there or how do you get your teams aligned
Arne (05:55)
Yeah, I think there are different ways. Like, I mean, the framework we use at Xing is of course one that also takes some effort to do so. I would not do that all the time. And also in my current role at FaceLift, I have not used that so often. It was Xing, which was a much, much bigger organization there. At some point, at least we had really established that as the go-to thing.
And then also if somebody, for instance, was to enter a new collaborative effort, they would probably say, hey, can I please see the “Auftragsklärung” for this?
So there it was really established, but it's also, you know, it's a bigger thing. To me, I think the main thing is that I also encourage my team to make sure that they are clear and also, you know, that they are also comfortable asking, say, hey, no, I don't quite get this. Like, do we mean this or do we mean that?
And...So I think that's, you know, one thing is kind of what environment do you create? Is it okay to ask these clarifying questions or is everybody expected to know everything? Because that's wrong. It cannot be like that. People have, you should give people the chance to clarify things and ask. So that's one thing. Then, I mean, a lot of things also come down to unsexy things like documentation.
So for instance, I have a really, really good PM now on my team who deals with all the API met like a whole business is based on APIs from the social networks. And he noticed that there are a lot of misunderstandings around this and what can be done with the API of Facebook versus the API of LinkedIn. And what he did is just write everything down in a very structured way, provided, share that information again and again and again with the company, point them to where they can find this information and.
There may still be people who misunderstand it. I think you can never be a hundred percent sure, but that, you know, it's not a very sexy thing to do, like to do documentation, but it was worth it. Like the effort of his was much appreciated and it really helped to raise the bar of how we talk about such things. So I don't think there's a silver bullet. It's more kind of a mindset thing.
And I believe that as a, well, somebody in leadership, you have an important part in that because you create a...you know, you set up the mood and the environment and whether it's okay to clarify such things or not.
Jack (08:19)
100%. I think what's interesting though, as a way as if you ask people whether they know what's going on, everyone says like, oh, you know, it's clear to them. It's, it's clear. And it's like, yeah, often it's not, or they, they believe it's clear. Everyone thinks that they've understood it concretely, but they have five different understandings. I was going to ask actually, and I think you kind of premeditated this a little bit with the documentation. What's interesting sometimes is do you default to trying to align everyone?
Arne (08:27)
Yeah, and it's often it's not.
Jack (08:48)
Sort of, I mean, in the old days, it would have been in person, right? You call a big meeting, we're kicking off a project, you get 10, 20, sometimes 30 people in a room together, and this is your sort of alignment, or do you default more to, uh, to a documentation process for that? Do you have a kind of a, a framework that you like to use? Some people, some product engineering teams, you know, say, oh, we have an RFC that we start every engineering project by, you know, someone has to write this down and then we get alignment on that.
Have you found any, have you got any best practices there or things that you like doing there?
Arne (09:23)
Now to be honest, this is something that I'm still playing with and that we are, I mean, it's not just me, it's also my team and it's also the rest of the organization. So it's not, I mean, I know that some organizations have really structured ways of doing this, like a friend of mine, for instance, works at Zalando and I know that they have a really structured way of how they do this.
We are improvising a bit more. I'd like to say there are different ways. I think I do rely on personal conversations having team meetings and also having one -on -ones also to check back with my team. And I think that creates an aligned reality. But we don't have one particular way of where we put everything and that's our silver bullet or so.
I mean, for instance, when it comes to the process of collecting consumer insights and discussing about them, we do have a structured process of how we do that with product board and everything goes in there. And the way we then present the initiatives based on that is somewhat structured.
So there are certain ways where we have established ways of working that also help others when, you know, like if one PM follows the structure and another PM looks at it, then they will more easily understand, okay, what is this all about? But we are not a massively big company. So we do speak to each other quite a lot. I mean, my team are currently 6 PMs.
So that also works without too much heavy frameworks. But I'm always fascinating when I hear how other organizations do that.
Jack (11:03)
Yeah, yeah, I think it.
Arne (11:10)
So constantly exploring.
Jack (11:12)
Yeah. I mean, you mentioned Zalando in there and I think, you know, Zalando is even much bigger than N26 where I was for three years, but you saw this need at some point for this function just for alignment, right? To keep everyone together on the same page. And that's a very different kind of organization that I'm sort of used to working with. And that was a big shock. I understood it as how essential it was though, right? Is that keeping everyone on the same page and all those alignment meetings.
I think something that we've seen, just kicking off a couple of new projects in the last few weeks, which I thought was interesting is sometimes you just have to get the people in a room together rather than, you know, that can also be virtual. But speaking to people at the same time. And what I mean by that is if you always go and have individual conversations, sometimes it doesn't move the thing far enough, fast enough.
Insofar as that you're like, okay, I've got this person's input. Now I've got this person's input. And then you can go back to all of them again. And you kind of start this, this merry-go-round. And I think just a learning from my side is like, even if it's really undefined at the start, that's okay. But you get everyone in and you get them understanding, this is what we're trying to achieve. Do you have ideas? You know, do you, how do you think that goal should be? How do you think that KPI should be measured, et cetera, et cetera.
But actually you can.
You can feel like, oh, I need to go in a line with each person before we do this, but actually getting them all in the room together, even if it's so undefined at the start can help a lot.
Arne (12:44)
Yeah, yeah, no, that's true. And I mean, I observed something similar, like our CEO recently also restructured the way how we have discussions and management because we somehow, for whatever reason, like we had gone into a lot of one -on -ones with him and everybody was having the one -on -one and at some point he said, no, let's bring everybody together in the room.
And I can tell that it really also helped to strengthen the shared understanding between, for instance, me and my CTO colleague on one hand and then the commercial leaders of the so I can fully second what you just said.
Jack (13:19)
It's funny, it reminds me of a post I saw on LinkedIn yesterday though, where someone said, you know, work is people setting up lots of meetings and then complaining that there are too many meetings going to fully async and then there's no one's aligned and then you schedule more meetings. And it's like, it's this funny kind of dichotomy between the two or relationship between the two. But that definitely sounds like an interesting and kind of more functional way of aligning at the C-level.
.webp)
.webp)
