Symba Revenue (2024)

hi everyone I'm Nikita Gupta thank you for the introduction um I'm the co-founder and CTO of Simba not for The Lion King but for symbiotic relationships um this is a very timely topic for us to talk about for me to talk about personally because at Simba we just went through a whole new product revamp in the last 12 months so I've got some insights to share um we'll share kind of like what I found surprising especially with dealing 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 a actual product team that is separate from their engineering team with product leaders PMS product engineers right who here gets to wear multiple hats and kind of be a PM as well as a technical leader too nice yeah so we're kind of ranging 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 um so over the next 20 minutes we'll talk 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 the hard lessons that we learned I want to 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 cool so we'll start with alignment um and we'll start off like I said with Simba's product Journey what didn't work and some of the lessons learned so right now if you go on Simba'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 early Talent from program acceptance to alumni status and track important program and Di data in one place so this has taken a few years to get to and we've been through kind of a crazy journey in 2019 we built a product that really wasn't a painkiller um just to give everyone context Simba 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 desperate times called for desperate measures and we then became a painkiller 2021 we kind of cruise 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 um to be completely transparent we struggled a lot with product in 2022 which is why it's really timely for me to talk about this and how we were able to maximize um 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 Simba since day one so even with working with different time differences and having our product team marketing team Business Development sales in 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 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 and what needed to be built um so just like that we depended on our customer input only 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's just based on the phone calls and the zoom conversations that we were having um Engineers were stressed out there was not a lot of innovation going on 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 um 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 um I don't want to speak for everyone here but people think that product means construct a road map and that engineering means bring that road map to life it is not that case it is not the case at all there's so much work that goes into building a roadmap 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 road map here's what I have for the next 12 months this is all the features that I want launched one feature every single month and the 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 Etc so some of the lessons that we learned was that we need a clear product strategy um 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 sema's only at 20 employees right now so we did get our 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 so how are we going to get to the alignment how are we going to evaluate some of the bottlenecks and understand the signals and act fast so um what are 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 very little trust between the product and Engineering teams and lots of excuses and blame and finger-pointing so the product team is um they're 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 they not only have to think about what individual projects they have to work about work on they also have to keep in mind the technical debt and sometimes there's delays that happen and it causes the 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 a bottleneck because we were not delivering features and there was no clear understanding between product and engineering and what we were trying to sell and how to be innovative 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 12 months we need this this is it there's no understanding of why features were being built um 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 warning that may had 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 lists that customers were quickly abandoning again these are Big indicators that there is no alignment between the product and engineering team so I'm going to jump into how we made it sustainable so we start off in 2022 in building a strategy of like what exactly is the value of Simba and how are we breaking apart our different features and what is providing to our customers we built a value Circle it's really helpful to kind of put together um 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 had a giant asada board so he's created a lot of different tasks for a lot of different leaders um 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 with our customers we did request 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 and I will talk about now how we got there so um 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 um and you can definitely connect with me on that later so we basically got all hands on deck until necessary so we had to have our sales and product leader our sales leaders conducting um really informative sales conversations when we were talking to new business opportunities so really getting their input on what their exact pain points were what they were looking to solve and kind of like what they needed we didn't really talk about what we offered in Simba until we heard what exactly they needed biggest lesson learned was we also fostered empathy um and we lowered the ego of the product and engineering team um something I want to talk about this here is that like Engineers have to feel that they're building a product that support um that they're building a product and product needs to support that with data over communication is really important as to why a feature needs to be developed and then 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 empathy and 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 gone recordings of the interviews that we were conducting they heard from those users or the potential customers firsthand that we need this because it's going to help us solve XYZ and when they start 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 too it's important to understand to what extent 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 customers able to do or are able to succeed in the original Mission of that feature as well as get to A to B but what kind of trade-offs are there and is it okay to get the feature faster at user's hand to be able to collect feedback earlier rather than later so these are also some decisions that we had to make that 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 we were able to deliver the same value that also allowed them to think that they had more power in their hands and 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 for 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 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 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 they build new features so fostering empathy and lowering the ego was really just the biggest surprise um 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 from product and Engineering that's when we had a lot of alignment so I can confidently say that the road map that I just showed you for the next 12 months we have been hitting all of our goals so far in the last four months we are on track to hit um and produce all of our next features and launch them to production and some of these and because of these lessons that are learned and the templates that we created and the strategy that we worked to do Simba 2.0 where we have been able to get there so um yeah so I spoke about our journey what is alignment how do we get there and how we can make it sustainable thank you [Applause] does anyone have any questions yes how do we set deadlines great question um how does she set deadlines how do you yes sorry yes how do you said I have time for Q a right okay cool have you said Marco how do you set deadlines are these deadlines for when the product team has to have the designs ready or when the feature has to be launched to production so 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 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 that they would actually rely on engineering show them the designs and say hey can you come back to me within a week and let us know how long this would take if it was under like if it was falling 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 overest debated 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 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 um you always have to keep a buffer in deadlines um and the reality is is that development is proportionate to how many hours engineering team is putting on right but it's not sustainable for them to work 24 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 keep coding to get the features out and that's how we've been able to meet some of the deadlines so but the best part is is like really early on when you're doing the designs and you're about to hand it off to engineering get like 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 looks like that's all we have for Q a feel free to connect with Nikita McDon as well as the email but we can give a round of applause thank you [Applause]