Q&A With Jesper Stenberg
Checking session availability…
Hang tight while we load the latest updates.
Join the conversation! Share your insights and probe Jesper on the elements of his on-demand talk that left you wanting more.
Q&A With Jesper Stenberg
Jesper Stenberg at UXDX Community: Nordics. Video: https://youtu.be/V8MTvEUXcpk
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.
Balancing the sales side and the product side
[00:00:00] Host: Thanks, Jesper, for your talk about Mestro and, I guess, the balancing and communication process there. If anybody didn't have a chance to see it, I highly recommend checking that out. I'm just going to jump straight in. One of the points that you made, and I found this is just a challenge everywhere, is you kept on talking about balancing the needs between the sales side of the business and then the product side. That's always a challenge. Do you have any examples of ways that you were able to do that a little bit better as you were moving on? An example maybe of how it was a little bit skewed at the start and now how you're able to manage that balance better.
[00:00:45] Jesper: Of course, and first, thank you for having me as well here. It was an interesting journey for me as well, going back in time to really look into understanding what had changed during the years I've been in this company, and understanding why we do things better now. When you're working in the actual process you might be very focused on what to improve or to change, but looking back you really can see that we had some progress, actually a lot. And again, thank you for having me, and looking forward to the questions also from the audience.
[00:01:19] Going back to your question, I think that one important thing that shifted for us is, basically, we grew a bit more confident in what we do, and confident with understanding that our clients and users and different stakeholders are actually smart people that you can communicate this with. So I think the balance we found is actually trusting them with a lot of transparency, clients and other stakeholders, and actually just telling them how we do things and the value for them. Instead of having a specific feature made for them, they could have plenty of features released instead that would benefit them in the end.
[00:02:08] So I think we're very open about our process, even in the sales process: how we work as a company, that we're always releasing new things and want to develop for many, not a few. And in that way, being very transparent with that, and confident that we understand what we do, we actually gained a lot of trust even in the sales process, which I found interesting.
[00:02:33] Host: Excellent. That's really inspiring, to hear somebody do it. And I'm just going to throw in, because it usually happens, it's like, yes, I understand the process and everything, but this is a huge sale and we just need this to close it and I need you to do it, and thanks for all of that, but come on, can you help me out here? Do you have any of that still happening?
[00:02:51] Jesper: I mean, I would lie if we don't still do things that perhaps in the perfect world we would say no to, or rather not. But I think what we also found is a balance with that as well. If we pick up some need from a client, what we don't want to do is just let them do the specification of requirements, or actually create user stories, and just implement them. That's what happened before, when it was very sales driven. Basically the client themselves had formulated their needs and we just implemented exactly what they said.
[00:03:29] What we do now is a much more balanced process, even in that. We talk to them and try to figure out other ways. The most important thing for me there, as a product manager and working with the product team, is that the clients a lot of the time come to us and ask for a solution, but what I want to understand is what is the underlying problem that they try to solve, because there might be several different solutions that they didn't think about, and some of them we might already have. So, understanding the basic need, and then involving them in the process of creating the stories and developer tasks, and together trying to find the best way forward. It has been working for us.
[00:04:20] Paired also with not trying to develop this specific feature only for them. If we pick something up from one of our clients, there are smart people working with their product and they understand the business, so probably someone else will have the same need. That's what we also try to figure out: is this a large need for a large group of stakeholders? And then try to do something that we can implement in the product for everyone, instead of doing it for a specific client.
[00:04:56] So there's a lot of communication there, I think, and being transparent with how our process works and involving the clients. It's been very appreciated, and they're much more harmonic in that sort of dialogue than not understanding what we do and just wanting to have things done for them, basically.
Too many chefs?
[00:05:21] Host: Just continuing on that, you mentioned let's get the team involved, let's get the stakeholders involved, let's get the users involved. Do you have a too many chefs problem, where you're getting too many voices and too many opinions and it then gets very hard to distill it down?
[00:05:40] Jesper: Yeah, that's a kind of a luxury problem to have, actually. We have a lot of great ideas coming in from all different directions, and sorting them out of course is a problem. I know before we tried different prioritization techniques for them, but that's also quite demanding in overhead, in time.
[00:06:04] We went through a phase before, also, when we didn't really have a set product management department, but we had a product council which consisted of one person from every department. And what happened then, we definitely had the too many chefs problem, because we tried to make decisions everyone together, and of course sales wants to drive us forward and try new things, developers want to build from tech, UX design want to have the perfect experience from the UX perspective. In that kind of setting it didn't really work.
[00:06:43] I think for now, when we have a good balance in the product management, this is not a problem anymore, because we always collect all ideas and we are very open and transparent about why we take certain decisions. It hasn't always been like that, but as long as we are very transparent and talk to all stakeholders and let them understand that they're involved and we listen to their ideas, but we decided to go this direction because of whatever reason it might be, then we also have a greater acceptance of the decisions we take.
[00:07:20] So I think having the product department be that middle guy, understanding everyone's needs and trying to make everyone satisfied enough, basically not making anyone too sad or anyone too happy, because then it's unbalanced, that's the struggle of my everyday life basically. But I think just being open with why we take the decision is very helpful for us in getting acceptance of the decisions themselves.
When the pendulum swung too far to tech
[00:07:53] Host: And that was a point that you touched on in your talk, where you didn't get that balance right at one point and it went far too heavily on the tech side. Can you give an example of what you mean by that, where it was too focused on tech and not enough on the other kind of development?
[00:08:08] Jesper: That was like the pendulum shifted from the sales driven to the tech one, right? Thinking back at it, it was a quite interesting project, when I was quite new at Mestro. What we tried to do back at the time was to build a full support and full integration to another system that was a widely used sustainability reporting platform, basically.
[00:08:44] So what happened then is, this project became ridiculous at some time. I think it stretched over a couple of years, and in the end it never finished, because they wanted to make a complete solution to all the needs that everyone would have in using this platform together with our platform. And what was a bit funny in the end is that it turned out we only had like a couple of customers who actually wanted to use this system, and there were other systems that were more widely used.
[00:09:14] The problem was, no one ever asked a question to one of the clients who wanted to use this, like, how do you want to use it and what do you need? And no one talked basically to the company we were collaborating with and the product we wanted to integrate to, to understand their roadmap and what they wanted to do. Because in the end, when we were about to finish, I don't know, it was quite a big job left, but then the other system just changed their setup completely. So everything we did, because it took such a long time, wasn't useful anymore.
[00:09:57] Host: Yeah, so that's like you've been outside[?].
[00:10:01] Jesper: But we learn from it, so I think that's the important thing. Now we can laugh about it. Because I asked the tech team just before, when I was putting together these slides, okay, so what are you not proud of in your history? And this was one of them. Like, no, we forgot to actually ask someone what they needed.
[00:10:27] Host: Great. Well, thanks very much, Jesper. I really enjoyed your talk, and as I said, if you didn't get a chance to watch it, please do go have a look. We'll be chatting again in a few minutes, but thank you for now.
[00:10:37] Jesper: Thank you.
