Open Table With Jesper and Monika

Jesper Stenberg, Monika Ocieczek at UXDX Community: Nordics. Video: https://youtu.be/ZY9M725f0S0

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.

Where design sits in the organization

[00:00:00] Host: Welcome back, Jesper.

[00:00:02] Jesper: Thank you. And thank you, Monika, I found it very interesting how you have put design and UX at the center of your organization and how you work with these questions. Sorry for cutting in, Rory, but I just wanted to ask something about that, because it's something that I've been thinking a lot about as well. We don't have a team of 11 UX designers, we are only one at the moment. We're just starting out our journey with the visual design in that regard. We always had one, but we decided to have UX design as a part of the product team, just to involve them very early and work closely with end users and where the actual product research is being made. But I was wondering a little bit about how you have organized the UX and design in your development process, and to make sure you get it at this early stage. I was a bit curious about that.

[00:01:02] Monika: Yeah, so I think, again, it just comes quite naturally to us, and it's probably driven by how we were structured from the very beginning. So we never had to make an effort to put designers in any special position. The other thing I would mention is that all designers kind of belong to the product design team, but they're also design leaders in their respective product teams. So they're constantly working, they're actually spending way more time with their product teams than they're spending with the design team. They're just part of all the conversations. Every standup, they talk about, they make decisions, they share insights, customer feedback. So designers are just always there, part of the product team, so they never have to fight for a seat at the table. They're just an integral part.

[00:02:04] Monika: And thirdly, I would mention that one of the things that we value, that we've pointed out as a success metric for our team, is how much designers contribute to innovation in their product teams. So we're very, very clear on designers and PMs and everyone else that they work with, that designers have a role and they have a say in these things, and they're even expected to drive innovation, come with ideas, and work very closely with the PMs and the engineers and everyone else on the team.

Measuring how designers contribute to innovation

[00:02:40] Host: How do you measure the impact? If you're saying that they're being challenged to drive innovation, how do you measure that?

[00:02:48] Monika: Oh, it's very simple. I send out a survey to all the PMs every month and I just ask them, last month, how much do you feel like your designer has contributed to... not just how many ideas they had, but you can contribute to innovation with your attitude, with asking questions, with just being a part of that innovation spirit. And sometimes it's harder to answer that question, and sometimes it's just like, well, it's not an exact science. But I think you can answer that question from a scale one to five, and make sure that designers know that they're being evaluated this way, so that will push them. We track these metrics and I share them with the whole team every month.

[00:03:44] Jesper: Excellent. Yeah, I mean, I found this very interesting. Just before, there was like a shift from traditional project management, product management with lists of requirements and sending it to the dev team, do this. And the shift now has been more to scrum, more agile, with a product owner doing the user stories. But this might be the next step of the evolution of product management and how you product develop in very visual products where you have a user flow. Maybe a designer, a UX designer, should drive that instead. I haven't heard of it being in the center so much, so I really, yeah, it's intrigued me a lot.

Letting designers start with something visual

[00:04:34] Monika: Let's say an idea. I think even more so, I think it can be in the forefront in many ways. I think that designers traditionally have been taught that they need to go through this very rigid design thinking process, where they have to do all the research and they have to do these user maps and user personas and whatnot before they can even start playing around with something visual. Designers actually have this very unique skill to actually create visual stuff, and they're just not making use of that. So I want to kind of flip things around. I love saying, we have an idea, let's just create a very quick and dirty mock and see how it feels. And now suddenly it's so much easier to feedback, it's so much easier to test, it's so much easier to show it to someone and say, does this make sense? What would you do with this next? And it's also that way easier to drive innovation in a team, where you can say, hey, I have an idea and I can show it to you. That's the skill designers have, so I always encourage people to make use of that.

[00:05:43] Host: Yeah, the triad that a lot of people talk about, design, engineering, PM, where they're all working together right at that start, just throwing out ideas. And the speed at which you can move then and come up with valuable, usable ideas is great.

[00:06:00] Jesper: I mean, of course it's much easier. We try to also involve users early, to have something to click on instead of describing it in text. You can't relate to that. If you can have something clickable, you can get some very different feedback, of course.

Universal checkout: modules and styling

[00:06:16] Host: Yeah, so I think that's a good approach. I have one question actually that came up, and I'll direct it to both of you, but I'll start with Monika. In your talk you were talking about the universal checkout, and I love the way that you said, instead of doing all these features, you flipped it to modules that then the end user could turn them on and off. From a design perspective, how did you manage that? Because you're then giving so much control to the user, that maybe they've turned off three things and turned on another one, and now you've got a skewed design because it doesn't quite fit anymore. So how did you manage that, where you're giving that level of flexibility to the end user?

