Symba Revenue (2024)

[00:00] Hi, everyone. I'm Nikita Gupta. Thank you for the introduction. I'm the co founder and CTO of symba, not for the Lion King, but for symbiotic relationships. This is a very timely topic for us to talk about for me to talk about personally because at symba, we just went through a whole new product revamp in the last twelve months. So I've got some insights to share. We'll share kind of like what I found surprising, especially with dealing [00:26] with my very small product team and a decent sized engineering team. So before I begin, I just want to kind of get a pulse of the room here. Who actually has an actual product team that is separate from their engineering team, with product leaders, PMs, product engineers. [00:46] Who here gets to wear multiple hats and kind of be a PM as well as a technical leader too? [00:54] Nice. Yeah. So we're kind of arranging here too. We've actually had a lot of our team members wear multiple hats. So even our customer success managers and head of customer success have also dipped into PM as well. So I will go ahead and start talking about it. So over the next twenty minutes, we'll talk about what does alignment mean. So I'll share a little bit about our product journey, what didn't work for us, and some of [01:18] the hard lessons that we learned. I wanna teach about how do we get to alignment. So, how do we evaluate the bottlenecks, how to understand different signals, and how to think of an implementation of a new strategy. And then also, how to keep it sustainable. So, avoiding the bottlenecks for the future and how to keep the surprises at minimum and create a sustainable plan. Does that sound good? Yeah. Cool. So, we'll start with alignment and we'll [01:46] start off, like I said, with symba's product journey, what didn't work and some of the lessons learned. So right now, if you go on symba's website, this is what our product page shows. We are the end to end platform for early career programs. We onboard, manage, and engage your early talent from program acceptance to alumni status and track important program and DEI data in one place. So this has taken a few years to get to. And [02:12] we've been through kind of a crazy journey. In 2019, we built a product that really wasn't a pain killer. Just to give everyone context, symba comes into play after you've hired your interns or your apprentices or your new grads. And we help you manage the entire experience from as soon as you give them the offer to project management, performance tracking, feedback, community building and engagement, all the way to even post program engagement as alumni. In 2020, [02:40] desperate times called for desperate measures, and we then became a pain killer. 2021, we kind of cruised with our product. We kept improving, and we got a lot of great customers to give us feedback and ideas on new features to build. But in 2022, with the challenges in the market, there was definitely a decrease in product innovation. To be completely transparent, we struggled a lot with product in 2022, which is why it's really timely for me [03:05] to talk about this and how we were able to maximize the skills from our product team as well as get all hands on deck and then also create alignment between our engineering team. To give everyone context also, we have an offshore engineering team. I have about 10 engineers based in India. They have been with symba since day one. So even with working with different time differences and having our product team, marketing team, business development, sales in [03:32] America, you can definitely add to the misalignment that happened in the beginning as well. So some of the things that didn't work for us was that we were becoming very reactive reactive to what our customers wanted. We only built features that when they complained about something or they asked for something, we would build that and weren't thinking about being proactive in what needed to be built. So just like that, we depended on our customer input only. [03:59] There was a lot of lack of design research because we were only building what our customers were saying and what we thought would be easier for them and how to stick that into our platform and get them from A to B. We were not conducting enough surveys also, so it was just based on the phone calls and the Zoom conversations that we were having. Engineers were stressed out. There was not a lot of innovation going on [04:19] and they didn't know what to build next because everything was kind of on the go. Here's what we have to build to make our customers happy. Our sales and product teams were unable to share the value. And most importantly, there was a difference in that thinking that product and engineering were really that simple. Most teams I don't want to speak for everyone here, but people think construct a road map and that engineering means bring that road [04:46] map to life. It is not that case. It is not that case at all. There is so much work that goes into building a road map and there's so much work that goes into bringing that road map to life. So we've dealt with our PMs also thinking that, oh, I built a roadmap. Here's what I have for the next twelve months. This is all the features that I want launched, one feature every single month. And the [05:07] engineers are like, what the heck is this? Like, how can we make that happen? There's a lot of technical debt to think about, etcetera. Some of the lessons that we learned was that we need a clear product strategy and company vision, which I will get to in a little bit, communication channel between product and engineering, and all hands on deck, especially in the early stage. Symba's only at 20 employees right now, so we did get our [05:30] CEO, our senior account executive, our CMO, our marketing leaders to also come on deck and provide insights to help take our product to the next level. [05:42] So, how are we gonna get to the alignment? How are [05:45] >> we gonna evaluate some of the [05:46] bottlenecks and understand the signals and act fast? So, [05:52] what what is the bottleneck and how to spot some of these signals? So thinking that product versus engineering is really that simple is going to be one of the first causes of a bottleneck. The lack of new features being pushed to production, which means that there's no increase in revenue or no customers that are wanting to come because of the lack of innovation, is also a good indicator that there is a problem going on. There's also [06:15] very little trust between the product and engineering teams and lots of excuses and blame and finger pointing. So, the product team is they want to establish a list of projects, aka the roadmap, and they're responsible for working with various stakeholders. So, we got to get the sales and the marketing into play as well. But engineers on the other hand have to bring this roadmap to life. And they're the ones that build the stuff that works, but [06:41] they not only have to think about what individual projects they have to work on, they also have to keep in mind the technical debt. And sometimes there's delays that happen, and it causes a domino effect, and it's not as easy as just putting duct tape and a Band Aid onto the problem and moving on to the next one. So, there's a lot of tension coming in, and this is what helped our team understand that there was [07:02] a bottleneck because we were not delivering features and there was no clear understanding between product engineering on what we were trying to sell and how to be innovative. [07:13] So, this happened because our product leaders were throwing requirements over the wall and treating our engineering team like a feature factory. Like I said, one feature a month for the next twelve months, we need this. This is it. There's no understanding of why features are being built. Product team was also canceling projects without any prior indication because of some of the KPIs that weren't being met, and engineering teams continuously missed delivery dates without worrying that may [07:39] have happened due to other delays. So there was definitely an imbalance here. We started to notice a high frequency of different incidents, developer burnout because they were trying to churn features while working all around the clock, and extensive low quality feature list that customers were quickly abandoning. Again, these are big indicators that there is no alignment between the product and engineering team. So I'm gonna jump into how we made it sustainable. So we started off in [08:09] 2022 in building a strategy of like what exactly is the value of symba and how are we breaking apart our different features and what it's providing to our customers. We built a value circle. It's really helpful to kind of put together your useful features, how it's going to cause stickiness for the users, what type of results it's going to deliver, and how we're going to visualize our mission as well as showcase it in the product. We [08:39] had a giant Asana board. So, we created a lot of different tasks for a lot of different leaders. What kind of interviews they had to do with our different customers. Keep track of all of that. We recorded everything in Gong. We shared it with our engineering team. We created a list of all of the features, output from our calls. We created surveys and got a lot of input from our surveys. We also created presentations to share [09:06] with our customers. We did feature request validation to be able to rank different features. And now we have a product roadmap for the next year. And this is what we came to in the last six months. [09:21] And I will talk about now how we got there. So [09:28] it took an all hands on deck. And by the way, I'm happy to share the templates that we created. So all of the ways that we thought about our product strategy, how we conducted interviews, who had to do the interviews, the types of questions we asked in the interviews. I'm happy to share all of that and you can definitely connect with me on that later. So we basically got all hands on deck until necessary. So we [09:51] had to have our sales and product leader our sales leaders conducting really informative sales conversations when we were talking to new business opportunities. So really getting their input on what their pain points were, what they were looking to solve, and what they needed. We didn't really talk about what we offered in symba until we heard what exactly they needed. Biggest lesson learned was we also fostered empathy, and we lowered the ego of the product and engineering [10:19] team. Something I want to talk about this year is that like engineers have to feel that they're building a product that supports that they're building a product and product needs to support that with data. Overcommunication is really important as to why a feature needs to be developed and it has to be there because only when the engineers understand the value of the product that they're building, then they will be able to build it with empathy and [10:46] understand what the users are going through. So that was a big surprise for us was that before and originally what we were doing was that we were giving our engineers just designs and telling them whip out these features in the next six weeks because we need them, our customer needs them by this date. But instead, we actually sat down with them, we shared them the Gong recordings of the interviews that we were conducting. They heard from [11:08] those users or the potential customers firsthand that we need this because it's going to help us solve x, y, z. And when they started to understand that there's actually a need for this feature that they're building, that's when they got more excited about it, and that helped them bring the entire team to alignment. We also depending on what stage you're at, you also and evaluating the resources that you have available, it's also important to understand to [11:34] it's important to understand to what extent do you want a certain feature to be built. Is it allowed for the engineers to create a simplified version in terms of the design so long as their customer is able to do or able to succeed in the original mission of that feature as well as get to A to B? But what kind of tradeoffs are there? And is it okay to get the feature faster at users'hands to [11:57] be able to collect feedback earlier rather than later? So, these are also some decisions that we had to make. The product team was working on creating designs and creating the different features, which we handed off to engineering. But engineering was given the freedom to think about how they could simplify that feature as long as you were able to deliver the same value. That also allowed them to think that they had more power in their hands and [12:19] that they could build smartly rather than just build what was given to them. We also had to spend a lot of time thinking about how we prioritize features. What I noticed from my team is that we always had to think two steps ahead. So, when we were working on the designs for feature number two, we already thought about what was going to come next and for feature number three. And because of that, our engineers got excited [12:43] knowing that they were building something but they had another feature that was up for them to build right after. So this also gave them kind of the mental energy that we need to build it faster because we have another feature waiting for us to build. We're really excited about that feature too. So it allowed them to speed things up. And it got them excited and it's smart because they can also think about the different dependencies as [13:05] they build new features. So, fostering empathy and lowering the ego was really just the biggest or the biggest thing, lesson learned that lesson that we learned. And it was very surprising because only when there was empathy coming from both sides, product and engineering, that's when we had a lot of alignment. So, I can confidently say that the roadmap that I just showed you for the next twelve months, we have been hitting all of our goals so [13:34] far in the last four months. We are on track to hit and produce all of our next features and launch them to production. Some of these and because of these lessons that are learned and the template templates that we created and the strategy that we worked to do, symba 2.0, we're we have been able to get there. So, [13:55] yeah. So I spoke about our journey. What is alignment? How do we get there? And how we can make it sustainable. Thank you. Does [14:09] anyone have any questions? Yes. How we set deadlines? [14:15] Great question. [14:17] >> Question was how does how does she set deadlines? How do yes. Sorry. [14:20] >> Yes. [14:20] How do you set [14:21] >> One of things with recording. [14:22] I have time for q and a. [14:25] >> Right? Yeah. [14:27] Okay. Cool. [14:29] >> Marco, how do you set deadlines? [14:31] Are these deadlines for when the product team has to have the designs ready or when the feature has to be launched to production? [14:47] >> So [14:50] the person in the middle who is the person so we've dealt with product managers who have not had any technical coding experience in the sense that they don't understand how long it takes to build certain features or don't know their product inside and out. I'm the CTO. I was the first person on the team to develop their product. And I've been able to keep my hands really dirty in development, so I know kind of how long [15:12] something can take and can think about the architecture. When I wasn't a part of those decisions in the last year, it was really hard for the product team to think about deadlines. So they would actually rely on engineering, show them the designs and say, hey, can you come back to me within week and let us know how long this would take. If it was falling [15:32] in between the right deadlines and the product team was happy, sometimes we also miss those deadlines because there were delays that came about or they overestimated the deadline or sorry. They thought that it would take too much longer and that was the case because there was too much work and then they would have to simplify the feature to be able to get it by the time that the product team wanted it to be. So I would [15:52] say that the most helpful part was me coming in and becoming more involved and understanding earlier on with product team that, hey, if you add this portion, if you want to add this feature, then it's going to extend it by four weeks. But if you don't want to add it, then we can get it launched in the next six to eight weeks. [16:09] You always have to keep a buffer in deadlines. And the reality is that development is proportionate to how many hours engineering team is putting on. Right? But it's not sustainable for them to work twenty four hours around the clock. But it has been the case for us where when things are getting really tight to the deadline, you just have to ask the engineering team, can you stay on for the extra few hours? Can you, you know, [16:32] keep coding to get the features out? And that's how we've been able to meet some of the deadlines. But the best part is really early on when you're doing the designs and you're about to hand it off to engineering, get a good sense of what that deadline would be, and then let the engineering team work with you to alter the designs if it's not fitting within the right deadline. Does that answer your question? Cool. [16:57] >> Hello, Ellen. Looks like that's all we have for q and a. Feel free to connect with Nikita on LinkedIn as well as the email. But if we could give a round of applause for Nikita. [17:06] Thank you.