Leader Spotlight: Bottling the benefits of failure, with Prabhath Nanisetty

---

Prabhath Nanisetty is Global Head of Industry, Retail Data & Technology at Snowflake, a data platform for AI that serves thousands of large and small companies across all industries. He started his career at P&G as a Senior Scientist, later becoming a leader in Consumer & Shopper Insights. Prabhath then served as VP of Product at InfoScout (now Numerator), before transitioning into the role of Chief Innovation Product Officer.

In this interview, Prabhath shares his career trajectory from CPG to tech product leadership. He talks about how he leverages lessons learned from failures to ensure future success by focusing product development strategies on how customers define their problem space. Prabhath also discusses how he leverages postmortems to build a resilient work culture.

---

Product management in tech and consumer-packaged goods

How did you find your passion for product management?

My career path has been a bit circuitous. I have a degree in chemical engineering and started my career at Procter & Gamble (P&G). I started in manufacturing, working on paper plants — my job was to understand the process of making paper, paper towels, and bath tissue, and find opportunities to improve or create new products.

We would also work on launching these sub-brands called line extensions. The process would start with understanding consumers and what they were using paper towels for, turning that into lab bench scale inventions, and then building the systems and processes to launch it. It was essentially product management but from a very different perspective.

Overall, P&G is a very consumer-focused brand. I ended up “following” my passion, but also following the data to consumer research and marketing analytics. That’s where I spent a lot of the rest of my career at P&G — building tools and capabilities for P&G employees to better understand consumers, behavior, analytical methods, etc. I fell in love with the science of product management and product development, but I found my way there rather than learning it academically upfront.

How did you transition from a role at a CPG company like P&G to your current role at Snowflake?

After P&G, I joined a very early-stage startup called InfoScout, a company that was looking to build what’s called a household panel. We would ask people to take pictures of their receipts, and then we would digitize those receipts and create a model of purchasing behaviors in the United States. This would help us understand what everyday consumers buy, where they buy it, and when. We were one of the first companies to digitize receipts and create an omnichannel view of consumer behavior.

I found my way to Snowflake because we used Snowflake as our underlying data and technology platform at InfoScout. As a fan and user of Snowflake, I came in with the perspective to help other companies grow using Snowflake.

Can you tell us about your current role?

I lead the retail data and technology segment of Snowflake. I work very closely with our retail and consumer goods industry, as well as many data providers, technology companies, and startups within this space, including many of our last-mile delivery companies like Instacart and DoorDash.

I serve both as an internal and external advisor, helping Snowflake figure out how to serve this industry better and working with our customers and others to show them what’s possible. I advise them on different strategies in the industry, like structuring numerical data, or processing images and videos, so businesses can drive growth using this data.

The tech industry is known for its complex solutions. Snowflake differentiates itself by not only simplifying these solutions but also offering many customizations, which developers and engineers love because they can build what they want. We also make tools like data science, machine learning, and generative AI more accessible to analysts and people using dashboards and business intelligence.

How have the learnings from P&G helped you as a product leader?

At P&G, I learned a lot about translating what you hear from customers and end-users into products. Product development is more about how customers define their problem space than what you’re supposed to build. P&G would say, “It’s not just the things that consumers say. It’s also the things that they don’t say — what they actually do, how they’re using the products, and so on.” This insight helped me become a better product leader and builder.

Facing product failures head-on

There’s a lot to learn from success, but there’s often more to learn from failures. Thinking back on your career, can you share one failure that stands out and what you took away from it?

My time at InfoScout taught me a lot about failure. I failed at many things, but I also had the opportunity to try different ways of bottling up the benefits of those failures and sharing them, organizationally and culturally. And I wasn’t the only one — we had a great executive team that had very similar mindsets.

One failure that comes to mind is not knowing what to sell and how to set up a good pricing strategy. Very early on the journey, we knew our product was unique and we let that novelty inflate our prices, but we didn’t always deliver enough value to justify them. We had a few customers who really appreciated and valued the data, but we strained and eroded those relationships because they felt that it was too expensive or we didn’t deliver enough to justify the cost. We learned a lot from that failure. We spent a lot of time painstakingly thinking through our commercial models and product offerings, and then we put that into action.

Have you noticed any recurring themes in why products or features don’t succeed?

One challenge is selection bias — when we’re vetting an idea, we might only talk to people who are really interested in the product and so the feedback might be skewed.

Methods like TAM analysis are good starting points, but at InfoScout we thought about it differently and said, “Why don’t we interview the end customers, as well as our users and potential budget holders?” For example, we sold to consumer goods companies. Well, the customer of a consumer goods company is a retailer, so we would ask the retailer, “What do you think about the data that these consumer goods companies are giving you?” This helped us determine what types of analytics and products we should be building.