[00:07:02] Monika: So if you're using universal checkout as it is, coming out of the box, we still control the layout. So we give you, you think of it as Lego pieces, they're still designed by Lego. They fit nicely together because we've made sure that the pieces will fit nicely together, and you can toggle on all of them and they will still make sense, because they're positioned such that they do make sense. Well, developers and merchants still have control over the styling, but this way they can just very easily in the UI choose which features they want to toggle on and off. And of course if they're using headless universal checkout, then they're free to do whatever they want.

[00:07:47] Host: And you mentioned, there's one bit that was the toggling on and off, and then there was the styling, that people, because they wanted it in their colors or those kind of things. How much control did you really give people there? Because again it could fall into that kind of, things just don't look right. Or is that just their responsibility, because when you gave it to them it looked nice and then they were the ones who went and changed it?

[00:08:12] Monika: Yeah, so the thing with Primer is that we don't want to push our brand. When you're using Primer's universal checkout there is no Primer sticker or logo on it. It comes with a very simple, neutral design that I think still looks decent, but it's very, very simple. It's not meant to be designed in any way. It will fit nicely into a white website, and it's fine if you don't touch the styling. But we actually encourage merchants, most merchants will want to style it, because you want it to fit nicely with your website font and your colors and your borders and styles. So yeah, they should have full control. There's no reason why you should have a Primer branded checkout at all.

Small iterations without ending up with a Frankenstein

[00:09:04] Host: Okay, excellent. It is a good approach to it. And I'm going to flip, it's a similar but slightly different question now to Jesper. You mentioned how one of your big learnings was that you just have to keep getting smaller and smaller and smaller iterations and more rapid delivery. I've seen a lot of places run into an issue, that actually Monika talked about a very elegant way of coming around it, but that if you're constantly just looking at these small pieces, who's making sure that the big picture all fits together and you don't end up with a Frankenstein style product in the end, because you're just plugging all of these extra small pieces together?

[00:09:48] Jesper: Sure. I think that approach is usually in different abstraction levels, also in the design or product development. I think it's mostly when we construct stories and want to develop specific features that we know we want, and to not make this mistake that we did with a big project that took two years and didn't lead anywhere, we rather want to break it down to small pieces. Let's say we do two out of ten things, we still can deliver something with value. And I think it's me as head of product, I will be responsible for the overall roadmap, to understand okay, how do these features fit together and are we moving in the right direction? So it's more up to our designers and product owners who are delivering the special feature to understand, how do we fit the pieces together?

Modularization instead of customization

[00:10:43] Jesper: And one interesting thing I thought about now that Monika also mentioned, talking about the modularization, that's basically what saved us from our previous errors. Instead of trying to build something that fits everyone, or a very specific solution for a certain client, instead we're building pieces that they also can put together to make the system that they want. Because we have a very wide range of stakeholders, also within the companies we work for. Everyone has properties, right, and buildings. Investment companies, housing companies. So we have a lot of different industries we're working in, and in these companies we also have the technicians that want the data, because they need to understand how to make the best decisions in the buildings for conserving energy. And we have the high level executives who want the reporting for yearly reports. And we have to understand all these needs.

[00:11:56] Jesper: But what we did before, we had everything in a monolith. That was a problem. If you went into our app you could see everything, and maybe that scares people, because if you only use 10% you don't want to see everything else. So that's where modularization and putting the small pieces together in packages that were directed to a certain target group really has helped us to come past this problem. So we use modularization instead of customization, basically. Being able to have a quite flexible system will ensure that our users can get what they want and only that, without having to make custom things for them.

Swinging the pendulum to tech

[00:12:41] Host: Yeah, I spaced out a little bit there as well, but I love that approach. And one, it's almost a devil's advocate, because I've seen this a few times where people go, oh, like you mentioned, we swung the pendulum a little bit too far, where we just went solely tech focused. But sometimes I see companies where they have so much tech debt, and just the way things are, they really have to just swing away to focus and just tidy up the house a little bit before you can really start delivering those features. So how much do you think that that was part of your swing, was to enable what you just talked about there, that separation and the modularization? And how much of that was necessary, or do you still think that you even went a bit further than was necessary?

