It’s not time to hire a product manager

Anand Jain (CleverTap)

2 August 2022
#Leadership #Product

When you’re an early-stage entrepreneur, it’s hard to hire a product manager. The money is limited and, to be honest, no one has the vision you do. So, you’re the product manager, you do sales, you code, you are HR. You are everything. It is what life as an early-stage entrepreneur is all about. But you don’t have to do it by yourself. You can co-create your product. 

Often, entrepreneurs ignore the role a customer plays in creating the product. It’s your first few customers that will help you shape the product. It’s important to discuss this today. Entrepreneurs have found new markets to explore. The pandemic nudged people to take risks and explore entrepreneurship. The results of this won’t be seen now, but a few years later. We are still sowing the seeds for a future that will change the way the world perceives Indian entrepreneurs. But entrepreneurship isn’t easy. Founders at early stages need all the help they can get. And one of the first things founders need to get right is the product. Today, I want to talk about how founders can co-create their products with their customers. 

My promise from this piece is that it won’t be esoteric.

Co-creating the product 

We accidentally fumbled into the co-creation framework. This is back when CleverTap just started. We first built the core database technology and had just started thinking about how to build the product on the top of it. We were trying to get a few early customers. Customers are rarely excited an early bare bones product. They typically want to see a more rounded, feature rich product. Something that they can plug and play. And things get harder because you’re often trying to replace an incumbent solution. At CleverTap, we were in the MVP phase for 30 months. We started to monetize our product only after we were satisfied that we had achieved a true MVP that solves customer use cases.

So, how did we build our product out? 

We showed the early versions of the product to entrepreneurs, prospects or anyone who would give us time. BookMyShow was one of those who was kind enough to give us time and expressed interest. Apart from BookMyShow, we had Firstpost, Crude Area, and there were a few others who were ready to pilot. All of them, one of a kind in terms of business model. We convinced them to install the SDK. And that’s when feature requests started coming in thick and fast. “Why can’t I invite others to the dashboard”, “Why can’t I embed this graph in my report to my investors?” Requests coming in from all directions. 

While using early-stage products, customers often stumble onto things they need when they start the product. It’s difficult to build everything a customer asks for. So, we build a framework, now called the co-creation framework, to help guide us – 

  1. The feature ask is from a customer, not prospect, and it should be useful for more than just the one asking for us 
  2. It must be on the directional roadmap. You have to make sure it is something you want to build sooner or later. 
  3. Whoever is asking for it, commits to using it, giving regular feedback, and evangelizing the feature. 

Let’s take a hypothetical example. Say an e-commerce company approached us. They say, hey, my when a user abandons items in a cart, we should be able to send them a push notification. This message should get to them over WhatsApp as well. That’s a use case that one company wants. They want us to open a new communication channel – WhatsApp. How do we decide whether to build that additional capability or not?

For CleverTap, email was the channel. Push notifications were the primary channels our customers used to communicate with their users. But customers would say, what if this user doesn’t have my app? We want to reach them also via email. Emailing as a new channel of notification was on our directional roadmap. So, that’s a check. 

Now, will other businesses use it? That will decide if we prioritize build it now or build it later. We asked our customers. For our many of customers who were web-heavy, having email made sense. BMS said, “We need to send movie tickets by emailing.” People want to zoom out and see the seat layout on the website and want to save their tickets by email. We spoke to a couple of other customers, and they said, yes, we want emails. When we went to others, we didn’t say others were asking for it. We asked, “do you want it?” It will not be sophisticated, but it will work. We gave a 30-day commitment. And delivered it in three weeks. 

The job of a product manager is to prioritize. What should be built? Why should it be built? And when should it be built? The ‘how’ is for engineering. 

Here’s a little caveat. Is the requested feature something the customer should build themselves and they’re just passing it on to you?

Sometimes a customer will ask you to build something that is so specific that it is ‌clearly a solution they should build in-house. Ask yourself, is this part of ‌the problem I’ve set out to solve? 

We were at this crossroads once. A customer wanted us to build a recommendation engine. When you’re not sure of a demand, buy time to research it well. We came back to the office and asked ourselves. Do we want to build a recommendation engine? Is it in our roadmap?

We decided to build. Some of these things, email, WhatsApp, recommendation engines, we prioritized them on our journey. The reason we did it was that the tech we were building allowed us to do it. 

We asked ourselves, does CleverTap want to solve all these problems? It did. But you need to ask yourself the same question. Does your company want to solve this problem? You don’t end up with something you don’t need. Remember, at the end of the day, you’re a product company. You’re building to solve a larger pain point for the customer. 

Finding champions

Now, you know what your customers want. You’ve decided it is worth building now. But the “what” is still to be untangled. And co-creating it means conversation and understanding what your customers want. In the early days, everything you build is for customers, not for prospects. This is a classical use case problem. Prospects might say, “Hey if you had this particular feature, we would buy it.” But then they always have excuses. Customers who are already using the product it will appreciate what you’re building for them, including them in the process. 

In the early days, one can truly understand the unarticulated customer needs by having a great working relationship with them. I understand, sometimes you might know them for too long. My suggestion to all early-stage founders is to meet their customers as often as possible. Not on Zoom, but in person. Observe how they use the product. Sit around a table and talk. When you’re sitting face-to-face, you ask follow-up questions. 

  1. What do you want to use this additional feature for? 
  2. How do you intend to use it? 
  3. What do you use now to solve this problem? 
  4. Why does the existing approach not work for you? 

The answers will give you insights on the problem. You now can begin to unpack the need that you’re addressing. 

Now, after nine years, we can show a laundry list of features to make a convincing sale. But back in the day, when we had a handful of customers, we had to do these one-on-one conversations to truly understand the need and assure the customer that we’re building for customers like them.

Once you’ve made the product, the challenge is adoption. Once your customer starts using the feature and has a good adoption, you need to nudge them for a case-study or a testimonial.  

Let’s go back to BookMyShow. Now, if BookMyShow has started using the email feature, we need to start monitoring its usage. We know how often a movie ticket is sent and when these email requests peak. Be data driven. This will help you be more confident and it helps you develop more features around it. And you can use that data for another prospect. The underlying factor here is that you need to know what game you’re playing. Co-creation is just how you do it. 

Building a network

Look, I’ve heard people say, “Anand, you had a network. I don’t.” It’s hard, I agree. But there’s a way to get around it. First, let’s understand why a customer won’t want to co-create with you. 

  1. There is no trust. Customers will ask. Why should I buy from you? We’re also giving you data. What if that data is not secure? 
  2. Even if they ‌know you, they may say you have fewer features than the product you’re looking to replace. 

How do you solve this? 

  1. Convince the customers that you’re not asking to rip and replace. Ask them to use your product on the side and evaluate if your is better than the existing one, even if for a specific problem statement.
  2. Startups buy from startups. Find an early adopter that will use your product and is trying to scale fast. Typically, these companies will be more open to taking risks.
  3. Park yourself at these customers’ offices. Sit there, talk to them, listen to them, and build it. For you, they’re the only customer that is important. You can build faster than their internal teams. Your engineering team has no debt, there are few other priorities. 
  4. Give them speed and attention to win them over. Other vendors can’t do that. The bigger you get, the less personal time you will be able to spend. 

When you’re going from 0 to 1, you can’t be a systems and processes person. You need creative problem solving. 

Tesla is a good example. Elon Musk talks about the battery of his cars and how EVs will change the way we think. Elon figured out to solve the problem deeply, and not just add batteries to an existing car chassis unlike other traditional car makers. 

So talk to the customers, figure out their unsolved and unarticulated needs and build deeply for it.