Building Products the Right WayPosted on 09 Jun
The week, we are featuring an interview with Sreejata Chatterjee Co-Founder and Head of Product of LeadSift. Sreejata talks about lessons learned from not one, but two product pivots, and how listening to customers was the essential ingredient to LeadSift’s success.
Q: What was LeadSift’s approach to building its product when you first launched?
A: One of the reasons we had a relatively easy time raising our first round of funding was because all of LeadSift’s co-founders were great at building things. We just went ahead with a product that we thought was right, and that people would like, and investors saw the potential. We all believed that if we build it – they will come. But after a few years with lower traction than we would have liked to see, we realized this approach was missing something.
Q: Is this when you first decided to pivot?
A: Yes. We knew we had to make a change. People just weren’t responding. So we repositioned our first product and built a second, again based on our idea of what our customers would want to see. But because we didn’t change the fundamentals of how we built the product, we were still frustrated by a lack of uptake.
That second product we built, I’m still really proud of it. It was beautiful. The technology behind it was spectacular. But it was too complex, and it wasn’t solving the problems of our target customer.
Q: After that first pivot, how is LeadSift building its product differently today?
A: Now, our approach is totally different – it’s very data driven. We pivoted a second time last year, and we started doing things backwards – instead of building a product first and sending it out into the marketplace, we now ask our customers what they want to see and pay for and then deliver it. We started by bringing two or three ideas to our customers and asking for feedback. Then, instead of spending time and money building a complex product, we delivered the simplest version of what they asked for, and continued to iterate based on their feedback.
In fact, that’s how our product is still being built today. We manually gathered and delivered the data that our customers said they wanted and it was only when we had too many customers that wanted access to this data for us to do it manually that we began building a platform and larger product.
Q: How do you communicate with your customers to uncover what they really want?
A: We’ve learned so much about what our customers want, and a lot of it is due to our process. We originally conducted interviews with customers that decided against using LeadSift, but that information wasn’t valuable to us – after all, there are a million reasons why someone might not use your product. Instead, we focused on the customers that did sign up. These are customers that want to be more successful, and we want to help them.
I’ll give you an example of our process, and how it has informed our product. We asked a group of customers if generating leads was their problem, and they said yes. So we initially thought that delivering a database of static leads would help solve their problem. But after conducting second-round interviews, we were able to understand their problem on a deeper level. They wanted to know which leads were best to get in touch with right now. They wanted context. Static lists were not good enough, or they already had static lists that they found for cheap, because everyone can buy them for a few pennies.
So that’s where we saw a big value add for our clients: adding context to leads.
Q: What would you say to a new startup facing the challenge of building their first product?
A: It might sound cliché, but listen to your customers. Really listen. This was the advice we got when we were just starting out in an incubator, and it took us three and a half years to actually implement it. I see so many other startups, at various stages, that don’t do this essential step, and they end up wasting time, resources and even fail completely because of it. Your customers want you to solve a problem for them, so listen to discover what that problem is before you build what you think they want.