Decoding Presales and Product Management - Cuppa Press

Picture this -  You very passionately continue talking to a room of 10 people about the sophisticated technology that your product uses.  

 

…. Only to realize that only 1 of them truly understands what you say.

 

“I’ve seen that in a room of 10 people, only one or two of them are technical folks. The remaining happen to be folks who actually are stakeholders from a business standpoint. For them what matters is when a customer comes to me how quickly can I solve this problem?”, explains Kishore V,  who heads the presales and product management teams at Kriti Labs

 

In the brand new episode of Cuppa Press, Kishore talks about the importance of stories in presales, the role of content from a product perspective, ways to reduce friction among product and content teams, and his mentoring experience.  

 

Do subsribe to our YouTube and Spotify channels if you don't want to miss out on the upcoming episodes!

 

YouTube

 

 

Spotify

 

 

Here is Kishore, in his own words:

 

Tackling Dual Roles 

 

My function on a typical day is a mixed bag since I have dual roles right now - one in product management and the other in presales.

 

As a product manager, I work with the team on a specific product and build prototypes. From listing down the features of the product to mapping a plan on how these features have to be rolled out, a product roadmap is drawn. Following this, the product production starts. 

 

On the other hand, for an existing product, we receive multiple feature requests from our customers. We put together these requests in a report and get into a discussion with the engineering team. 

 

Not every request can convert into an actual feature. So we identify if these features are specific to the customer, specific to the industry or if it can be accommodated in the core product.

 

As a presales person, I would work on the solution. I take a product, see what use case the product is trying to solve, build a solution around it, and then work with the sales team to see what existing leads in the pipeline we can look to convert. 

 

It is very intense, because you will have to work with your team to ensure that the messaging is conveyed in the right way, and the sales team is able to talk to the leads and their customers in a way that they understand the whole value that we're trying to deliver as a company. So it's a very interesting role.

 

Role of Content from a Product Perspective

 

If you look at a product, what ultimately it does is, it delivers some kind of value to the customer. And you need to clearly articulate that value to the customer as to why they should look at the product that you're building, why they should be using the product, what value will they see.

 

And typically, if you present the demos of the product, that's not going to suffice, you should be able to articulate it through multiple ways. 

 

Content is important from a product management perspective, because even from a sales pipeline, so you have, you have the MQL to SQL to conversion, and then the conversion rate. So at each stage of the pipeline, you have different content that you put forward. 

 

Similarly, even in product management, you need to look at what you're building as a product until the product is out of the wind out of your pocket to the customer. And once the customer starts using it, there are multiple types of documentation that you build, multiple content that you create. 

 

Now some of them are internal to the organisation more from a process perspective, some of them are external to the organisation where you convey what value the product is going to bring to the customer. So when you look at the product building standpoint, right, you need to understand what use case you are trying to solve. 

 

Types of Content the Product Team Creates

 

At Kriti labs, what we do is whenever we see a use case, we build something called a concept.

 

That concept note very clearly articulates, what is the business problem that you're trying to solve, how are you trying to solve, what is the platform that you're trying to build and we then build a story around it. 

 

 

And once the concept note is ready, we then send it to our founders for a quick walkthrough with them because everything has a budget tied to it right so we can't start anything without approval from them.

 

The next step is we convert that product into a feature list. It is an elaborate process where we create a Functional Requirement Document that talks about the pure functionality as to what the product must do, how it needs to behave, the workflows so on and so forth. 

 

Then the Technical Requirement Document (TRD) is prepared, which describes what aspects of technology do we require, the number of layers, etc. Our products typically have three layers. 

 

One is the hardware layer. Second is our common platform layer. And third is the application layer because we are in all these three layers. So when I build an FRD, it needs to flow through all these three layers and when I build a tech, TRD, it will be for each of these layers.

 

And then we build something called a data sheet. Now the data sheet is something that we convey to the customer. Because in IoT, what happens is one of those things that customers look at is also the specifications of the product that you're building. 

 

When I say specifications, you don't have to really talk about the innards of the product, but more in terms of the operating parameters like at what temperatures can you use the product, what is the product certified, so on and so forth. Now the content from the data sheet will be made available to the team and to the people outside the organisation when they start evaluating our product. 

 

And between the time of conceptualization to building the product, there will be a lot of use cases that we will start looking at. We will probably be doing a lot of pilots, plus a lot of Beta releases. 

 

So what we do is whatever data that we get from these beta releases if we see is got any value that we can showcase to the customer, we start putting it forward to the customer so that when a customer possible future customer looks at it and feels that it might actually solve his/her problem is what the thought process would be. 

 

