What Makes a Great Product Company (With Raymon Sutedjo-The)

Now, Raymon, Questions to start with, just to help pitch and build the scene a little bit here, build a bigger picture, first of all, Marqeta FinTech, what is exactly that you do as an organization? Yeah, I think it's not hard to explain, but a lot of the things that we do is behind the scenes if you will. So a marketer builds a lot of, technology and platform to support financial institutions and companies, right? So we built tools and platforms and APIs that enable other companies to do their business your door, your Uber, your. Yeah, so if you look at a couple of examples on the dot com website, you can see a couple of case studies, right? And I think companies started with card issuing. But now we're expanding to other parts of kind of the finance world moving into credit into banking and money movement into risk and fraud management. Into tokenization, so a lot of different aspects of, finance and payments. Wow. So you started off as a. What a smaller company focusing just on, did you say card issuance and that type of stuff. And then it's grown from there. Yeah. If we're like going all the way back I think the very first I don't quote me on this. I'm not a marketer historian, if you will. But yeah, I think in the beginning there was a lot of different pivots. I think even they dabbled in whatchamacallit, rewards, card rewards and all that. But at the end, the one that really found the product market fit was card issuing. And that's when Marketa really took off. And then with the broadening of your offering, I suppose then you are shifting from a, this kind of narrowly focused smaller organization to a much more broadly focused enterprise. Absolutely. Yeah like I mentioned a couple of areas that marketer started to expand into is, banking and money movement, for example. Prison fraud management and those are some of the areas that I also lead on the design side. For example, last year we officially launched the product suite that we call risk control. And that's 1 of the kind of newest product offering. And we also launch officially my game money movement products which we're continuing to build and evolve. Among others yeah, I think you're absolutely right. We're just starting to expand into other parts of the payments in the street and really providing a lot of different solutions for different companies. Right? Some companies might need just reason for our management. Others might need everything. Others might just need, card issuing. So it's pick and choose your own event. So then as a design manager, you mentioned that you're, you've led up a couple of the more recent offerings. Within Marqeta, as a design manager or design leader manager, what is it that you do? What are your, what's your reason for being in the organization, Raymon? Yeah. So I think there's a lot of different offerings that Marqeta has, right? A lot of it has to do with APIs and providing that backbone and. Scotland and blueprint for other companies to use to build their products on. But also we provide things like what we call the marketer dashboard, which is the end user facing. Tool, almost like your think of your sales force, your Zen desk, your service. Now, those kind of tools that our customers can use if they're not. Using APIs, or if they're choosing not to, or they're trying to do something else with our products, and maybe they don't necessarily have a lot of custom needs and we can fulfil their needs just by using the dashboards. So a lot of the design work that we do revolve around the market dashboard. For example, somebody, our customer might use the dashboard to. Look at transaction disputes for their cardholders and manage disputes accordingly in, in in my credit dashboard. That's not the only thing that we do. We also support things like the go to market efforts. More recently, that's been happening more. So we help the business development team develop the pictures and the the story. That they tell to prospective customers, and because we do have the, the knowledge on the product side, we are able to help them paint that picture for the prospective customers. And help them understand what it is that marketer can do for them, especially if we can't just talk about the APIs and codes and technology, right? Ultimately, our customers who may not know about the company and the products and the technology that we offer. They want solutions. Yeah, they want things that they can use for their own needs, business needs. And our role in a product design team is to help the business development team build and paint that story. We always call it like the art of the possible. What is it that you can do with our tools, with our technology, with our solutions, those kind of things. of course, there's also other support things that we do , all product design in the in the broader sense. Not just focusing on market a dashboard, but also, for example, documentation developer experience, customer experience onboarding. I think there's a lot of things that we do on the product design team. And I will also say that might vary company to company and team to team. Depends on what your product is, how big the team is, how big the company is what it is that for example, like, if you think about health care, right? I think. A lot of the considerations might be different from what we do in payments. Or if you think about government work, very different versus media or consumer type of products, very different as well. It's something that really piqued my interest there, right, was . In a traditional organization, let's say a normal, say normal, an old school kind of tech organization where you've got technology on one side and maybe you've got the business on the other perhaps you've got someone like product or some kind of change function sandwiched in the middle. Yeah. And. What I've always found is in those traditional organizations, the art of the possible was defined by a sales team who would go out and sell something and then turn around to. Product or tech or both of them, or tech via product and say, we have sold this and we have promised it by this date, go and do it. What I found refreshing was it sounds like you are being brought into those conversations so you can explain just what is possible and how over and above the API is your overall solution can assist your customers so that you are more integrated into that sales process. Is that a fair. Reflection on what you said, I would say so I would also maybe caveat it by saying that it's a relatively new muscle for us and I think in the customer with the salesy type process. That's a new muscle. Yeah. Yeah. For us as a team as an org I think that, I've been at Marketo for a little over two years now I think in the first. Like, you and a half maybe just under 2 years, we haven't really done a lot of those, but I think more recently we've started doing that. Yeah, and I think it's a new muscle, but I think it in a way, it makes sense. I've also been in companies or, and this is more on the consulting agency side, in the past where what the scenario that you're describing was. It's true, right? Sales would promise the world, right? And then came back to product and tech or saying, yeah, the customer bought X, Y, and Z. Can we build those? We don't have that right now which are frustrating and always say a source of tension because then any kind of priorities and all that goes out the window. And we're being dictated by that. Yeah. A little bit , I think that's not necessarily the case right now. Always room to improve in terms of how we do it and how products and we support it. And ultimately, like, if we're in the process right now of trying to figure out how to make that a more efficient process, for example. Does every conversation need to have product designs involvement? Probably not. And how can we make it a bit more perhaps actable, so that each of the pitch or BD conversation doesn't have to be corporate custom, right? So where's. Still trying to figure that out and make that process a bit more streamlined. But yeah, that's where we are right now. I think it's fascinating and for me tells a bigger, tells a chapter of a bigger story that's going on, which is this transition from the traditional textile companies. Where technology is seen as something which you either buy it or you build it. And if you're going to build it, then you create a separate department and then you try and manage that separate department, like you would have done a warehouse or a manufacturing line or some other somebody, some other part of the organization, which traditionally would have provided you with something tangible to actually a situation where product organizations are much better integrated. And the interactions between the different silos are better defined. And I think create a more holistic alignment against what you're trying to achieve. And this is why I think that organizations that started. And grown and with a strong product focus, and you know what it is to go out and have to get revenue and go and get funding. Then it means that you're going to start having a different attitude to how you go about doing your work. I think a lot of the organizations which are trying to get a shift from the kind of technology to being producty organizations. I've just got a lot of baggage because they haven't, they didn't start that way. They're trying to transition across to that kind of mode. And I think that's very challenging. One company I know of. And I won't mention who, and hopefully he, the person that I'm talking about we'll be listening to this because he's a very senior product person and he enjoys some of the conversations that come up, but he said to me, now I'm going to totally shortcut and paraphrase the conversation that really like shit got real for them. And they became much more product focused when they had to make redundancies. And then they had to become more focused and the purpose, they were more able to learn the purpose and they couldn't stick to the silos and they had to evolve how they were working because they wanted to succeed. And I think it's, and the one common thing I think about that situation is that organizations that started and then grown and experimented and pivot, they pivoted is that scarcity. It's a scarcity in the high level on purpose, which I think is really refreshing to hear. And I love the fact that you were involved in those those sales and those marketing to go with the salesy type discussions. Cause I think that's, for me, that's a big tick in the box when I'm working with organizations is seeing that type of interaction. One thing that I'm interested by. There is a parallel between what you spoke about there about product people being involved in all the conversations in the Agile world, people saying two teams be involved in all the conversations in which people are involved in what conversations, right. And that's always been a common Agile gripe. I'm wondering on that Agile theme from your experience as a product designer in the product world, is there anything else from the Agile world, which you are seeing being taken on board? Or any kind of parallel challenges that kind of the agile world, but you're also experiencing in the product world. So I think I'm also seeing how product design specifically as a as a practice starting to adopt some of the agile framework and methodologies, right. Your two week sprint, your retro at the end and that whole ritual. I think that at least in the last. We just said, I've had that was the case. So we use the sprint framework and trying to in the way. Quantified the work in some ways, or make it a little bit more tangible because I think. With designers often challenge of. Making the work a little bit more visible. Occasionally, it seems like there's a perception that. Design is a black box, right? You. Go to the design team, you want some sort of a solution and all that. Sometime passes and then there's a solution and I think. Doing it with the agile framework and all that breaks down to work a bit more and quantify that and make that more tangible in a way that also helps. Outsiders understand a little bit more. What are we doing this friend? Oh, we're doing some user research and we're talking to 3 participants and that's going to be. A 5 point story, something like that. Having that and. Making that a bit more visible and tracking the work and all that. And the way helps internally, we're doing the work. We know what we're doing. We know roughly, when we might have results or, like, the timeline and this and that, but. Outsiders might not, which I suppose is a similar challenge then to many technology software development teams is that technology is often seen as a black box where some requirements or some kind of specification went in and then cross fingers. At some point, some stuff is output and you. Lucky if it meets what you'd expect. And I suppose then people embrace agile because it's endless focus on a short period of time and let's focus on delivering something of value. What you're saying has helped is being able to break things down into the into steps, which you can clearly articulate, which tell a story about what you're working towards. Yeah, absolutely. I would also say that in some ways design work is a little bit tougher to quantify compared to like engineering. When you say quantify, do you mean the value of it or the, what you're doing? What's the hard part? The latter, I would say. For example, if we talk about doing some initial sketches or like lo fi designs, that part can be a bit nebulous, right? It could be that we're exploring a lot of different options. We still don't know the exact shape of it yet. Or if we are a little bit more clear about what it is that we're going to do, but we're just exploring some small options or permutations. So in that sense, it's a little bit more flexible and valuable versus. It seems to me, like, with engineering tickets or work, it's more concrete, right? Like, hey, we need to, look into this API and connected to the front end, or we need to build this component and we have, like, a distinct. Not to say that design won't have like a more distinct output at the end of it, but the middle part tends to get a little bit more messy. So there are situations where I think that some technology teams do struggle to produce something which is meaningful, it really shows a step towards something. I can imagine some people almost being surprised at what you said. Not in a negative way, but surprised because I think that showing a lo fi design is something that people can see and interact with in some way. Whereas I think some technology teams are stuck just producing stuff that people can't see or interact with. And I think that provides them with a. A really big challenge, I find it really interesting that similar challenges felt on the product design side as well. Yeah, and I think at least from what I can observe, a lot of the. Challenges often with product design, especially if we're working in sprint is really to break down the work, right? We often have challenges with, working the work down into small bits of tickets that we can tackle in the sprint or things like that. We tend to put in the big bucket, right? Hey, I'm doing research. Yeah. Or like, hey, I'm doing low fi designs. Or I'm doing usability testing or whatever it might be. And that could take a little while and maybe it'll expand beyond, like, 1 sprint. Right, and that happens often, and we need to get better at that. We're actively trying to get better at that. But yeah, and I think I also mentioned earlier before the podcast, there's also like a challenge or like a balance that we need to. Strike because we also don't want to lose the big picture, especially with design. We maybe we want to consider like, the cross product implications of our designs, or maybe we want to make sure that we're not just considering the feature. Or the product in isolation, right? What is it, what implication does it have on that our product area or like, our. The market dashboard, I'm using our example as a whole. Are there any changes that we need to communicate to the design systems team and things like that. So a lot of the bigger tickets are like maybe longer term implications and considerations. We need to be a bit more vigilant about that because sometimes it gets a little bit lost when you are focusing on like the current sprint and the next sprint and the backlog and the tickets and breaking down the work and all that. Is there an overarching mechanism or roadmap or something, which then takes the work that you're doing and the work that they're. software creation teams are doing and helps it all to align. So right now we're we've been doing what we call the V2MOM. It's this word acronym, but it's it stands for vision values methods, obstacles, and measurements. So it's like a high level way of alignment. Right initially developed by Salesforce, and then we're adopting it and we're starting to use it like. A year ago, 2 years ago it's a way for everyone at the company to align. Of course, we're still willing that muscle up. Our process isn't 100% there yet. But it's a way for all of us to align so that. At the top level you might say that, hey, method number 1, this is like our top priority and. It goes to be above number 2 and number 3 is about number 3 and so on and so forth. And that cascades down to all the different teams and product areas and functions and whatnot. There's also, of course, our roadmap. I think more recently, we've experimented with the lean or mapping, which. You heard about it in the conference, right? The whole idea with, do now the next 2 later kind of idea and having, , and being a little bit more flexible with that and giving you a little bit of a space to change and pivot if needed. Yeah, those are some of the things that I can think of that help us align as a team, as a company. So working backwards, we're now next later. I'm a big fan of that, even in my personal life, me and my wife have been I say me and my wife, me mostly because some people will say, Oh, what time is the, what time is the kid's dentist appointment tomorrow? I'm like, I don't know. That is tomorrow information. I do not need to know tomorrow information today. Right now. I need to know, , have we got something in the house for dinner and, are my children leaving the house with shoes on? But that's today information, tomorrow information, I'll deal with tomorrow information tomorrow, but it's that ruthless prioritization of being able to say, would you want it now or next? And actually that now next later, if you came way back and Mike Cohen wrote about this, I think 10, 15 years ago, perhaps in one of his early agile books, I believe saying that prioritization doesn't need to be any more complicated onto it. Is it now or is it later? And initially just being hard on that ruthless prioritization saying, is this, do we need to care about this now? Is this contributing towards something we're trying to prove or disprove now? Or it, can it come later? Because if it comes later, we just put it over there. I'm a huge fan of that. Previous thing you've mentioned, what was it? V, say again, V to mom. So it's spelled V, letter V, number two. And then I'm like, Oh, V2MOM. Okay. Mom, I can't say it. I'm sorry, but it's a real problem because then when I go and recommend the book, the mom test, I just sound like an idiot. V2MOM, is there information on V2MOM? Yeah, I believe like if you Google it, I'm sure you'll find a ton of resources. Okay, great. Not heard of it before. I will absolutely include that in the show notes and do some reading on that. So thank you very much. That is a really interesting thing I've not heard of before. Like now, next, later roadmaps, particularly using OKRs. The world and its dog seem to be trying to use them in some way. But VT1 I've not heard of. So thank you very much for that. One question that I think people listening might have. This sounds like. You're doing a decent amount of upfront work before it goes to the teams to create the solution, right, to do the programming. And I know that in the agile world, that's always something that people have really struggled with is how much upfront work is done before you can't say you're agile anymore. And I kind of think that's a understandable concern, but I think people make more of a deal of it than it needs to be because some work just needs to be done upfront. Now, in your experience. Like, how have you found that handover then, from the upfront work you're doing to the teams that are going to create it? Do you find it's done in a big batch? Do you find it's, in your experience, do you filter it in bit by bit? Like, what is your approach? Yeah, I think right now what we've been doing for a couple of months now, starting last year is we have, I'm speaking from product design. We have like a design intake process. So any kind of work that need design support that needs to appear in my kind of dashboard we filter through the intake process and I consider that as like doing the work up front. Right? And what that does is it asks a lot of questions in the beginning to understand the problem space a little bit more. Right? Who are we targeting this for? What are the user needs? What are the success metrics? What are the, technology implications. Do we have the APIs ready to go? Do we need to build them? Things like that. A lot of kind of foundational, fundamental questions. Yeah. And what that does is that it almost acts like a forcing function. ideally most, if not all of those the answers are ready to go when we do the intake. But if not, it then forces a product and or engineering to do the homework a little bit. Right and figure out the answers to those questions. And that doesn't mean that the discovery work ends with the intake. With a project, we do find that it's useful to do what we call a sprint on the design side. And that's going a little bit more in depth with the discovery work, right? We might do some more digging really looking into maybe password looking into maybe some light research. And the output could vary. I've heard cases where the output of. Sprint 0 was not to do the work. Yeah, maybe it's not worth it. Right. In some other cases, we might do the work as this. We might do the work with some modifications and all that. But yeah, I think. Going back to your question about doing the work up front. Right. I think it's critical because we want to understand what we're dealing with. We don't want to understand the problem space, and it might appear that you're moving quickly if you're jumping into the problem immediately, but you can go fast. But if you go fast in the wrong direction, what's the point? What's the point? Reminds me of my friend Bars of Oda. But he lived in Singapore for a long time and he was stuck in a traffic jam with his kids and his kids were looking on the other side of the road. And they're like, daddy, they're going so quick. And we're going so slow. Like, why can't we go that quick? And Bob said we absolutely can go quickly, but it will be in the wrong direction. What would you prefer? We go slowly in the right direction or very quickly in the wrong direction. And their answer, we want to go quickly into the wrong direction and pass forward to yourself. And this is the problem that we're facing in the industry is that people are so keen to go quick. We never make sure they're going and they don't increase their confidence they're heading in the right direction. And I think given the space that Marqeta is in, like payments, there's also a lot of complicated things that go with it. Right. Requirements, whether it's technology or legal or privacy or whatever it might be. So a lot of those have to be taken into considerations. Before we start building, before we start designing, I suppose that glimpsed background to what we spoke about in the beginning of our conversation, which is a, who do you get involved in? When, so I guess if you're looking at the technology aspect of it, what was the, if the current APIs are sufficient, then you may involve someone from technology to bounce some ideas off of. Yeah. During the intake process, we we'll have design, obviously usually it's me plus. Designer on my team, optional usually, we always have at least 1 person from product and 1person from engineering. there's always at least 3 people in those intake meetings. so that we have a representation from each of the function, right? In case there's something that we need to know. Some flags are some considerations that maybe we didn't think of. I think that for the most part works, I think usually provides us with enough coverage to start with. And again, that intake process is not the end. We'll continue to have that conversation and dig into more details and all that. We'll find out more things. But yeah, in, in that first phase the process, we almost always include three people from three Disciplines, right. Product engineering and design. Three is the magic number. It appears when it comes to getting people together. Same as when I talked to a company called Panda docs, they have a trio of people that lead certain areas of the product, and you go back to many years ago, something called it was a book by Gojko Adzic called Bridging the Communication Gap. Yeah, but he talks about the three amigos, so always interesting how the number three comes up. Let's draw this one to a close. And what we can do is we'll pick up a, another topic in our second conversation, if that's quite all right. Yeah. I think this has been. Really interesting. And if I'm taking away one particular thing, two things, let's say from this conversation, one is the V2 mom, which I hadn't heard of, or at least don't remember hearing of. So I'm really looking forward to learning more about that. Also your design intake. process, what I really liked about it, and probably because it's similar to what I help organizations do, is that I articulate it from a commercial perspective as each question you answer will either increase or decrease your confidence to continue funding the idea. And there's like a critical level of confidence you need to reach before you say, let's release some proper money onto this and get something created or test this in the market in some way. And that design intake, there's questions that you ask, the upfront work, which needs to be done. You can't, there's some stuff that you can integrate into agile product creation teams. Whether it's Scrum, Kanban, whatever they're using, but there's always some stuff that needs to be done up front. And I think historically, a lot of that work was maybe done by people in the business and was just very opaque to everyone else. And they were just given stuff and not given that information. I think that, going back to what you were saying about... In Marqeta, product being involved in some of those conversations around the art of the possible, being involved with sales, creates a holistic view and really is a fantastic way to help build that confidence enough so that you can fund and the fact it's being done by somebody other than like the business and in inverted commas, yeah, I think. It means that you can utilize such fantastic skills within the product community. And so I think that's a big takeaway for me is that whole process. So thank you so much for sharing that. I really appreciate it. And I hope everyone else who's listening has appreciated it too.