[00:13:29] Jesper: I think we probably definitely went a bit too far in that, and for too long a period of time. We sorted out that, but then continued to work in that way, because we could see that it produced good things, but it was only tech driven. And I mean there was a lot of very important things we did. This might be old news for everyone else, but we moved into the cloud during that time. Some companies might have done it 10 years ago, but we didn't have the time and the calm in the development team to do that, because we needed to sell, and we needed to sell new things. That's one of the most important things for us to be able to scale now, having a completely cloud based database and being able to microservice that one as well. So it definitely was very much needed and I'm very glad that it happened, because now we can scale much more with all the data that flows and we store.

[00:14:34] Host: Yeah, I think AWS just announced their figures. I can't remember the stats exactly, but it was something like, this is how much money we're making, but this is 2% of IT spend. So 98% of IT spend is still not on the cloud. So you're definitely not the only one out there who hasn't moved.

Why building a checkout is hard

[00:14:56] Host: Monika, I don't know, because you're probably more in the design space, but do you know whether you had a similar kind of a tech issue there? Because you mentioned in your talk that you went from this kind of, oh, we'll make it easy to integrate, but then it wasn't so easy to integrate, to then making it super simple. Which, if you're making it super simple for your customers, you're taking all the complexity internally there. So do you have any insights about how did your team manage that? Because I know you were saying some of the things about Fast, but one of the ones I read was that they underestimated the technical challenge of what they were taking on, and that was taking them a lot longer to develop. So what's it been like from your perspective?

[00:15:47] Monika: I mean, building a checkout is really hard. There's a lot of things you need to take into consideration. I don't know exactly what Fast struggled with.

[00:15:58] Host: Also Bolt, they were saying. So their point was that he thought, okay, I'll build universal checkout, but every single customer almost had a different integration, so they couldn't build something that was just plug and play. But you seem to have overcome this problem.

[00:16:18] Monika: Yeah, so what we've noticed is, our complexity on the integration grew because we were adding features. So you're adding new types of payment methods, there are asynchronous ones, so there's more back and forth that you need to include via the webhooks. Or you're adding some third party service modules that now suddenly ask for additional information from the merchants, you need to add additional fields to pass into Primer, stuff like that. So our complexity of the integration grew as we were adding features. But looking at Fast, they have one feature, it's one thing, it's literally one button. They offer no alternative payment methods and it's all processed by Stripe. So I actually struggled to understand where the complexity was, and why they had, as you mentioned, different types of customers with different integrations. Because to me it all sounds the same, but obviously, well, it would be interesting to learn what it was. And I'm also actually surprised to hear, what were they working on for such a long time with such a big team? Well, it was just one button.

[00:17:43] Monika: So we started very, very simple. It was a checkout with a couple of payment methods that worked broadly the same way, and cards obviously, and you could style and customize it. And then when we started adding new modules and different types of payment methods, like crypto, by the way, is also very, very different, now the complexity grew, and we kind of didn't take care of the complexity, rather we just put it on the merchant to figure it out. And then we realized that it's unsustainable, it's not a good developer experience. So, can we include more of the back and forth communication between the SDK and Primer API in the SDK itself? And it's all driven by the automation platform, or workflows, so the checkout just does the right thing and displays the correct information back and forth until you just get payment success, and you can show your success screen, whether you want to use Primer's or your own.

[00:18:48] Host: Excellent. It's great to hear that you've overcome what they obviously couldn't. That would be like a business case for the business schools coming up.

[00:18:58] Monika: Too soon to talk about.

[00:19:02] Host: Yeah, too soon. But the founder actually, we're getting very off topic, but he went on to a podcast like the day or two afterwards, and I'm thinking, you probably shouldn't. But yeah, it was everybody's fault but his for the failure, so he absolves himself. But anyway, moving on.

Customer success as a product input

[00:19:24] Host: So I'm going to jump back into your talk, Jesper. You mentioned the criticality of customer success in what you're building. Can you explain a bit more about how it works that you get your information? So obviously customers contact customer success, but how does that filter through and feed through to your team?

[00:19:49] Jesper: So we have a quite complex product as well. Customer success, of course, like you said, they feed us with product ideas. But the most important reason for them being a very important part of our company is that our clients need some guidance if they want to use the real advanced functions. And the variation of the knowledge in our clients is very, very different. An investor, a sustainability manager at an investment company, they don't know anything about energy and technology, and they shouldn't, it's not their job, but they need someone to help them with that. So I think that's one of the important things with our customer success department being very important.