We also learned to leverage our services team by not necessarily talking to the end customers but also talking to the experts who were serving them. We spent a lot of time with our services team really figuring out what was working. When we had a new product, we let the services team introduce it more manually, and then we would check on it after a few months, so they are actually the tip of the spear from an innovation standpoint. This allowed us to learn where the value was through our experts while somewhat containing any failures.

What are the most common types of failure and how do you handle them?

I see three different types of failure. First is commercial failure, which means that the product just didn’t do well. To solve that, it’s very important to bring your customers along on the journey and not plan too far ahead of time. You have to allow your customers to truly co-develop with you.

Second is technology failure, which means that you built something that didn’t work, didn’t scale, or just spent too much money keeping it afloat. There’s an engineering acronym that I really love called YAGNI — You Aren’t Gonna Need It. It basically means to build the simplest form of a product and take it from there. Often, when multiple companies are competing on new ideas, it’s the company that allows for the least amount of customizations that takes off first because they can understand the market faster than anybody else.

The third type is culture failure. This is about understanding the people on your team and their appetite for failure. Some team members could be eager to take big risks, but others might prefer a more conservative approach. Both types of people are valuable, but you have to know who’s ready for failure, and you have to make it cultural. We celebrated failure through what we called “Epic Fails Night,” which was like an open mic session with awards for failure. We made sure that people injected a bit of humor, which is a great icebreaker. We made sure the executives began so others felt more comfortable talking about their failures.

Handling failure when scaling products

Have you ever faced failure when scaling a product?

When we were working on scaling InfoScout, we used Vertica as our platform’s underlying technology, which was fast for one or two users but couldn’t scale as more users ran queries. When more users joined the platform, everything would come to a crawl. This occurred to a point where, on Monday mornings, people were missing reports and couldn’t get what they needed.

We spent an inordinate amount of data engineering time trying to get that solved. We evaluated different technologies and realized that the way we tested them led us down the wrong path. It was because we said, “Let’s run these queries based on what we have today,” but what we should have done is test real-world scenarios. We eventually brought in Snowflake to replace Vertica, and it simplified and scaled much better. The lesson here was about testing in real-world scenarios — we hadn’t built the load of multiple users running queries simultaneously into our test design, and that hurt our scalability.

Did you ever encounter a project where ideas were pushed forward without a solid business case?

When I was at P&G, it was the era of BI dashboards. Everyone wanted to build these dashboards, so we would spend weeks or months co-building with them, but then they’d say, “I want this drop-down,” or, “Can you put this chart in?” So, eventually, no one would adopt them.

These ideas or projects were emphasized by folks who were really into them, but often, success isn’t just addressing the needs of that power user; it’s how you get broader. How do you lift more people up with something like BI and data? That’s when we started talking to other stakeholders — not our users or the budget holders but their customers. This helped us build something that had wider value.

Building a resilient work culture through postmortems

What key elements do you look for when doing a postmortem?

I’ve found reading books on how prominent manufacturers solve problems incredibly helpful. There’s this great book called The Goal, a Theory of Constraints, which I consider to be the bible of the manufacturing world. It offers a thorough insight into managing complex processes and organizations. After-action reviews are also a great tool used by the military in the postmortem process.

But a lot of product managers use retro processes as part of their sprint plans. This retro approach is actually very effective for post-mortem and learning when people are unhappy, rather than doing an employee survey. You can use it to get anonymous feedback and then do that dot-voting exercise to help people agree on common themes. One tool that I’ve used and loved is Retrium, which facilitates retrospectives in a variety of guided ways.

I find that sometimes the simplest methods are the best for postmortems, like the Five Whys. “The product didn’t scale on Monday morning. OK, why? We had too many reports being run at the same time. OK, why?” I was definitely a huge advocate for those sessions and things like hack days.

The key to effective hack days is the consistency of them — the executive support and people being able to stamp their name on a potential success. Organizationally, they provide the support and funding for these risks. Nonetheless, it is important to work on ideas that may be a bit further out, or, my favorite, revisit ideas that have failed in the past because the market or the time wasn’t right.

How do you cultivate a culture that helps people get comfortable with failure?

When we did postmortems on a product, we were very objective and didn’t try to hide bad decisions that were made. Once people saw that they weren’t getting fired after the first failure and that they were still valued in their role, they understood we were rewarding the attempt and not just the success. Hack days are a great example of people sharing what they worked on and getting a fairly empathetic response. Share your hack day projects — even if they’re not successful — because people want to know.

When somebody says, “I had this idea that didn’t really work, but here’s what I learned,” one of the best things to hear is, “Oh wow, I probably would’ve done the same thing, maybe we can try this instead.”