Nigamanth has been part of the team that executed implementation for their first client and since then, the implementation for larger enterprise clients like Marico, ITC, Nestle, Tata, and more. In this freewheeling chat, he shares his early experiences, the implementation growth journey, and lessons along the way.
Let’s get started. (The conversation has been edited for brevity and clarity.)
I’ve been with Pando for two years — heading delivery for nearly two years, before transitioning into a Solutions role. My post-MBA experience of nearly six years has been in Supply Chain which is why I was excited to join Pando in the first place.
Pando is a freight management platform, or a Transport management Software in supply chain parlance. The logistical spends of our client companies are in the range of 10% of their revenues — up to 1000 crore. This means that up to 1000 crore of freight spend has been traditionally managed using spreadsheets and emails. Considering this scale of spend, you can imagine the amount of work. Also, the supply chain is external facing, so there are a lot of other stakeholders and companies interacting with the process.
This is where Pando comes in. Essentially, we digitize the supply chain for a company. In addition to freight management, we also offer additional optimization layers such as data analytics and network spread so they can leverage data to improve deliveries and efficiencies.
In the last two years, Pando has established the right product-market fit. We grew rather quickly — by enterprise standards — to 20 enterprise clients as of December 2020.
I think I'll use the analogy from the movie Kung Fu Panda and say that there is no secret to the secret ingredient.
If I had to think about it seriously, I think it helped that when I joined, I came with a fresh pair of eyes, so to speak — the freshness brought in the element of fundamental thinking. There was no baggage, so we learned what we did - ground up and with a common-sensical–thumb-rule approach. Only once we set down these processes, did we hire the next round of people. We consciously brought in a mix of talent — logistics people, implementation people, and people who have nothing to do with any of this directly.
I think because we were learning from scratch, we were a little unclear about the product we had and what we could promise. So we were not sure what if we were overselling, and didn’t even know what was easy to build, what added value to the customer, etc.
I think, at an early stage, when you don’t have too many processes — internal and for the client — managing client expectations correctly is key. There was the element of bridging towards what was promised to them in the sales deck — we had to assure them that we could and would build that out.
It is important to build comfort and trust with the client and thinking about what would add value to them.
Initially, we looked at it purely as an implementation exercise - getting the client live was the focus. After the first two implementations, we reoriented the team and our approach. We moved away from a project basis approach that focused only on timelines and delivery through a typical Blueprint > System Setup > Testing > Go-Live flow.
The two big learnings after the first two client implementations would be:
1. Focus on change management: When you go live with a product, it is a fundamental change in the way the user operates; it is a huge change for them.
This made us think about what we can do to make the go-live much smoother and ensure the client doesn’t come back with feedback later, or completely abandon the project later. We preempted this big change and created a system of 3-5 change management programs - run by Pando or the client. This also meant saying that we would not roll out our product to the end-user on go-live day 1, but effectively on day 1 after the blueprint exercise. This way people were used to the product for almost two months, so we don’t wait till UAT to get feedback
This focus on change management can be carried out through marketing or gamification. For instance, we create games that replicate scenarios - Say the fastest user to create 10 indents - etc, to build awareness and engagement.
2. Shift to a Value Delivery approach: At our end, we wanted to rethink how we tend to think of a client as out of our focus after go-live. We changed the name of our team from Customer Success and Implementation to Value Delivery. This brings a clear focus to the team.
At the blueprinting stage, we make sure to understand what the objective of our tool is by speaking to the CFO or buyer at the customer end - in our case the objective is mainly cost reduction. We ask them to share metrics and how they are currently faring on those metrics.
We then proactively measure these when we go live. We send out a monthly mailer (that we internally call an ROI document) to the client to ensure they see and realize value.
Doing that baseline and being transparent with the client is very important.
Yes, we charge for implementation. Most enterprise clients are used to this and willing to pay. We do not have a complicated system. We have different versions of various line items like “light” vs “heavy” touch across the spectrum, for instance, in training. We don’t “offer’ it to the client, we take a call based on the kind of organization — instead of confusing the customer with options. We end up picking from different tiers of implementation plans such as Gold or Silver, depending on the right fit for the customer.
We were two people handling two clients. Our third hire was six months later — and consciously so. The reason is that for the new resource to go from zero to one — where we were — would definitely either be a struggle for the employee or eat up our bandwidth.
We decided that a new hire should breeze through what we had already learned. We called these value delivery foundational activities and set these right before a new hire. Here’s what we did:
We also added a dedicated section for the client to add in their questions - in addition to these existing FAQs.
Great questions, I had these questions myself - since I didn’t come from an implementation background and we didn’t have a value delivery approach in the initial days.
In terms of frequency:
First, in SaaS customers need to know now what value they are deriving from our product. So, we send them these auto-captured metrics, say the freight cost moved via Pando, etc on a monthly basis. This is more of an assurance.
Second, these conversations, beyond upselling or cross-selling, keep us close to reality and help us build other things we can offer our next customer. For instance, with our client Marico, we had nearly 17 change requests even six months after go-live, and we worked on them because they would solve critical and urgent problems for them.
We have a process involving a Product Council, that compromises senior leadership such as the founders, head of sales, etc. Any request gets recorded in a product council request followed by a discussion - after which, the product managers take a call. This Product Council meeting minimizes the tussle between product and implementation, and most importantly, brings in the perspective needed in such cases. If the product council says no, it is a no.
We have also realized that it is good for the client also to be aware of and understand our internal practices. For example - our clients also know that new requests have to run by the project council and that their decision is final.
The way I see it - it is good to remember our role enabling getting people into the same room to enable decision making, and sometimes that’s all we can do.
Here, again, what has helped is the customer understanding our process well. For example - we then go back assuring them that it is on our roadmap but not on immediate priority.
In case, they insist on still prioritizing it immediately, we charge them for the said request. We’ve seen that with large enterprises, if the feature is really of value, they are okay to pay, and in some cases, this either puts things in perspective for customers or helps us push back.
At Pando, this aspect is handled by the sales team and not the implementation team.
Since your system integrates with ERPs or third-party systems which can sometimes be like a black box to you, how have you evolved for this?
So, there are steps we have taken and steps we’re still working on. Here are two things we’ve already done:
What we are currently doing:
We realized that it is important for third parties to understand what we do and own the end to end integration themselves.
This was not the case. For example - if they were testing SAP to Pando, their testing would end at the entry point to Pando and not further to see if it has entered Pando.
Now, we will give them training about Pando and where the data points are to be seen, and what they would be. They don’t need to understand all of our product but instead the importance of those data points.
This way, the third-party project-manages end-to-end and drives the UAT conversation with the client. We have seen good results with this
We loved how Pando’s journey from 0 to 20 has been focused on the value for the customer and looking at implementation beyond just delivery and go-live. There are lessons and takeaways for all of us - a shift to value delivery, focus on solid processes at every step, and customer relationship-building. Here are some of our key takeaways from the conversation.
Join our private, invite-only Slack community and attend the next Implementation Stories session. You will also gain access to peers, get to share knowledge on customer onboarding, implementation, and customer success.