[00:20:37] Jesper: But what we do basically, every idea that comes in the dialogue with our customer success team and the clients, we save them in our project in Asana. So far I have been personally going through all of them. It doesn't take too much time, because the thing is, I do it, our UX designer does it, and also our product owner does it, because it's a very, very good way of seeing where are the tides shifting. We know the roadmap, we understand which directions we want to move, but also getting a little bit of a reality check, if we hear a lot of clients asking about a certain thing. Of course, if you follow the sustainability news in the EU right now, it's basically taxonomy. That's what everyone asks: help us, how do we deal with the EU taxonomy, what numbers do we need, how do we sustainability report? So we understand this is a shift in the market and we hear it from our clients, they want to understand things.

[00:21:39] Jesper: So basically we collect all ideas all the time, and if we know this is something we're working on, we can put them in that project in Asana, or that research project. If it's something for the future, we put it in a pile for the future to pick up on later. And then we respond to the customer success team so that they can talk to the clients as well, so they know they're being listened to.

[00:22:04] Jesper: And I think one thing that changed there, to avoid too many chefs and also build a better relationship with our clients, is that we talk to them a lot so that they understand also the difference between, I've ordered something that should be delivered, and this is an interesting idea that we might or might not do something with. And they understand that we listen to them, we take everything in, and we need to balance them for the greater good of all users basically. So I think we found a good way of doing that and responding to them in a way that they don't expect it to come out in a couple of weeks. But when they do, we of course inform them that we're releasing new things.

Coming from customer success, and a technical background

[00:22:52] Host: Excellent. And you said actually at the start that your personal background started in customer success before moving in. So do you think that's given you a slight bias towards that, or an advantage in a way of working like that?

[00:23:07] Jesper: I think it's more of an advantage. All of the people that I have recruited for the product team are actually also internally recruited from the customer success team. And now we actually have all new recruits in our company start a couple of weeks in the customer success team, and our sales team will start for a longer time. I think it's really important because in that team you work with the clients every day, you know their pain points, you understand what they want on a daily basis. So I think that's a really good lesson to learn, and you get to be a bit more humble. I can't say it's just a client who wants that and they don't understand what they want, because I understand, okay, if they have a problem that they want us to listen to, it probably is important to them and we need to understand it. So I think it's only strength.

[00:24:04] Jesper: And I was joking a little bit about that in the talk as well, but the importance of customer success to our company now and in the future, that kind of service as a part of our SaaS product, is basically equally important. And I think that it would continue or even become more important when our product becomes even more advanced. I think that's what will happen.

[00:24:36] Host: Yeah, it sounds like it's always the focus on the customer, so it's great that you're getting that background. One thing, and I don't know if this is an issue for you, but it comes up a lot in the conversations about product managers, should they be technical, should they not. So do you have a technical background? Coming from customer service and making the assumption that it's probably less technical, is that an issue for you?

[00:25:01] Jesper: No, I have a technical background, but it's the wrong technical background basically. So I'm a mechanical engineer, that's my field of study. And in that field, of course it's product development, but it's for physical products. So the work process, the understanding of which stakeholders are involved, is basically the same if you have a physical product or code. And my understanding from the business of energy and the technical understanding of how energy works and stuff like that, I have from my research before. So I have that. I don't know code basically, but I don't need to know code more than on a conceptual level, because we have great architects that understand. They're part of the tech team, and they will always know which is the best technical solution, and we talk about it.

[00:25:52] Jesper: So they might ask me, or a product owner, or a UX designer, could we do this instead, it would be easier for us? And we always say yes basically, because it's small tweaks. We want to have an environment where the tech team also is empowered to themselves not just do what someone else says, but also be critical about, is this the right way of doing it? And then if they don't think it's right they will tell us, and then we will talk about it basically. So I don't need to know code because they do, and they will let me know if we did something that we're not supposed to do in the technical part of the product.

Developer success is a product team

[00:26:35] Host: Excellent. Monika, I just want to jump to your talk, because you mentioned that you have a developer success team. Is that essentially customer success because your customers are developers? Or are your customers really the marketers who are buying it? What is your customer slash developer success setup?

[00:26:56] Monika: So it's not the same thing. We do have customer success, which is usually talking to the head of payments or the CTO or the payments product managers, or whoever is sort of buying and making the decision to use Primer, who's the key stakeholder on the payment side. Developer success obviously cares about the developers who are integrating Primer, but also we want to build a community around Primer in the developer community. So I think that if we do a good job on the developer experience side, developers will be choosing Primer over other payment solutions. And that's really the goal.