In general, content is important because the content in various formats, be it through blogs, be through videos, be through posts, and all that will actually convey the value the product is building. And also you have the case studies that you talk about, right? Once you implement a specific product, you need to very clearly say what kind of value you've been able to give to the customer.

 

For instance you have done you have implemented the product, around 50,000 installations across the country, you've been able to bring down the pilferage or bring in some added amount of benefit to the customer to a specific percentage, for instance, you've been able to reduce the turnaround time by 30% or 40%. So you need to call it out. 

 

And these are those content that you really need to put into your website or into through your blogs. In addition to that, there will be content from a thought leadership perspective, like how is a specific industry gonna go in the current crisis or in the current atmosphere, which direction is it gonna go? These are some of those content that you will have to end up building for the customer as well. 

 

So the customer perceives you not just as a product builder or as a value provider, but also someone who's thinking about the future, as someone whose thought processes like 30,40 years into the future. So, so that's what I say you need to build future proof solutions. So that's how it is. So these are certain content that you build along the way of product management and beyond.

 

Avoiding Friction between Content and Product Teams

 

So typically, what happens is I always give the benefit of doubt to the content team because they know how beautifully or how accurately can content be depicted. And even in the whole mix of product management, there is a role that I didn't really talk about is the product marketer. Now, the product marketer's primary role is to ensure that the content is put together in a way that the target audience is able to get it.

 

So when I look at my target audience, my target audience is typically large scale customers who do bulk transportation, in my case. If you're looking at Freshdesk, or if you're looking at Zoho, their target audience would be small to medium scale business, right SMB customers. So what are the typical problems an SMB customer would have?

 

Their problem would be in terms of getting all their content in one place or utilization of cloud and all that. So as a product marketer, my content should be serving or should be targeting a specific audience as the product that I'm building. 

 

That is where the role of product marketer also becomes very, very important because they help put together the content for the product, and they will have to work very closely with the core content team when they are putting it together. 

 

As a product manager or as a product marketer, you can convey what the product does. But how effectively or what is the content strategy that would be in the hands of the content team because they know better. They know how the market is going to read the content, whether the content needs to be gated or not.

 

All these strategies are something that the content team would do. How the content needs to be put out is something that I would give completely to the content team. But what content needs to go out will be with the product team, be it the product manager or the product marketer. So that's how I look at it.

 

Importance of Stories in Presales

 

When you are building content typically in the space of presales, what happens is that it ends up being very technical, because your solutions are typically technical solutions that you put together. 

 

But when you go to a customer meeting, not all of them are gonna be technical folks. 

 

I've seen in most of my presentations, at least, only the technical folks happen to be only 10 to 20%. So in a room of 10 people, only one or two people at max are technical folks remaining happen to be folks who actually are stakeholders from a business standpoint. And you go ahead and talk to them about technology that you're using, about the databases that you're using, it is not gonna really fly because they'll not be able to make anything out of it. 

 

For them what matters is when a customer comes to me how quickly can I solve this problem? That would be one of the questions that they might have. So what I typically do and I also recommend people to do is to look at a use case, right?

 

A Banking Company’s Onboarding Story

 

For instance, your solution is about customer onboarding and let’s assume you are a banking company, right? And you have trouble when you're onboarding customers from omni channels. 

 

So, typically, omni channels are multiple channels through which the customer can access the bank. It can be mobile, it can be web, it can be social media, it can be a branch, it can be a kiosk, so there are multiple channels. But what happens is, in customer onboarding, the problem is, the experiences vary across these channels. So sometimes you go visit a branch, it's actually easier for you to get onboarded as a customer. 

 

But when you're trying to do it online, there will be multiple problems that could creep up, right, because your technology or your infrastructure is not really made for. So that's when a banking customer asks for a solution for, for onboarding their customers. When I give them a solution for this, it will be a story that I'll talk to them about. 

 

For instance, my story would be how my product or my solution can help someone who's sitting remotely in Timbuktu with a 2G or 3G connection, how is he able to access the bank's portal or the bank's app and still able to, you know, put in the required data, upload the required documents that are required for the onboarding without any problems. 

 

Now, for instance, if he is using a laptop and he's uploading the information as asked by the bank for onboarding, and he loses power, or he loses the connection. So what typically happens is if you don't have a proper omnichannel solution, the data uploaded till then will not get saved, and the customer has to do it again. 

 

This becomes a pain to the customer and he’d rather go to some other bank because he now has to do it again. So, in that circumstances, what would happen is if you have an omnichannel solution, you will be able to do it partially, and you will get a code from that you take that code, and you know, you have a mobile app, you can actually start from that thing again. 

 

So what you would do is you would switch to the phone, take a photograph of the signature and then continue uploading. So this is your omnichannel solution and when I talk to the customer, this is how I will weave a story around it.

 

