SUMMARY OF THE PODCAST WITH GIREESH SAHUKAR
Gireesh Sahukar, Master B2B executive adviser and former VP at commercetools and Dawn Foods, shares insider tips for buying software. He emphasizes looking beyond features to evaluate vendor stability, financial health of specific business units, cloud infrastructure dependencies, and realistic roadmap delivery capabilities. Key advice includes finding references the vendor doesn’t provide, understanding SLAs and business continuity plans, verifying comparable customer success stories, and comparing past roadmap promises against actual delivery to assess future performance.
FAQ
Who is Gireesh Sahukar and why is his perspective valuable?
Gireesh is a Master B2B executive adviser who has worked on multiple sides of the software industry—as a VP of implementation at commercetools (an e-commerce platform vendor), VP of digital at Dawn Foods (practitioner side), and has experience with systems integrators. He’s also a Mach Alliance ambassador emeritus with technical expertise, giving him unique insight into both vendor and buyer perspectives.
What’s the biggest mistake companies make when evaluating software vendors?
Companies get too focused on features and functions, treating the product as if it’s the entire company. They fail to look at critical factors like vendor stability, management turnover, cloud infrastructure dependencies, financial health of specific business units, and actual delivery track records versus promises.
Why is understanding cloud infrastructure and SLAs important?
Since most software today is cloud-delivered, you need to understand what happens when third-party providers like AWS or Azure experience outages. Questions to ask include: What are the SLAs? What’s the recovery time? Does their downtime mean your site goes down? You need business continuity plans for these scenarios before they happen, not after.
What should companies know about a vendor’s data processing agreements (DPAs)?
Every SaaS business must disclose through their DPA who their third-party providers are and for what purposes they use them. This isn’t secret information—it’s contractual. Understanding the vendor’s ecosystem of partners and dependencies is critical since your online experience now depends on multiple interconnected services.
How do you properly evaluate a vendor’s financial performance?
Don’t just look at total company revenue. If you’re buying from one business unit within a large corporation, understand that specific unit’s performance—their trailing 12-month results and projected next 12-month revenues. Public companies often disclose this in annual statements. If the numbers don’t add up (2+2 doesn’t equal 4), that’s a red flag.
Why should you seek out references the vendor doesn’t provide?
Vendors will always give you their best, happiest customers as references. You need to find customers in the “average,” “unhappy,” or “churned” categories to understand potential problems. Use LinkedIn and your network to reach out to companies using the software who weren’t on the vendor’s reference list. Ask churned customers why they left.
What questions should you ask about comparable customers?
Ask about customers similar to your company size and industry. If you’re an enterprise B2B company, success stories from small mom-and-pop shops aren’t relevant. Understanding how the vendor performs with comparable customers gives you realistic expectations for your own implementation and support experience.
How can you tell if a vendor’s roadmap is realistic?
Look at what they’ve actually delivered in the past year versus what they’re promising for the next quarter. If past delivery was “an inch deep” but future promises are “a mile long,” ask what’s changed—did they triple their engineering capacity? Engineering teams typically grow incrementally, not exponentially. Past delivery volume is the best predictor of future delivery.
What’s the screenshot technique for evaluating roadmaps?
Take screenshots of the roadmap the vendor shares during your evaluation. A year later, pull out those screenshots and compare them to the current roadmap. This shows you whether they delivered on past promises or if they’re presenting essentially the same “wish list” year after year. Gireesh recommends buyers take accountability by doing this comparison.
How does the financial services disclaimer apply to software buying?
Ironically, while financial services say “past performance is not a guarantee of future returns,” in software buying, past performance IS a guarantee of future returns. What a vendor has delivered historically is the best indicator of what they’ll deliver going forward. Their track record matters more than their promises.
What “day two” activities do practitioners often neglect?
Beyond initial feature evaluation, companies need to plan for operational realities: What happens during outages? What’s the recovery path? Do you have business continuity plans? These aren’t day-one concerns but week-two and month-two activities that are better addressed early rather than during an actual crisis.
What should you look for regarding vendor management turnover?
Be wary of excuses like “management churn is normal in tech.” Ask specific questions: Why is the CEO no longer there? Why was the entire product team let go? Significant management changes, especially in leadership or product roles, can signal deeper problems with company direction, strategy, or stability.
TRANSCRIPT:
Brian: Welcome everyone to Friday 15 with Master B2B. We’re going to be talking about software buying tips and tricks from an insider – Gireesh “The Silencer” Sahukar. Gireesh has is a living example of someone who’s been on both sides of the fence. He’s a now a Master B2B executive adviser. Welcome to the team there, Gireesh. You were a VP of implementation and customer services at commercetools, a leading e-commerce platform. Prior to that, VP of digital at Dawn Foods. You’re a ambassador, I guess, emeritus, right? The Mach Alliance. You worked at Keurig and Dr. Pepper. Gireesh, welcome. Tell us a little bit about yourself and your journey.
Gireesh: Andy, Brian great great great to be here again. Great to be back with the Master B2B cohort. Looking forward to having a lot of great conversations with the master B2B folks. As you mentioned I’m one of the newly minted Nexus advisors just starting out on a new journey here.
Andy: So we wanted to bring you on Gireesh because you’ve had a lot of different experiences. You’ve been on the vendor side, you’ve been on the SI side, you’ve been in the e-commerce space, the search space, been a practitioner in multiple companies, and you have a technical background. So, we thought this is like a really good opportunity, especially since you’re now one of our executive advisers, to pick your brain about what are the mistakes that you see companies make and what are the opportunities that they miss when they’re buying software. And so, we want to go through a couple of slides with you and sort of tell you what we think people do wrong and then get your thoughts on what they should be doing, right?
Brian: Yeah, there’s so much confusion around this now, Gireesh, because you’ve had all this composable stuff come out. AI is is further confusing and as a business leader in particular and you’ve crossed you cross business and IT so magnificently that I we think that you can really contribute. So let’s go through some of those to Andy’s point let’s go through some of those points. Well here’s the first one Andy you want to set us up and then let’s ask you.
Andy: Yeah. And I found this to be the case myself that companies when they’re evaluating software vendors, they get stuck on the product and they think the product is the entire company and it really isn’t. So I always say don’t settle for a long list of features and functions. the excuse that management churn is normal in tech. That’s one we hear a lot. Yeah. Why is the CEO no longer here? Well, it’s just management churn. Or how come the entire product team was let go? Oh, it’s management churn. and then of course recently the statement that we are committed to AI. , what exactly does that mean? Right? It’s like when a plane crashes and they say, “Well, safety is the number one priority.” Well, apparently it wasn’t right before the plane went down. So anyway, that’s sort of what we see on our end, but want to talk to a little bit about what you think companies should be doing instead or in addition to those things.
Gireesh: Andy, you said don’t look at features and functions. I think that’s a day one requirement right when when you’re launching a new platform with a new platform you need to know what they have but beyond that once what they have what’s next with a lot of almost every software nowadays being a cloud delivered software you need to understand the SLAs. You need to understand what’s their availability is like and when they go down what is their recovery time recovery path what’s that outage mean to you and your own front end is is your site down? If a third party provider is down, those kind of things that you need to understand and you need to have a contingency plan. You need to have a business continuity plan for those things. And , those are day two activities. Those are week two, month two kind of activities that most practitioners don’t really pay attention to when buying software. You need to have a plan and it’s better to have that plan early than have to endure a AWS outage like last week or an Azure outage. I think that was yesterday. So these are if an AWS goes out what is your what is your plan to be up and running? Those are key questions.
Andy: It actually also stresses the point that you need to have an assessment of the ecosystem these people operate in because as you pointed out when it was software that you installed behind a firewall that was one thing but now that there’s a dependency on cloud compute providers other companies that are building your online experience your mobile experience your AEO GEO experience you need to know not just who the software company is but also who the partners they have and right what partners do they still need right and these things are not secret right every every SASS business has to tell you through their DPA data processing agreement who are the providers they use and for what purpose so you will know contractually who you’re dealing with and who else they’re they’re using. So another big one that you’ve talked about when we’ve chatted about this is this idea of understanding the financial performance of the company right it seems like whenever companies report their financial performance to potential co companies customers they say things like oh here’s our total company revenue and here’s how many years we’ve been in business and here are what I call the macro metrics which is here are here’s how we deal with all of our customers. And you’ve contended that that can hide a lot of things, right? It can hide business business unit performance. You only care about comparable customers, right? If you’re an enterprise company, do you really care that these guys are serving a mom and pop shop in their basement really well? Yeah. So, what do people need to ask here?
Gireesh: So, think about a large software company, right? We talked about some of the other providers that released their earnings this week. But when you unpack that if you’re buying services from only one small business unit inside of their gigantic corporation, you need to understand how that small business unit you’re actually doing business with. What is their track record of performance? what is their trailing 12-month performance and their next 12-month projected revenues, right? They are more than happy to tell you in any kind of RFI RFP process under NDA. They’re willing to share these things. Public companies generally give those in their annual statements. So they’re public. You can look them up. so do that diligence, do that research, right? If 2 plus two should add up to four, sometimes it doesn’t and that’s when you raise the flag. And then you also want to think about not just the customers that they won also some of the customers that they’ve lost and see if you can talk to them and understand why did they say no to a provider you may be saying yes to – what were their criteria. When I was at Dawn, we actually did this and asked a bunch of other B2B companies why they chose the software they chose versus the ones that we were looking at. And many of them gave us really candid and good honest advice about what we should be looking at and thinking about when we were going to pick the software we’re picking and how we should be operating on that.
Brian: I was going to say one of the things that I’ve always found valuable is finding references in companies that the software provider didn’t give us right when I was a practitioner. So who else is using them that they’re not they don’t want to maybe don’t want us to talk to, right? So, there’s a little bit of that.
Gireesh: When you just ask your prospective vendor for references, they’re going to give you their best customers, right? So you have to go find the customers that are using but they’re not extremely happy with or customers that are unhappy and have left and have churned. so you have to dig through and find out who’s in that sort of average or unhappy or exited buckets and try to figure out if you can and if your if your network is big enough to go find them and you can reach out to a lot of people on LinkedIn nowadays. it. , LinkedIn has made it easy and you can go get that kind of advice.
Andy: So since we talked about references, which actually I think that’s great. Let’s talk about the last area here for today, which is the road map. This is one of my favorites because whenever I talk to companies and they brief me, you wouldn’t believe some of the crap I hear about road maps. And so I just sort of throw these in there and I know you and I talked about this like don’t settle for what they tell you is on the road map or what they’re excited about. I don’t care what you’re excited about. What are you actually going to deliver? And then don’t settle for what customers are asking for. That’s the other thing I often hear. It’s like oh well this is our roadmap. Customers are asking for this. None of this matters right unless they can actually demonstrate that they’ve delivered. So what’s your advice for them on that?
Gireesh: When you go to these briefings you get the road map, the future forward of future looking road map and the past deliveries, the the past year delivery is an inch deep, but the road map for a quarter from now is a mile long, right? So, you you have to ask yourself, okay, you delivered an inch, how are you going to deliver a mile one quarter later? What have you done in that intervening period to be able to make that enormous leap? Sometimes that is true. They’ve added a whole lot of engineering teams and staff and capacity. That is possible. But more often than not that is not true, right? The engineering capacity almost incrementally goes up. It doesn’t go triple quadruple in one quarter. That is rare unless you’re dealing with a startup that went from seed to series A or series B. But in general what they delivered a quarter ago, two quarters ago is going to be the amount of features and capabilities they will deliver in the quarter coming up or in the quarter after. Right. So anything beyond an inch deep is probably not realistic. So you have to evaluate that and be realistic.
Andy: Yeah. past this prologue, right? I mean, what they’ve delivered in the past. And I often say too, Your road map is not a wish list. It’s a development plan. And so, I’ve seen people just load up on all the things they want to do with no real plan to deliver. And to your point with no track record of actually having delivered any of that stuff. And so, I know I won’t name names, but I’ve talked to companies in the last several years where the road map is almost exactly the same as it was the year before. And honestly pretty much the year before that. Wow. One more thing and I’m like wait a minute this is the same road map. So either you guys do a terrible job of road mapping or you can’t deliver anything.
Gireesh: Yeah. When I was selecting and implementing software what I would do is I would take screenshots of the road map they shared and I would go back to those as I’m talking a year later and said here’s what you promised a year ago. Here’s the road map that you’re presenting today. Right. and , we’re if we’re buyers, we we have to take some accountability in that, right? And say this is what I promised. This is what I planned and this is what you’re now promising. So, your promises are matching up or not matching up. You have two pictures side by side and you can do that yourself. Right? This is one time where that you hear the statement on all of the financial services past performance is not guarantee of future returns. In this case past performance is a guarantee of future returns.
