How to involve users early and co-create the product
Parent Post
One of the things
One of the things that differentiate us, in general, is the level of customer obsession that we have.
I’m not kidding you when I say that for months and months we 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.
What our users tell
What our users tell us goes hand in hand with the data we analyze because we’re able to confirm 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 innovating and solving these problems as possible.
I think it’s difficult
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 you—you co-own it with them.
I’ve found that knowing
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 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.
What I learned from
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 doesn’t matter unless you have a good knack for understanding real customer needs and wants.
And it turned out, we were ignoring that a lot in the first company.
We have customer advisory
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.
We identified some 76
We identified some 76 users across different internet mediums, including Twitter, who 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. But if you are a developer or an engineer by training, do not skip this part.
We have had several
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 it 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.
Icertis users continue to
Icertis users continue to give feedback. We continue to listen 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 that one user.
This has been critical! That is why I 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!
Rarely does the idea
Rarely does the idea for a good product arise independently from the mind of a brilliant entrepreneur.
A perceptive entrepreneur is also a rigorous researcher who knows exactly what frustrates the user and then works towards improving the existing product for better results.
In many ways, therefore, the successful SaaS products of today are manifestations of carefully curated user feedback that address complexities and constantly innovate to enhance the overall product experience.
We went out to
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.
Yet, 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.
Nowadays, people write and
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 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 spent almost a
We spent almost a year in stealth, working with customers and seeing how we could get their experience right, how we could create those wow moments for the user, and we could 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
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 adopt the product?
That has been a very, very core part of the DNA and everything else is built and centered around the product.
We started working with
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.
The referral thing has
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.
We made the initial
We made the initial prototypes, expecting everyone to love them and buy the product immediately. We were wrong but also lucky that this was an alpha release.
We pivoted and built a beta product 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.”
Having said this, in
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 responding to what the customer was asking for, we would not have been the product we are today.
That is to say, 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 many levels deeper.
You might uncover an excellent opportunity that even the customer doesn’t realize.
Don’t immediately start building
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 well 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.
Comments ()