Did you involve any early users in shaping the product? What are the biggest lessons learned from that journey?

MONISH DARDA

We have had several of our customers come back and say that they want to work with us. We have had several of our partners come back and say we want to work with you. From a values perspective, making sure that works out well for both parties is very important, but how do you see and get the right people? How do you make sure that they are referring to more and more people? Because if you wake up in the morning and you want to go to the office and work, and you love being part of Icertis, you will refer it to 10–15 other people. The referral thing has worked out very well. In my mind, it all boils down to getting your values right, executing them, and making sure that people know what is important in a given situation.

With Icertis, we got lucky! We had an enterprise customer before we built the product vested in our success. So these early users shaped the product— and we haven’t forgotten that today. Icertis users continue to give feedback. We continue to listen carefully and act on it. The biggest lesson, though, was not listening to your users—how do you look beyond what they are asking and see how it can be incorporated to benefit the whole community, not just that one user. This has been absolutely critical! I think that is why I absolutely love product management. It is like a painter creating a work of art from paint and canvas—it is quite incredible when the right paint and canvas in the hands of an artist becomes a great work of art!

ARPIT JAIN

We started working with parents and teachers very closely from day one, even before building our product. User research is one key thing we focus a lot on. We have a few teachers who’ve been helping build our products since the beginning of our journey. That’s over 10 years ago! This user feedback process is ingrained in our team’s culture, and this ensures we’re in constant communication with users.

Listening to your users, whether it’s through your support channels, through app store reviews, social media, or anywhere else is crucial. What our users tell us goes hand in hand with the data we analyze because we’re able to validate the problems that the numbers are telling us immediately. We always assume that if one user has reported an issue, then it’s likely there are at least 10x users who are facing that problem. We then ensure that we’re constantly innovating and solving these problems as quickly as possible.

I think it’s difficult but important to break away from the engineering mindset where you have a set idea of a product in mind because it appeals to you. At the end of the day, you have to remember that after the release, the product belongs to the users as much as to you—you co-own it with them.

ABHINAV SHASHANK

One of the things that differentiate us, in general, is just the level of customer obsession that we have. I’m not kidding you when I say that for months and months we just lived in customer offices, asking what your problems are, how do we solve them. Everyone started from our developers to designers to product people, everyone did that. At some point, it gets ingrained into your DNA. We are a very customer backward company today. We have customer advisory boards, we have a ton of our customers meeting almost every two weeks to give us feedback. Every release that we do is first done to our customers, and unless the customer advisory board ticks it off, we don’t release it. There is that level of customer obsession that is there.

IT’S DIFFICULT BUT IMPORTANT TO BREAK AWAY FROM THE ENGINEERING MINDSET WHERE YOU HAVE A SET IDEA OF A PRODUCT IN MIND BECAUSE IT APPEALS TO YOU. AT THE END OF THE DAY, YOU HAVE TO REMEMBER THAT AFTER THE RELEASE, THE PRODUCT BELONGS TO THE USERS AS MUCH AS TO YOU—YOU CO-OWN IT WITH THEM.

— ARPIT JAIN

PRUKALPA SANKAR

We spent almost a year in stealth, working closely with customers and seeing how we could get their experience right, how we could create those wow moments for the user, and we could really rethink. If you think about the core problems we are trying to solve, they revolve around data quality and data management. These are problems that have existed since the 1990s but have never been solved. We started to rethink these problems, to build a completely new way for people. Remember, our users are all very different people—like an analyst’s workflow is very different from an engineer’s workflow, which is again very different from a business user’s workflow. How do you get all of them to naturally adopt the product? That has been a very, very core part of the DNA and everything else is built and centered around the product.

SPARSH GUPTA

We made the initial prototypes internally, expecting everyone to love them and buy the product immediately. We were wrong but also incredibly lucky that this was an alpha release. We quickly pivoted and built a beta product entirely in sync with our customer’s needs. For a couple of quarters, many people had free access to our tool in exchange for feedback. Looking back, it was one of the most impactful decisions we made early on. I remember once Paras (Chopra, co-founder) and I joined a customer call to have a five-minute conversation. The customer shared his experience and requested a feature. I put myself on mute, and by the end of what became a 40-minute call, I unmuted myself and said, “By the way, the feature you asked about is now live.”

