Incredibly grateful to have Lukas Klinser, VP of Product at Hive, on the Product Comms Series today! We have an interesting discussion about all the things we DO want to achieve when building product, but that it is also extremely important to clarify the things that we DO NOT want to focus on.
And we are covering much more. Here are the key learnings from our discussion, enjoy ↓
✅ Set Clear Expectations: Early on, establish clear goals, non-goals, and boundaries across disciplines to align team efforts and build trust.
✅ Embrace Reusability: Avoid reinventing the wheel by building on what has worked in the past, saving time and resources.
✅ Communicate Non-Goals Explicitly: Clearly articulate what is not being targeted to maintain focus and prevent scope creep.
✅ Tailor Communication to Your Audience: Adjust the level of detail and content of your communication based on the audience's needs and interests to ensure clarity and prevent surprises.
✅ Preemptive Stakeholder Management: Engage stakeholders individually before group meetings to address concerns and streamline decision-making processes.
Lukas (00:13)
Yeah, absolutely. Lucas, VP Product at Hive, joined in August 2020 as we were just getting started with our very first customer, actually. And yeah, I've basically built up product and design around here ever since and very proud of what we've achieved so far.
Jack (00:35)
Nice. Cool. Let's jump straight into it. I mean, you and I both have experience obviously working with, with designers. We've been PMs for a few years now and, and obviously PM to design is a very crucial kind of interaction, right? Uh, you know, most teams have a designer in, there's a lot of UX and UI work going on, but tell me about an experience that you've had where the communication didn't work so well between product and design.
Lukas (01:04)
Good question. I think one of the more recent examples was probably... Effectively, the promise statement was the following. We have a couple of different software add-ons that we are offering to e-commerce brands. We historically have not had that productized in a sense of if you were using the main platform, you couldn't just say, hey, I want this. But rather, it's just like a personal conversation. Hey, do you want to use this? And we would set it up on our side. And we've recently brought the first flow of that into the product. And we were looking at, hey, can we get other flows like this into the product as well?
And as often the case, right, the first time you do something, you don't always have every edge case thought out. You don't have every user need anticipated. And you might just want to iterate on it. So effectively, when we then approached the second one, or at least what I observed was it almost went like a green field type of thing again rather than trying to reuse what had worked.
And that led to a bit of frustration on both sides, where on the one hand, from a design point of view, you always try to push what's best for the user and to really, in a way, flex the product instincts and guide the user the most effective way. And from a product point of view, you're often like, hey, man, I really need to get this piece of functionality out, be it to move a metric, be it to just get going on the next thing you want to get going.
And so that was a little bit of a disconnect there, I guess.
Jack (03:03)
Mm-hmm. And what kind of what was the impact of that disconnect? What happened then?
Lukas (03:11)
Long story short, we got started on it later than we had wanted to get started on it. I guess a bit of wasted work, if you will, or rather work that's going to be tackled in a V2. Just a bit of miscommunication in general. At first, the thinking was, hey, we can reuse what we have. Then it looked like, hey, actually we'll have to build a couple of new things.
And then, as you can see, it very quickly extends to outside of product and design as well, namely engineering being involved and thinking, oh, those are new components, or hey, that's a pattern I haven't used in a while, or hey, I might be doing something totally new here. And actually, it's not going to take me a sprint. It's going to take me two.
Jack (03:57)
Mm-hmm. Makes sense. And if you wind back to the beginning of that, what would you have done differently?
Lukas (04:05)
I mean, from my end, probably the expectation setting bit, I guess that's one thing that all teams will probably benefit from. If in the very beginning, you get in a room together, you get on a huddle together or whatever the cool people are using these days, and you just hash it out. You put down goals, non-goals, you put down very clear do's and don'ts as a group. I think it's especially important to do that cross discipline. S
o you also build up the trust with each other. Because no one PM is going to understand what every designer does. No one designer is going to understand all the product context. And no one engineer is going to understand the other disciplines to 100% either. So the more you put out there, the better, at least is what I've observed in the past. And I mean, the two of us also did this at a past job that when you start a new flow, you do sort of an inception style, one, two, three day kickoff, call it design sprint, call it whatever, right? I think just putting those expectations and those goals and non-goals out there, it's just tremendously beneficial later on because you always have something you can refer back to.
Jack (05:23)
Yeah, it's amazing, I think, how often product doesn't give the full context of what's in our minds to other people. And you start building and you're like, there's a ticket there. Why don't you understand the entire scope of something? But it's often so much, much broader and that why doesn't come across in a few acceptance criteria bullet points.
But I actually think that the way we did it in 26 with the inception workshops, often it felt like you know, or do we really want to take three days out to plan something? But actually that three days often cut a lot of time later on in the process around confusion or duplicate work, or, you know, actually, uh, refining things down and not needing to do some bits at all. So I think it was actually that kind of measure twice, cut once, uh, mindset that actually helped us move much faster.
But there's something that you mentioned there that I'd love to zoom in on you mentioned kind of non goals Tell me a bit about that and how you think about those
Lukas (06:39)
Yeah, good question. I think that's a thing just very often not verbalized at all, right? But I think everyone kind of has some idea in their mind of what the thing should be. Now let the thing be a feature, an improvement, a new integration, whatever.
And of course, like it becomes clearer or more explicit when as a PM, for example, you write down the scope or as an engineer, you write down what's possible. But I think what's very often left unattended is saying what you don't want to achieve. I think that's especially relevant when, say, you build the first version of something or you work on improving an existing flow that you just haven't.
And like, of course, I think when you're pushing to build the best product possible, like you'll always want to touch everything, right? Like you'll want to make sure every interaction works. You'll want to make sure everything uses the latest component, whatever it may be. But sometimes it's also important to just say, hey, we've noticed, say it's a three-step flow that we're reworking, and we notice that users get confused by number one and number two.
So yes, step three might not be awesome, but we've gotten literally zero issues reported by users. And so we explicitly write down, hey, we're not touching this. If we have ideas, cool, let's discuss them. Let's maybe user test them. But for now, what we want to solve is like 0.1 and 0.2.
Jack (08:27)
Yeah, that's a great way of thinking about it because I think usually there's every design can be improved upon and every flow and every experience always has, you know, learnings and a way of doing it more perfectly. But it's so tempting to try and revisit all of those every single time that you that you iterate on something. So it's really important to have that focus there as well. Moving away now just from the design to product side. Obviously, you're a VP of engine of products even, not VP of engineering.
Tell me a bit about, you know, you're in a, like both a stakeholder to PMs, but also you have stakeholders in terms of the C level at the organization or, you know, VPs of engineering or VPs of growth. Tell me, do you have a, like a story about how your communication hasn't worked so well with stakeholders in the past?
Lukas (09:26)
I mean, yes, I think everyone does and everyone who doesn't admit it is lying. Just to put that out there. Yeah, many. Let me think of one. I mean, maybe one more recent one is so we basically wrapped up our H1 roadmap planning like per team, right? Tribe, squad, call it what you will. And one of those is working very closely with one part of the business, don't want to put anyone's names or roles out there. But effectively, it was very interesting. So we've grown quite a bit.
So when communicating these plans more broadly, I don't go into every single detail anymore because that would just be very boring. Instead, I would be standing there for 30 minutes explaining each and every detail of what the warehouse management software team is doing. It's not super interesting. So in a company-wide setting, I wouldn't go super detailed. But one key thing that I left out was, funny enough, this kind of ties back to the non-goals. And one of the things I left out was something we deprioritized but had discussed with the team in the past.
And since that wasn't clear, people then as a follow on in the team were actually surprised or flagging, hey, team X was really surprised that we're not working on this feature anymore. And I think we should have provided more rationale. And then I was like, yeah, actually very, very fair feedback. And let me take that up with the, with the respective leader and then sort of work towards, towards resolving that. And so I guess the, the learning day, if you will, was tailoring the message to the audience is Good is very much needed and not everyone needs every piece of information, right? but when there's important, I guess changes or pieces of information that like might Almost like not shock but like surprise someone in a in a larger round
And it's probably good to sort of like prepone those conversations and just sit down one to one or like in the smaller round where it's important and discuss it or hash it out. So to say.
Jack (11:54)
Yeah, that reminds me of I think one product colleague we had at N26. I remember her saying that before those very intimidating products, what were they called? Product summits or whatever, where you'd have like, I don't know, what was it? Product alignment committees. So I remember that PM from N26, I was saying before those product alignment committees where you'd have like the head of the bank, the CEO, the CFO, etc. CMO and she said that she would go and tell each person before the meeting, what was going to happen, you know, and deal with any questions that they had.
So that when she was actually presenting in the meeting, there wasn't someone going, uh, Oh my God, I can't believe you're doing this thing or that thing.
Because everyone had kind of been pre, uh, pre warned and she had really dealt with, you know, any concerns they had. So there wasn't, things weren't firing up in there. And it was, I think a really interesting example of like stakeholder management done well to really make sure everyone felt heard before the meeting and could air those things so it didn't all explode in the meeting itself.
Lukas (13:01)
Absolutely. Couldn't have said it better. I... yeah. Wait, that just inspired a different thought? Did I forgot again? Nevermind.
Jack (13:13)
One other, I think, interesting learning I had at N26 was, I mean, you mentioned it around tailoring the communication to the audience. And one piece of advice I got was to think about what that person needs to know. So when you're giving a product update to a CEO, for example, what does the CEO need?
The CEO, he or she is usually going to be, you know, communicating with that with their investors usually, maybe their fundraising at that point, maybe there's a compliance angle that they need to understand. So they don't usually need like the minutia of, of the product, but they do need to understand launch timelines, impact on KPIs material like this. So tailoring your communication, not, not what would you want to know, but what do they need to know?
And then working back from there actually helps make, you know, your life so much easier because if you put yourself in their shoes, more often than not, you're going to basically get to kind of 80% correct communication at the cadence that they need it at because you've just put yourself in the shoes of them. It's, I think the same as putting yourself in the shoes of building for a user. You need to think about what they need. And it's the same with communication.
Lukas (14:26)
Absolutely, absolutely. It's like what they need and also what they care about, right? Because sometimes while what they need actually gets the job done, if someone feels like you're holding something back that they really care about, maybe there is someone that really just wants to dive super deep into the flow, be it because they're a hands-on founder, be it because they're an early employee and they just care about the details. I think you capture it quite well with like tailoring it to what someone needs, like really needs to get their job done and also what they want. So kind of like the product way of like, who's my user, right? And like, what are the jobs that they might want to get done?
Jack (15:09)
Yeah, it's so interesting how you can kind of take product thinking and apply it to different circumstances It's the same thinking just applied to communication rather than building this product for users essentially Lucas thanks so much for your time today super nice to chat. It's been really cool to have you on.
.webp)
.webp)
