StormForge Fireside Chat Podcast | Episode 1

Puja Abbassi (@puja108), VP of Product at Giant Swarm, speaks with us about identifying pain points in the dual world of being both a vendor and a trusted partner. From moving to Kubernetes, or managing clouds, to identifying partners and helping with product introspection, Giant Swarm has a lot of user needs to solve.

NOAH: Hello everyone and welcome to our podcast series that we’re doing before KubeCon. We’re here this week with a bunch of different people from a lot of different areas. Today’s guest is the inimitable Puja Abbassi. Did I say your last name right?

PUJA: Yes yes.

NOAH: Excellent, perfect. And my co-host Cody Crudgington. I am Noah Abrahams, the Open Source Advocate here at StormForge, and gentlemen if you would like to introduce yourselves more than I did already?

PUJA: You go first, Cody.

CODY: Yep, Cody Crudgington, leading the Customer Success and Professional Services here at StormForge.

PUJA: Puja Abbassi, VP of Product at Giant Swarm.

NOAH: Great. So this week’s topic, we’re talking about pain points. We’re talking about identifying them, and how they lead into… how they lead into vendors, how they lead into solutions, how they lead into people building their own things, whatever it comes out to be. So let’s start with the identification of a pain point. When somebody comes to speak with Giant Swarm, what are the pain points that lead them to come talk to you in the first place? What drives them to you?

PUJA: It is different depending on the stage they’re in, right? If they’re just starting out with Kubernetes, the pain point might be like moving to Kubernetes, moving to the cloud. If they’re already started, it might be wanting to scale in the cloud or for cloud native projects within their organization. If they’re really far, it might already be pain points around consolidation – being able to manage a lot of clusters centrally. These kinds of pain points.

CODY: Yeah, so Giant Swarm is kind of both a vendor who gets picked and a trusted advisor who helps customers pick their solution. What’s it like balancing the customers needs in a world of partners and solutions?

PUJA: There is definitely kind of a balancing act I guess as you said. It is thought that we try to really keep the trust as this trusted third party to not like misuse it, so we don’t usually take any kickbacks, for example. So we try to stay independent of vendors and try to also, let’s say, kind of vendor proof or lock-in proof the solution. So in case something happens with the vendor or in case something happens in, I mean in this ecosystem stuff happens very fast, companies get bought, projects get changed or get donated or might not live the next year, so we try to kind of avoid a too hard technical lock in to a solution and try using these cloud native technologies actually. The abstractions that are already there and most cloud native projects out there try to use them to the advantage of not locking ourselves in.

On the other side, as we are responsible for a lot of these things too, sometimes we just need to be opinionated and think about ourselves. Like if I’m responsible for the operating system, then most probably I want to choose the operating system and I don’t want to listen too much to the customers besides their needs, their pains on that level. But if I’m responsible for keeping that up, if I’m responsible for keeping up the network, most probably I’m going to choose the networking plugin, for example, or the solution. Hopefully through CNI, for example, being abstracted away so much from the customer that they don’t need to migrate their network policies once I change maybe the CNI.

NOAH: So are you maintaining a list of partners that you have or are you going back every single time? You said you’re not doing any sort of kickback, but are you still doing partnerships to enable those particular solutions?

PUJA: Yes, we do. In some cases we do, and especially in those where we usually just have a single partner. For example, on the OS we work with Kinfolk on Flatcar, so there is like a direct relationship that is quite fixed there. On the other side, we try to keep good relationships with all the partners. That’s sadly something that without conferences happens less. Usually on conferences you run around, you meet all the all the other vendors, so for me conferences are usually the place where I meet all the potential partners and we talk and might talk about, hey there would be this like really cool case to work together, so let’s keep the relationship and see if we can work together with the customer, for example. On those solutions that are also quite customer specific, we usually also don’t try to come with our partners, but just make suggestions toward the customer. The customer still should choose themselves, but oftentimes we see being pulled into those vendor choices. Like we were pulled into a very big security vendor choice last year where it’s like hey could you join these vendor talks – let’s get a third opinion there.

NOAH: So one of the things you just mentioned was about conferences. That in person interaction being able to sit down and talk to people. Now you’re Europe-based, but when you look at your customer base and you look at how these relate to the conferences that people are meeting up, because a physical conference is going to have some sort of geographical tie, are you seeing any major differences between the conferences that people originate in or between the markets, like between EMEA, US, Asia, and how people are identifying pain points, and how people are identifying their problems, and how they communicate those problems – whether it’s when they come to you or whether it’s whether they’re talking at the conferences?

PUJA: I’d say you have that definitely a bit between like US and EMEA where in the US sometimes companies have a bigger tech opinion and might come with more opinion and less of a pain, but more I want psyllium. But what do you want? Or I want the service mesh. What do you want it for? Right? And like we’ve seen that a few times more like in the US than here in EMEA, although this is pretty much very common that like especially depending on the person you talk to, they’ve read about service meshes, that’s awesome, and they want to have it, right? And finding the pain point is really really hard.

You also have a tendency to talk to people like that more on something like a KubeCon because people have a more technical background. They do sometimes like a solution already or have a solution in mind, so like pulling them back and saying hey what is the pain actually, or like what is the problem you’re trying to solve, do you want a hole in the wall or do you want a drill? And let’s look at what are the different ways to get that hole in the wall…

NOAH: And what is… Sorry, I didn’t need to cut you off there, but I wanted to go a little bit into what does the time look like for that? If you’re spending more time on that for you as a vendor as a consultant, do you find that it’s harder to identify the pain points with people who’ve already come around with a solution, or do they tend to have more articulation around what they want?