WE SPENT ALMOST A YEAR IN STEALTH, WORKING CLOSELY WITH CUSTOMERS AND SEEING HOW WE COULD GET THEIR EXPERIENCE RIGHT, HOW WE COULD CREATE THOSE WOW MOMENTS FOR THE USER, AND WE COULD REALLY RETHINK. WE STARTED TO RETHINK THESE PROBLEMS, TO BUILD A COMPLETELY NEW WAY FOR PEOPLE.

– PRUKALPA SANKAR

Having said this, in the last ten years, we have also innovated on things that no customer has asked. If we had limited ourselves to just responding to what the customer was asking for, we would not have been the product we are today. That is to say, just building the feature that the customer is asking for will not cut it. You have to understand the real pain behind customer requests by going multiple levels deeper. You might uncover an excellent opportunity that even the customer doesn’t realize.

ABHINAV ASTHANA

What I learned from my first company—and this was right before Postman—was that no matter how good or how hard you work on the technology, how good you think you are at design, it really doesn’t matter unless you have a good knack for understanding real customer needs and wants. And it turned out, we were just ignoring that a lot in the first company.

Specifically, I’ve found that knowing why users are not continuing to use your product is a very important thing. Seek out people who are more likely to reject than accept you. In the first startup, we were like, “We built something awesome, and even my mom has the app installed,” but that sort of validation is not useful.

In Postman’s case, we would seek out hardcore developers, people who really don’t like most things; they’re very tough customers. You cannot be scared of going and asking for their feedback because you may get punched in the face with that feedback. So we kind of built that muscle to be able to withstand that sort of thing. We went out to seek ugly feedback where people were saying: “Postman doesn’t work, it’s sh*t, it can’t do this one simple thing that I need it do”; that is the kind of feedback we like because it makes our product better.

However, many companies don’t do that. CEOs often pitch their product as if everything is great and all metrics are up, and the product has no weaknesses. I’ve always been very skeptical of such views.

RITESH ARORA

Don’t immediately start building for an idea. Instead, identify users who have been facing an active problem. You need to ensure there is a genuine need in the market; figure out the depth of the problem and what they are currently using to solve the problem. That is something we did very differently with BrowserStack. Being developers, we have the tendency to jump on to writing the code straight away. But this time, we were very clear that we will not write the code; in fact, we will not write anything for the first month. Instead, we did a search on the internet. Nowadays, people write and share their experiences—you think about any problem, and you will find people sharing experiences about that problem, whether it’s a high-end enterprise problem or buying shoes. So, it’s all over the internet. We just need to find the one where people are sharing their thoughts. Those are your users; they will help you build the business. You also need to identify how you would reach those users. You get your go-to-market from there. We identified some 76 users across different internet mediums, including Twitter, who clearly identified their problems with testing. We could get a sense of how big the market would be and how active the problem is. I would recommend that as the number one thing that first-time founders should do. If you are from a sales and marketing background, it will come to you naturally. But if you are a developer or an engineer by training, do not skip this part.

YOU THINK ABOUT ANY PROBLEM, AND YOU WILL FIND PEOPLE SHARING EXPERIENCES ABOUT THAT PROBLEM, WHETHER IT’S A HIGH-END ENTERPRISE PROBLEM OR BUYING SHOES. SO, IT’S ALL OVER THE INTERNET. WE JUST NEED TO FIND THE ONE WHERE PEOPLE ARE SHARING THEIR THOUGHTS. THOSE ARE YOUR USERS; THEY WILL HELP YOU BUILD THE BUSINESS. YOU ALSO NEED TO IDENTIFY HOW YOU WOULD REACH THOSE USERS. YOU GET YOUR GO-TO-MARKET FROM THERE.

– RITESH ARORA