Shoptalk 2024: Grove Collaborative Discusses Their Product Discovery Evaluation

Shoptalk 2024: Grove Collaborative Discusses Their Product Discovery Evaluation

While the key themes from Shoptalk 2024 continue to make waves in the ecommerce space, so do revelations about the importance of retailers’ product search and discovery experiences. 

Constructor CEO Eli Finkelshteyn and Grove Collaborative CTO and Co-founder Chris Clark sat down to discuss Grove Collaborative’s product discovery journey during Shoptalk 2024. Read the candid interview below, including Grove’s challenges and triumphs involved with building a sustainable plastic-neutral ecommerce company from the ground up.

Eli: Could you start off by telling us about Grove Collaborative and what you do? 

Chris: Grove is a consumer brand and retailer focused on sustainable, natural, non-toxic homecare, personal care, and wellness products. [We focus on] all the things in your home that you run out of that aren’t food — hand soap, dish soap, vitamins and minerals, supplements, paper products — [with] a real focus on making those a force for human and environmental good. 

In particular, we have a focus on removing plastic from packaging and single-use plastic from that ecosystem. These categories aren’t good historically in that area. So, we hope to push the whole category forward. 

Eli: Constructor and Grove Collaborative work together on search and product discovery. Could you tell us about why that’s important to you? 

Chris: Grove is a company that came up through home care. We started off in home cleaning. That’s a category where the selection was smaller, and search and discovery was a bit less important. So, initially when we first got into this as a business, we created a home-grown solution. 

But over time, we’ve come into a lot more categories, like health & wellness and personal care. We’ve expanded the selection of our homecare products. 

As that catalog got bigger, our home-grown solution started to be more challenged. At the same time, it was important for customers to understand the breadth and depth of our catalog in different ways. It’s a story of expanding our footprint into more categories, but not really having the technology and tooling to get those products in front of our customers. 

Eli: So, your customers wanted more Grove products, but as you were creating more of those products, it was making the search start to fall down. 

Chris: Exactly. The business had outstripped the system we had built, which is a pretty common story in software and in growing businesses. 

Eli: That makes perfect sense. How has your experience been with Constructor so far? 

Chris: It’s been great so far. We’ve been live for about 6 months. As we go, we’ve been implementing more and more breadth of that platform, and we’ve been working closely with folks on your team both before launch and coming up through the project, proof of concept, and the other side as well. 

Eli: How did you go about the evaluation? You must have looked at other companies. Why did you choose us? 

Chris: We looked at a bunch, absolutely. There are a lot of offerings in the space. I think it really came down to two things. 

The first was that our engineers really liked [Constructor]. We went and started looking at proof of concepts. You know this. I think you come from a software background as well. When your engineers like something, the estimates get lower. And it’s easier to implement. 

I take that feedback really seriously — when my technology team says it will work, we like the APIs, [and] we like how to implement it. There’s nothing worse than biting off a technology project and it turning into a quagmire that you’re not getting value on. I think that was really the first thing for us. 

The second was that we were in the market initially [for] search, but quickly found out that Constructor has a broader portfolio offering — the ability to do recommendations in different strategies, the ability to do collections modules, recommendations in email. There was a broader set of functionalities there. I will say we found you to be one of the more expensive solutions. This is not something that’s cheap. But when we were looking at it, we had other options that were less expensive, but they were really point solutions that were focused around search. And we knew that it might be less expensive to go in a different direction, but we’re going to have to find vendors to fill in gaps in other areas. 

So those two things — the completeness of the solution and the suite — allowed us to really justify the price. And the fact that we knew we could get it live, and our engineers were excited about that. 

Eli: I love that. Was there a way that you folks scoped the value of it beforehand? If I remember, you went through our standard Proof Schedule™  process, right? 

Chris: Yeah, exactly. And there were two pieces. One, we were sunsetting an older piece of technology. So there’s some concrete savings that come from that. We get to shut down AWS services, and of course, we don’t need to spend engineering cycles on this anymore. We can reapply it, and there’s real value in that. 

But that’s not enough. If we’re going to invest our valuable engineering time and our valuable product management time in a new technology project, the ROI has to be significant. 

When we worked with Constructor, we set a floor threshold goal, saying look, we’re gonna go through [the Proof Schedule™,] this proof of concept, and we’re gonna need to demonstrate that very clearly, out of the box, day 1, regardless of our expenses, there’s gonna be a 3X lift, not from a revenue standpoint, but from a contributions standpoint. Actually cash money in the bank. We’re gonna generate enough revenue with profit dollars to be able to pay for this three times over. That was sort of the minimum threshold that we set when we went through that Proof Schedule™ . 

Eli: If I’m understanding it right, you both wanted to give your shoppers a better experience. You wanted them to be able to find more of the products now that you’ve got this big selection, but that’s not enough. You wanted to have engineers have these better APIs, but that’s not enough either. What you really needed on top of that to make this really worth your while was it needed to much more than pay for itself. 

Chris: Yeah, exactly. To be clear, we had no doubt that Constructor was going to beat the pants off of our home-grown thing, right? We were clearly in the market for a reason. 