PUJA: I’d say it depends. It’s sometimes quite easy to get from a solution to the pain points as long as you stay patient and ask questions and try to actually find. What we have found really interesting is just going back to the use cases and saying okay, what is it you want to achieve? What is it… what is the end result? What does your software actually need? Are you trying to globally roll out this e-commerce software and what are the pain points in that software? Let’s drill back into those.

But on the other side, also sometimes when people come with a pain point, the pain point might be too abstract. So that might sometimes even be harder to find the actual pain point. So sometimes it’s easier to drill back from the solution to a pain than from a pain that is maybe just perceived and not really there, or the pain that is too abstract and might be a business pain that is very abstract and on a level where you’re not really sure what the actual problem there is and how to attack it without maybe changing even organizations and the pain might be organizational and processes. In big companies, that’s really hard to change. And then you need a real consultant I guess.

CODY: So being in the kind of [paz] and MSP space, what’s Giant Swarm’s process for identifying pain points and how do you go about solving those?

PUJA: So our process is usually very early on trying to really understand the use cases, the projects that are trying to get cloud native and get to be deployed, for example then on Kubernetes, and building a real relationship kind of as like a almost the external SRE team, as like the extern like the trusted friend that you would ask what should I use? Building this trust based on experience, based on being independent, and still I think there is a balance to be struck between independence and having relationships with a lot of partners because it’s important to know people I feel in this ecosystem, or the companies in this ecosystem, because once you’re using a project, you might find bugs, right, or you might find issues, or you might find… and solving them together with the vendor, that’s much nicer than just creating tickets. Just sitting down with vendors, and this is kind of a unique position we’re in because we’re operating the things usually for the customer, is that we can actually sit down with the vendor and look at it together maybe. We might even be able to give them access or a test cluster to run together, and the direct logs there’s no like… not a lot of steps in the feedback loop. The feedback loops are tighter and if you know the maintainers that’s even better. If it’s an open source vendor, for example. And you can maybe even contribute. Maybe I think one of our colleagues contributed the helm chart for Loki when it came out because I was so excited about that project like finally! And it was I think in KubeCon Seattle that it was announced, and he was in a hotel room with me, and he was sitting there late at night still hacking on that helm chart just because he wanted to contribute it, and he wanted to show it to his customers later.

NOAH: Awesome. So, you mentioned sitting down with the customers. Has that been something that has been drastically affected by the face-to-face aspects of what’s going on in the world today? Like dealing with this pandemic and whatnot?

PUJA: Interestingly, it has been affected quite positively, and especially in the second half of this pandemic phase that we are in, and it’s actually interesting that people are finally realizing you can do these things remote. There are still some things missing, like actual face-to-face, being able to have dinner together in the evening between two days of meetings, for example. And those sometimes miss, but we’ve realized that it’s become actually quite easy to not travel anymore, even for bigger contracts and even for building this trust. Doing more remote, it’s also learning because we used to maybe do a workshop for a full day. Full day workshops online don’t work. It’s just… you have to split them up into like three days each, like maybe two or three hours, smaller workshops. Those work a lot nicer. These are some of the learnings. The other one that we did was we actually introduced like a monthly customer and potential customer evening where we sit down maybe with some drinks and talk about the topic, just to get to know each other more and talk about the problems that we are facing. Sometimes it’s not even us that can solve them the problems because, or can understand the problems that well, but might be a different customer, or it might be someone that we know that is not a customer, like maybe a Zalando who has done this themselves and they can help some of the customers to understand the issue that they’re currently facing.

NOAH: So I would expect that if you’re taking a day-long workshop and you’re breaking it up over multiple days that now you have the opportunity for the team members within the customer to go back and talk about oh, we didn’t even really think about this particular point in this particular way, now we can put words to the problem that we identified. Is that helping the outcome of the workshops that you’re running to have them be able to get back together and have their internal conversations?

PUJA: Yeah, indeed. That’s a very good point actually, and it came by accident. Wasn’t planned like this. Especially as we kind of split those three days into different weeks, so it was like maybe we did one the first one this week and then the next one in two weeks. So there was like even maybe a week or two in between. So they might have even tried out some things. It’s like oh I tried out this English controller and I tried out some security settings, I have some questions again. And we can talk about them. So it is quite interesting and you can also pull in different people, maybe based on the topic, because if you’re splitting it up into maybe different topics, you could even pull in different people from different places in the company. Maybe someone from the security division won’t be able to dedicate a full day to it, but if you say hey these two hours we’re going to talk about security and we’ll find a day where you can also join, it’s going to be more interesting. So usually especially in these bigger organizations, you want more people to be in these conversations early on so no one hits the roadblock up ahead and says hey, but our network is behind a VPN.

NOAH: Awesome, awesome. Well, I think I’m out of questions for now. Cody, do you have anything else that you’d like to talk about with regards to pain points while we have our guests?

CODY: No I think we’ve pretty much covered it all. I think we can move on to the infamous Rapid Fire questions.

NOAH: Okay.

CODY: I’m gonna let you run with it. I’m gonna let you run all of them.

NOAH: Okay, first question. Yes or no – pineapple on pizza?

PUJA: No.

NOAH: Okay. Favorite piece of technology, any technology.

PUJA: So hard. I guess my iPhone.

NOAH: It’s like a lifeline now, right? Favorite open source project.

PUJA: Kubernetes.

NOAH: Favorite hobby?

PUJA: Martial arts – Chinese martial arts.

CODY: Very cool.

NOAH: Favorite place for vacation?

PUJA: Thailand.

NOAH: Okay, that’s the end of our Rapid Fire. Those are fun.

I want to thank our guest today, Puja. Thank you for joining us. This has been a great session. Insight into… I think you have a really great unique view as both a vendor and a consultant. It just brings some points of view that I don’t think a lot of other vendors can bring to the table. So, thank you for joining us today, and stay tuned for our next episode.

Thanks everyone.