Product Stories
The journey of becoming a product manager and building software to improve your industry with Shruti Bansal
Summary
In this episode of Product Stories, Victor Purolnik talks to Shruti Bansal, Principal Product Manager at Kpler. Shruti shares her journey of becoming a product manager to build software from scratch that improves commodity trading in the freight industry.
Episode Highlights/Topics:
- Before/After Kpler: From end user building small internal tools to product manager
- Data Sources/Providers: To make sense of data, you must be comfortable with tech
- New Product, New Industry: How Shruti brought ideas, thoughts, problems to solve
- Customer Conversations: Don’t use buzzwords, be friendly, and make their lives better
- Minimum Viable Product: Systemize feedback, identify gaps, and prioritize requirements
- Product Development Risks: Put quality checks in place for users to rely on products
- Product Management: Something will be missed, go early to market to get feedback
- Being a Manager: Be open to learning and honest about what you know or not
- Prioritization/Digitization: Learn to say, ‘no,’ due to limited resources, unlimited requests
- Product Management Tips: Find solutions, understand the why, and make mistakes
Another video you might like
Building products faster by mastering the art of Product Management
Resources/Links:
Read the transcript:
Victor [00:15] Welcome back, everyone. Today’s guest is Shruti Bansal, principal product manager at Kpler. In this episode, she will share with us her journey of becoming a product manager to build software to improve the commodity trading in the freight industry. It’s a very, very interesting topic. Shruti welcome to the show.
Shruti [00:32] Thank you, Victor. Thank you for having me.
Victor [00:36] Yeah, absolutely. You have basically become a product manager to build a fairly large piece of software from scratch. That is a super exciting story. Something a lot of our listeners will like to understand more about. Why don’t you give us a little background and how you got there.
Shruti[ 00:56] Yeah, I’m Shruti. I come originally from India born and brought up there. For now, I’ve had almost 12 years of experience working in the commodities and shipping space. I look at my career split into parts before and after Kpler. Before Kpler, I was working within commodities, and shipping all over the world, I’ve worked in places like Singapore, UAE, South Africa, Germany, as well. Right now I’m back in UAE, I worked as a analyst and trader on the paper market press, primarily. I got introduced to Kpler in my previous company on a trading floor as an end user. I think from the get go, I had high admiration for what Kpler was doing. Being in my own space for 10 years, I was also working on building some small solutions to cater internally to my desk and myself.
That’s when I saw the opportunity to kind of start transitioning. That’s what I’ve been doing for the last two years being the principal product manager at Kpler, for one of their product offerings [inaudible 02:03] we took one year to develop from 2019 to 2020, to develop the product. Then it has been launched for over a year now. It has been very positively received by the industry. Extremely happy about that.
Victor [02:19] That’s awesome. That’s a big success. When you said you were building small internal tools, within your previous job, what did that look like? How did you learn to build software within your company?
Shruti [02:33] I always had an inclination towards tech, because when I started working, we were using a VBA Excel files and PDFs and copy pasting was a nightmare. Data was just growing in the shipping space at the moment. Suddenly, we saw this big influx of data. I knew like you have to be comfortable with tech to be able to make sense of the data at hand. My journey with development and tech started there. Initially, it was just me trying to do things to make my own life simple. From there, it gradually went on to becoming building this internal database. Again, at my previous company, which was an energy utility, we had 50 data providers, data sources, and data was coming from all directions. First and foremost, we just wanted to create a database. We had allocated, we had some developers allocated to us.
Basically, I had to learn the language, try to make them understand as an end user, then to help them in scoping, building, validating those kinds of things.
Victor [03:34] Then you obviously, as they say, in every spreadsheet, there’s a SaaS business. I guess you saw what could be done, what could be very useful for your industry. Then how did that go with Kpler? I understand that you’ve built a new product basically for a new industry. How did that look like? Did you come with your ideas? Or was there a global hypothesis?
Shruti [03:59] It was a mix of both. I had a home advantage, like I had my own baggage that I came back to Kpler’s telling them guys, this is the problems I have been seeing for the last 10 years. But obviously, it was still limited in its perspective and scope, because it was just me and my exposure so far. When I joined Kpler in 2019, the company was already five years old, and they have collected a lot of feedback over time. I did spend a lot of time initially to sort through that feedback to align that feedback with my own thoughts. Again, a philosophy that I try to follow, we tried to follow at Kpler is to try and answer before you develop a product, why do you want to develop it. For us to figure out what are we trying to solve and why was a great exercise that helps us stay focused both in the short term and long term. Initially, I came I had the feedback. We also did some validation through product advisory calls through doing some calls with my industry contacts, doing some questions, some mock ups, those kinds of things.
That’s when the scoping design and development began.
Victor [05:13] Mostly from customer conversations. Do you have any advice for people trying to do the same thing at this point? Did you find anything difficult or any specific way to ask questions or what to avoid?
Shruti [05:28] I think genuinely, what I’ve experienced is clients are very friendly, and they are more than happy to share with you the list of their requirements. I think one interesting learning was 90% of the time, when you speak to someone, they have this big list of requirements, and that’s very easy to follow. But 10% of the time, it’s not necessarily because they want to hide it, but they’re not able to communicate. You have to pick up on those hidden requirements. This is what we try to do. We organize a product advisory session, where we get in touch with some of our friendly clients or allies, we set up a one hour call with them. We ask them to show us okay, of course, you’re going to tell us what do you need, but shows your work, day to day workflow. What do you do? What does a typical day look like, for you? In those sessions, when they’re showing us what do they do be like, okay, maybe this is something that we can try and resolve. That’s when we go back, we take the risk, we develop it, we deliver it, and a lot of times it’s positively received, sometimes it’s not. But that’s just part of product development.
I don’t think there are any bad questions or wrong questions, I genuinely believe in that. As long as you’re trying. I think one tip, I would say on one recommendation, if I can, is, whenever we work with tech, sometimes words are used, like disruption or displacement, displacing human workflows and capital, I think that’s when people can get offended. If somehow, like tomorrow, if someone calls me and tells me I’m going to develop a product that’s going to disrupt your workflow and potentially make you redundant. I think that’s not going to be well received. But I think besides that, so don’t use these buzzwords, and try and be friendly and see how you can make the life better.
Victor [07:17] That makes a lot of sense. How many conversations have you had roughly? Do you recall?
Shruti [07:25] Oh, too many. Again, I like talking to clients, I like talking to people, I like getting their feedback. I think, especially when the product was at the nascent stage, freight is a complicated market. I don’t want to go into details why it’s complicated, but it needs a certain level of expertise. That’s why I had to interact a lot, I would say, maybe three to four calls, including demos and feedback sessions in a week, is where I started at. Now, definitely, I have incorporated that knowledge within Kpler. There are people who can go and talk about these topics. Now it’s getting less and less frequent. But still the product advisory we try to do it as often as we can.
Victor [08:10] That makes sense. Now you’ve probably had, like, I can just imagine that because whenever I have calls I have especially calls like that pages of notes. You must have had books written filled with notes. How do you make sense of that when planning out a product in the beginning? Because there must also be conflicting views, there must be different requirements, you need to find this core of a minimum viable product. How did that go for you?
Shruti [08:40] Again, it tied up very nicely with why we want to build, and it was about identifying where the gap is. If I give you the example of how I went about it, we saw in the freight analytics, the market analytics, there were a lot of tools and softwares available for executing whatever trading decision or whatever your workflow is. But there was a tool lacking for this strategy and planning and being able to help you make those decisions. That’s where we identified the gap. That’s where we went for. We also did like competition, landscaping, where we saw a lot of our competitors were providing, let’s say, if A plus B equals C, they were providing B and not A. I think that identification is very critical. Of course, we use tools for feedback management. I do note down everything that I have over the pen and people during the call.
But then we follow up with practice as soon as the call is done. There is a tool called harvester that we use, and we plug in every feedback. Then as product team we go through that feedback on a weekly basis. We’ve sorted out in terms of discoveries, okay. This is a common requirement. We do put attributes to them. For example, the size of the company, the impact that the solution will have, not just on this user, but overall in the industry and overall for us as a company, things like how much investment is needed, not just in revenue, not just in the cost, but the time and resources that we have those attributes that we assign to each and every discovery or topic. That helps lets us prioritize things and put some kind of quantitative analysis to a very qualitative feedback that we get.
Victor [10:32] Now you have that feedback that you’ve systematized put in order put in structure, discussed, you’ve come up with the common denominator of what you actually want to build. What was your development setup? What was your product team essentially, in the beginning? What is it now?
Shruti [10:51] In the beginning, it was a lot of strategy calls for the top management, presenting them the business case, presenting them a plan of action for the next 12 months. This is where a lot of scoping work was done. Okay what do we want to do, how exactly you want to do it, we split it into development phases. This is where the minimum viable product also comes in. Initially, a lot of that was done by me with the help of the data and people I had. After that, then there is a specific list of what data and developers do we need. Once we have those resources allocated, that’s when we try to split the entire roadmap in different milestones. Every quarter, let’s say is a milestone. Let’s say we want to tackle topic A in Q1, then that is further split into sprints.
We have three sprints, four sprints every quarter. One sprint is three weeks. Then within that milestone, we break it down into small tasks, like story cards, and every sprint will have certain cards are located. That’s how we go about in development. Of course, a big part is also going early to the market. We are very agile like that. We do want to wait till the product is perfect. We believe in philosophy, that you make it work, you go get feedback, and then you keep refining it over time.
Victor [12:18] I guess there’s always a trade off, right? Because I’m not sure with your product, was there any risks with clients using an imperfect product making decisions, maybe with a bug or something? Was there any risk like that?
Shruti [12:32] There’s always a risk inherited in product development, that’s what I believe in. There are minimum quality checks that we put in place. We won’t just put anything in front of the clients. That’s why also Kpler kind of bring market experts. The first level of product that goes out, it’s still qualitatively much better than you’re not just putting anything and everything in front of clients, because you’re exactly like a trader, in our case, looking at this data, and if they make wrong decision, it can cost them millions. Once you lose that credibility with your clients, it’s very hard to gain it back. There are definitely quality checks in place. I mean, it’s not defined like okay, 80% or 70%, it’s very subjective, depending on the situation. But from our side, the way minimum viable product works is okay might not have all the 10 functionalities. We’ll put five out there. But those five will be at least quality wise, good enough for users to rely on it.
Victor [13:37] You said it took about a year to develop? Did you do any sneak peeks private public betas alphas beforehand? Or did you wait that year?
Shruti [13:49] No, no, we started doing alpha and beta access, again, with all our allies from the market. They give them early access, we give them extended trials, then we set up follow up calls with them. All of that definitely I think is very key. There are things. I mean, we are all humans at the end. I can do all my research. I can scope further, we can develop everything, but there’s always something that you’re gonna miss. It’s just part of product management that I’ve accepted. It’s good to go early to the market and get their feedback. Yeah, for sure.
Victor [14:25] Was there anything you’d call like the worst user feedback you ever received? or hypotheses that was just so bad? That it just wasn’t true? Did that happen?
Shruti [14:39] I have to think about that. I’m not trying to be snobby. But fortunately, like the product has been very well received, like, we work with clients for so long. I mean, yes, there are some on like off calls here and there. I don’t remember any bad feedback in that sense. I think the worst is I mean, I can do this on my own, why do I need your solution?
Victor [15:07] Yeah, of course, now let’s turn to product management in general. You went from being a trader, to also building a bit of software on the side to help you and your team work better to actually managing an entire product team. From what I hear you’ve done this by the book essentially, like very beautifully. How, how did you learn about product management? How did you go about that?
Shruti [15:37] It was a steep learning curve. I’ll be honest, before Kpler I had some exposure to product management, but there was nothing at risk. It’s my own company developers are internal. It doesn’t matter if it takes six months, 12 months. Honestly, it did not matter internally, it’s very different. When I first joined, it was intimidating to tackle deadlines to know that a company like Kpler in itself has been one of my favorite success stories like it’s organically grown, co founders from a small room, trying to find a solution and commodity markets from 2014, to where it has grown. To see like this is genuinely hard work, and they are putting their chips on you, it was intimidating. I did not have knowledge. I’ve not worked with sales before communications market, all those sort of things.
My learning has primarily been on the job. I was comfortable with risk being a trader in my previous role, there were some strategies that I applied, like, as a trader, I always told diversify your risk, don’t put all your eggs in one basket. I did something similar in product. I’m not gonna put all my developers and resources on the same kind of direction of products or diversify that. Or to try and learn more on the tech side of things like what is ETL RMS web server. Just be open to learning. Be honest about things you don’t know. I think people appreciate that a lot, instead of you trying to pretend you know everything. I’ve gone to developers and tell them, I don’t know, the most basic things, can you help me out.
As soon as you open up, I think people help you out. Same with sales and marketing and commercial, I think it’s just been a steep learning curve for me, I’m still learning to this day. That’s also why I love this job so much, because it pushed me out of my comfort zone. It taught me skills that I potentially would have not learned if I stayed where I was.
Victor [17:36] That’s great. I absolutely love that being honest and open, also just asking for help, right? Because that’s also true of what a product manager does not necessarily ask for help but understand where people are at and communicate with them. Being this gatekeeper to the backlog. What was the hardest part to learn for you?
Shruti [17:59] I think privatization and the service deployment is the hardest part. Prioritization, again, because you have to learn to say no, as a product manager, you can’t say yes to every request that you have, because you won’t end up anywhere. Prioritizing in that sense is very important, and the hardest to learn. Because doesn’t matter how much quantitative analysis you will always have this personal human bias, and it’s hard to get rid of. Those are the struggles I’ve had. Then I think, as an industry on its own, because digitization is so big now, we are genuinely suffering from an under supply of developers. We have limited resources, and unlimited requests. So how to prioritize what you want to build with the element of risk that you’re willing to take, and how to deploy the resources that you have on those development, I think has been the hardest or the part where I had to struggle the most.
Victor [19:03] That’s very true. I mean, we see it every day in the industry that there’s more and more need for developers, but there’s just that many, and good product manager and also a good designer working in product team like that. I mean, it trading in code is good is great, because the best thing you can show to a customer to try is a product, right? It’s much better than than just a mock up. But when developers are scarred, you need to find ways to iterate outside of code. At least try. That’s what a lot of people do. We’ve had great people on the show who were speaking about product management and also about design and how to apply that before even writing code. I guess that’s one of the strategies that we have to use more and more, because we just can’t build an infinite amount of things.
Shruti [20:00] Exactly, and your margin of error is very small, and your opportunity cost is so high, that it makes it very important to exactly what you’re saying, like have you’re not perfect, but nearly perfect mockups and design and then exactly where you’re going with the resources you have.
Victor [20:18] Do you have any tips and tricks for new product managers on what to learn? What’s the most important? Apart from prioritization I assume.
Shruti [20:29] For me, product management is about finding solutions. Focus on that. What are you trying to solve? Second goes back to why you’re doing what you’re doing. Learn to say no, again, part of prioritization. Don’t be afraid to make mistakes. I think that has also been a key learning, you can have everything prepared, you have a plan, everything is going perfectly, but you will make mistakes, you will break things, when you deploy something that will happen. I think that’s also one of the best ways you learn. Obviously, you will try to minimize your errors, but don’t be afraid to make them. One rule or mantra that I follow is over spec and under scope.
Always assume that you’re talking to a five year old when you’re doing your specifications. Be as elaborate in your specs as you can be, and always under scope. If you think you can develop 10 features in 10 months, just cut it down to seven. Just under scope it. When you think you have your roadmap ready, just trim it down by 20, 30%.
Victor [21:33] Yeah, that’s very true. Also about what you said, with not being afraid to make mistakes and to maybe go in the wrong direction once or twice, even though we all tried to figure it out at the customer interview stage. You say very well, and also that we need to tell the product team that what we’re building is not likely not going to be the perfect solution. Because when I’m so super sure that what I’m building is going to be the thing, everybody gets super pumped. But when we align everybody on, we’re just validating this. We’re trying this, but we may be doing something else tomorrow, I think there’s less of a frustration when things change after two months.
How do you cope with the responsibility of having to make the right product decisions? You already said and I think that’s very wise and very smart to not put all your eggs in one basket. But have you felt pressure on that part at any point in time?
Shruti [22:37] Yes, for sure. I mean, like I say you have kept like restrictions on capital. It’s not free flow. Also, I think it’s your moral responsibility to make wise decisions. Of course there is that pressure, like, are you making the right decision, but I think I’ve just been conditioned to it, being a trader. I’m sorry, I keep saying this again and again, but just to be accepting of the fact that yes, there is a risk, you have to deal with it. Sometimes you have to just take that leap of faith, you need to do your homework, you need to do your research. But after a certain point, you also need to just go ahead with it. I think if you have good scoping done, use your tools to not make 50 slides, that’s not what I’m saying. But have your arguments ready for your business case, have your execution risk ready, have your development like whatever resources you need the list ready so that you can always fall back on that and just give it your best shot. If in the end, it doesn’t work, it doesn’t work.
I can tell you, you will see so many products around you that have completely failed. Doesn’t matter big or small companies. It’s just everyone is trying to do their best. I think that’s what I try and remind myself again and again. If your intentions are right, I think you should be able to cope with the pressure.
Victor [23:59] Very, very wise words. Thank you so much. Shruti. Where can we find more about you and Kpler?
Shruti [24:06] Please go to our website. It’s kpler.com. On there, you can learn about the company, the co founders, what do we do in terms of tracking commodity markets and so on. What all products we offer, there’s also a possibility to get a free trial for the data that we have. I don’t know how many of the listeners would be interested in that. But if you are, please go ahead. You can also find us on LinkedIn, Twitter, and YouTube. On YouTube again, we post quite often some free resources like there are webinars done by our research team on market trends on oil and gas if you’re keen on that.
To find me, you can find me on LinkedIn by my name and you will see an oil tanker in my profile. That’s going to tell you that it’s me.
Victor [24:54] Thank you so much. This has been very insightful. Thanks for joining the show today.
Shruti [24:59] Thank you so much, Victor for having me.
Let’s share this article!
Other episodes you may like
Everything You Need to Know About Working With Software Development Agencies
The COMPLETE Guide to Hiring & Leading Your First 5 Developers | SaaS Academy
Overwhelmed SaaS Founder? Learn to Delegate Responsibility Strategically
How AI Could Potentially Kill Your SaaS Business
Learn to Guide Dev Teams: Your Monthly Advantage
Get the edge 1,500+ founders swear by. Once a month, access a power-packed mix of podcast wisdom, exclusive events, deep-dive content, and actionable tools.