Because these are typical day-to-day problems that people face, I mean, you might have an internet downtime, you might have a power downtime you never know. So, that is why when you talk to your customers, you will have to weave the entire story to them. And then you get into the demo.

 

This is what presales does - build a story and put the content in line with the story. So you need to really understand who's the hero in this. In some cases, your hero might be the solution. Or in some cases, your hero might be the end customer who's going through the entire thing.

 

In my example, the person who's actually uploading all this data to get onboarded is the hero. 

 

But if it's an end business or end-user problem, it is the end-user itself, who's the hero. So you need to decide who's the hero, you need to decide how are you planning to tell the story around it? What use case are you trying to solve for the customer?

 

So these are those things that you really need to keep in mind when you go for presales presentations when you are actually demoing your product to the customer.

 

Taking a Strong Stand Against Misconceptions

 

People think that in presales, you are a master of building presentations and master of writing content, but I actually beg to disagree. There is a lot of work that needs to actually go in before we start putting the presentation. People don't look at that. 

 

So, the typical effort that we put in before we start putting the presentation is we do a lot of conversations. We talk to the customer, we listen to the customer, we try understanding what their problems are, we then do a lot of primary and secondary research in terms of what the customer problem might have been, which we might not have understood. 

 

We look at the industry the customer is in, understand what are the generic problems in the industry, analyze the competition, etc. 

 

So we do a lot of research before that, and in case, we have already worked with the customer, we also try to look, you know, internally talk to our own folks to understand if there have been any problems earlier. 

 

So there is a lot of data gathering exercise that we do, right? Then we try putting together the elements of the problem statement and only after that do we key the problem statement. After all of this is when I would even start thinking about how I put it together, whether I put it as a white paper or whether I put it together as a presentation or as a Word document. 

 

But typically what happens is the moment you know, we go to a presentation, everyone looks at the presentation and they say that we’ve made a fantastic presentation. But I tell them, "It's not about the presentation, you are missing the picture entirely!". 

 

There is a lot of effort that goes, a lot of analytical work that goes. In some cases, we also do some amount of basic data analytics to understand whether whatever the customer is told us is not the symptom, but the actual problem. So this is from a presales perspective. 

 

From a product perspective, one thing which I've been hearing and I've been telling people is that to be a product manager, you don't have to be you don't have to have an MBA.

 

It is a wrong notion. People think that you need to have an MBA to be a product manager.

 

I’d say you just need to be a problem solver who understands technology, who also understands the business domain a bit. If you can do that, you can be a product manager. 

 

I mean, you write a feature list in English, you talk to people, you just convey what the product needs to do, what features it needs to have, you need to, you know, coordinate with a lot of people with the engineering team, with the marketing team, with the content team. 

 

So there are a lot of things that you need to do and you don't need to have a fancy MBA degree for that. Anyone with basic common sense can do that. 

 

Common sense is the big-ticket item there I mean you really do need to have common sense.

 

Reaching out for Mentoring

 

When I was growing up in my career, and when I tried my hand in presales, I didn't really have anyone to handhold me literally.

 

 I just had my boss who gave me fantastic advice as and when it was required. But apart from that, I didn't have anyone that I would actually lean on to or talk to saying, “Hey, you know what, I'm here and I don't know what to do next”.  So that is something, which I'm trying to do.

 

People can reach out to me on LinkedIn. My DM is always open. I always call it out in my headline. 

 

And once you have expressed your desire to talk, do let me know, we can then mutually agree upon the, you know, the schedule, and then connect. I think that is the easiest way of reaching out.

 

And I've had a very interesting experience because it's not just about me telling them what I know. It's also understanding a lot about people, a lot about the problems that they are facing, a lot about in terms of a lot of people are looking for a career change.

 

A lot of my presale specific queries have been that I don't know what to do next. I've been being I've been a presales consultant for almost five years. I don't know what's next. So I tell them, that there is a lot of things that you can do in the leadership roles as a presales person. 

 

So I tell them, you need to do this, you need to do that. Or if they're looking for a change to get into product management, I tell them where they can start. So what they need to do the bare minimum to get started and what are those first steps that they need to take. So these are certain things I've been doing and it's been really useful for me also to understand what different people are looking for. And it's not you know, straight line when you look at a career. 

 

People have had their ups and downs and people really are looking to make most of their careers at this point in time.

 

So I have an open DM. I've also published my phone number and my email on my LinkedIn. So LinkedIn is the best way of reaching, reaching out!

 

Previously on Cuppa Press

• Selling in This Digital Economy
• Content Marketing Playbook for SMBs
• LinkedIn, Quora, and Personal Branding
• All things Branding
• Brand Storytelling for Millennials