The thing we were doing did not give good results. It had a lot of empty results. Users would type in some queries, and you’d get really odd things. If someone types in shampoo for search, the first result we had was a dog shampoo. It’s not impossible, but it’s unlikely that that’s what that person was looking for if they just typed that in. So, we just really didn’t have the ability to scale our search. 

We were very confident that [Constructor] would work better. But we’re a company that takes profitability seriously, and we really want to make sure that we have to see the results not just qualitatively but quantitatively. So we set that bar of 3X ROI on the actual cash-out-the-door to you guys that we could recognize within a year, and we cleared that bar in the initial implementation. And then of course since then, we’ve rolled out a considerably larger portion of the offering. And so there’s much more surface area. And so that number is starting to tick up and up. 

I’d say the other thing that’s interesting about how you all work which is different from a lot of folks is that we have weekly meetings with your team to [find ways to improve business metrics, like] tweak algorithms [and] run actual A/B tests of different strategies and recommenders. So very quantitatively, not just theoretically, we can see the ROI ticking up over time. And then it’s gonna show up in email, [and] it’s gonna show up in other aspects of the site. And that surface area just increases, and the return increases. 

Eli: I really appreciate that, and I appreciate you calling it out. It’s a big thing for us that we want to show you that initial lift, but then every single year that you look at it, that lift should be bigger than it was the previous year. And the year afterwards it should be bigger than that. 

So, the way you actually evaluated us: You went through the Proof Schedule™ , the proof of concept, and that kinda gave you faith. The engineers played around with the APIs. You saw it looked better when you were looking at the results. But then you tested it afterwards, right? 

Chris: Yeah, I mean we ran an A/B tests. We built a proof of concept to sorta prove out the actual implementation then launched an actual A/B test to measure and verify that 3X ROI contribution initially. Then once we were live, we did testing on both different types of algorithms and strategies across the site. And then again just pushing out more and more modules. 

Eli: Very, very cool. What’s next in store for the relationship? What do you want to do next? 

Chris: So, we just finished [implementation]. Right now, if you go to — or in the app — and you see any carousel or recommendation [that tells you] ‘hey, check out these products,’ whatever it is, these are all powered by Constructor now. So, one of the things we have to do is delete a whole bunch of code that used to power this. 

Eli: That must feel good! 

Chris: It’s great! Nothing makes me happier as a CTO than deleting code.

Eli: Awesome. 

Chris: So, we have to do some clean-up on our side. But then, there’s a few more places that we’re looking to expand Constructor in our ecosystem. One of which is email. We’re not yet live on email recommendations. We’re fully live on the site. Next step is email, which is always interesting because it’s very high volume. We’re sending large volumes of emails, much higher than site impressions. So, we’re excited to get that going. I think that’s in the next 30 days, hopefully sooner. We’ll see. 

The other piece, too, is a little bit in the weeds, but you all have on your roadmap something called variation slicing. We’re a retailer with a focus on merchandising. So, these details matter quite a bit. The ability to dynamically say hey, we want this product to not show up as a single hand soap. We want it to show up as three different scents in the results. 

The plan is to control how much surface area we’re exposing for each of those products and be able to blow them apart or put them back together in order to show customers, [essentially] showcase more of what we actually have to offer. 

Eli: And you folks needed that to be really fine-grained. So you could split it out by scents, but you wouldn’t split it out by sizes or something like that? 

Chris: I think we could, and we’ll have the options to do each of those things. I think one of the things that we’ve liked about the tool is that the back-end configuration and set-up is very much there. But the controls are not like super in the weeds or nitty gritty. We have controls to be able to say ‘hey, let’s boost this or bury that. Set this up this way. Set this up that way.’ The amount of configuration [is very user-friendly]. 

The thing that impressed us initially was just kinda how it worked out of the box, which is why our engineers liked it. But there’s just enough controls in the back so that the merchandising team can do their jobs. 

Eli: That makes perfect sense. If I could ask you one more question, and I’ve asked about this before. So, feel free to say no, but: What’s your advice for somebody else in similar shoes to you before you chose Constructor? 

Chris: I don’t know if it’s Constructor-specific, but don’t build your own Elastic search engine. That would be my advice. Yeah, it’s a more complex problem as we got into it more and more. Maybe everybody else already knew this. So, we had to learn it the hard way. But [my advice is] really getting it right so that all the synonyms are working right [and] so you’re not getting empty results. It’s just more nuanced than I thought. 

And not only that, but it’s hard to measure. It’s non-trivial to figure out what’s working and what isn’t. So frankly, being able to not worry about this category of problem anymore is a really nice thing to do in the business. We can focus on what makes Grove special and different and delivering our mission. 

Eli: I love that. Thank you so, so much for being willing to partner with us on this. Thank you so much for being willing to have this conversation with me in the first place. 

Chris: My pleasure. We are very happy customers. We wouldn’t do it otherwise. 

Eli: You folks are lovely to work with. 

Chris: Thanks! 

Eli: Chris, thank you so, so much for doing this. And thanks for being a great partner. 

Chris: You’re welcome. Likewise.  

Interested in the full story? See more details about how Grove Collaborative upleveled their product discovery experience with Constructor here.