[00:27:46] Monika: And there's a lot to be done on developer experience. I think Stripe is famous for being developer centric in the world of payments at least, and literally every developer I know who's built a Stripe integration thought it was very, very painful, and they're still known for the best developer experience. So I think there's a lot that can be done and improved. So we're just striving to become the obvious choice for developers, and giving them an amazing experience even when there's someone else in the organization who made the decision.

[00:28:32] Host: Great. And so with your developer success, is that somebody to talk to, or is that team just focused on, we have to have the best API docs? So is it more, can developers self-service, or is it a call center help type of a situation?

[00:28:47] Monika: No, it's a product team. So it's a product team with a PM and engineers and a designer. And they obviously own our docs, our API reference as you mentioned, but also thinking about what developer tools can we build to make the integration easier. So for example testing tools, debugging tools, the developer section, and self-service as you mentioned. And we're also trying to figure out how can we improve things even more, so what other types of developer tools can we build to facilitate the integration, like an interactive integration walkthrough that helps you understand rather than just read through the docs. So that's essentially the developer success team, which is a product team.

[00:29:40] Host: Excellent. I completely misinterpreted that, so thanks for the clarification.

Balancing many different types of user

[00:29:47] Host: Great, so I think we've gone through all of my questions. Did either of you have questions to each other? I know Jesper actually started off by getting in a few of his questions. Do you have any further questions?

[00:30:02] Jesper: I was thinking a little bit. One thing that also interests me, you talked about, and also now that you have, it's also something that we struggle with of course, but I think it's maybe more clear for you as well, so everyone would want to understand a little bit more how you work with that. And that's the different kinds of users of your products that are outside, like external stakeholders. You mentioned the merchant, which might be what you would refer to as your client or customer, but then you had the developer as well. I didn't really understand that as well before, I thought it was an internal developer, but now it's also an external client, and they have an end user also. And we're wondering about, how do you balance all these needs? And then you have all the needs of these internal stakeholders that want you to do different things. How do you manage to understand all these needs and put them together? Because my guess is that they don't know each other's needs, in the organizations you work with either, so someone needs to.

[00:31:12] Monika: Right. Actually there's more than that, because we also build parts of the product specifically for support teams. So we have a lot of support agents using it, because oftentimes when there's something wrong, there's something wrong with payments. So we have massive support teams who are just using Primer's dashboard to find that transaction and inform their customers, like oh, why the payment didn't go through, or why they cannot have a refund, or whatever the case might be. So that's a very different type of user.

[00:31:46] Monika: We also have products for finance teams, so financial reporting and reconciliation, which is again a very different type of user, that cares about the output rather than configuring the payment strategy. And even to make it even more complex, we also have partners. So all the third party applications that you can use on Primer, most often we partner with these services, so we call them partners. And we're opening up and allowing third parties to build integrations to Primer without us being even involved. So that's again a different type of user, which we're building, we call it Primer Connect, a separate dashboard.

[00:32:37] Monika: What we do is basically we have those teams that are built around a problem area of a specific user. So we allow the developer success team to focus only on the developers that are building integrations to Primer. The Primer Connect team only focuses on partners and their developers. And the payments operations team focuses on the finance teams. So it's quite easy to have this very, very specific focus when you have very clear product ownership over a specific area. And you don't have to decide or to find priorities between those teams, because they're independent and they have their own set of KPIs, their own roadmap. There are, in many cases, dependencies, right, like the checkout works along workflows and so on and so forth, so the teams do collaborate a lot, but they have their specific usage that they can focus on.

[00:33:47] Jesper: That's interesting. It sounds like a good approach to it, then. You basically have each team are experts on a certain product area as well.

[00:33:55] Jesper: Yeah, in the case where those product areas in the product need to have some API or some integration between them, they will sort it out, but usually they operate, they are not affected by each other in that.

[00:34:15] Monika: Yes, so we're trying to find this separation of concerns to make sure that everyone is independent and can move as fast as they possibly can within their product area. But the reality is of course that there are interdependencies and people collaborate and share information.

[00:34:35] Jesper: Sure, great.

[00:34:38] Host: That was a great summary actually. I really like that structure, it's perfect for the customer centricity approach that we advocate, of each team focusing on a particular customer. And I think that's all we have time for today, but I really enjoyed our conversation. So thank you to Monika and Jesper for sharing all of your insights and thoughts.