Productside Stories

AI Product Discovery and PM-Designer Collaboration with Snehal Ghag

Featured Guest:

Snehal Ghag, Design Manager for AI Products | ServiceNow
10/06/2026

Summary

In this episode of Productside Stories, Rina Alexin sits down with Snehal Ghag, Design Manager for AI Products at ServiceNow, for a practical, experience-backed conversation about what product discovery looks like when designers are in the room from day one, and how AI is reshaping every step of that process.

Snehal’s background spans enterprise and consumer product across Amazon India, Salesforce, and ServiceNow. At Amazon, she was part of the core team that launched the platform in India, navigating the complexity of multiple languages and cultures. At Salesforce, she worked on Einstein Analytics. Now at ServiceNow, she leads AI-native product design and has built a discovery workflow that treats AI as a continuous thinking partner, not a process step.

The conversation covers the PM-designer partnership as a form of co-parenting, where both parties discover the problem together before anyone picks a path. Snehal explains how her team feeds real user research into AI to build personas, stress tests those personas against frustrated and novice user scenarios, uses vibe prototyping to put multiple design options in front of users in a single day, and validates everything with real usability testing before a single line of code gets written. She closes with a deceptively simple starting point for product managers who haven’t yet built the habit: keep an empty chair for your AI partner, and use it to pressure test your PRD before you share it with anyone else.

Key Takeaways

PM-designer collaboration is basically co-parenting.

  • Snehal compares the product manager and designer partnership to new parents raising their first child: you figure out the problem together before anyone picks a path. Leave design out until the end and rework sends you the bill. The best partnerships think the problem together, discover it together, observe it together, and synthesize it together before a single solution is proposed.

Synthetic personas are great sparring partners, terrible stand-ins.

  • Her team builds AI personas from real user research, then sets the grumpiest ones loose on every design. Stress testing against frustrated, busy, and novice users surfaces the edge cases that a single-perspective design will always miss. Synthetic users never replace real ones, though. Usability testing still happens before anyone writes code.

Vibe prototyping only works if you’ve done the homework first.

  • Vibe coding can get several design options in front of users in a single day. But Snehal spends 80% of her team’s effort in the problem space before touching a prototype. Speed without that foundation just gets you to the wrong answer faster.

Discovery is the new bottleneck, and AI is the best tool to widen it.

  • Andrew Chen observed that AI has made building so fast that deciding what to build is now the constraint. Snehal agrees, and her team’s response is to use AI to go deeper in the problem space, not to shortcut it. More scenarios, more user journeys, more perspectives explored before the solution conversation even starts.

AI should be a habit, not a process step.

  • The empty chair Amazon kept for the customer now has a new occupant. Snehal’s advice for PMs just starting out: before sharing a PRD with anyone, ask AI how your designer will react to it, how your engineers will react, how your sales team will react, and how it will land in different locales. Keep the decision with you. Use AI for the perspectives you’d otherwise never hear.

Chapters

  • 00:00:00 – Introduction to Snehal Ghag and Episode Focus
  • 00:01:29 – Snehal’s Career Journey: From Artist to AI Design Leader
  • 00:05:40 – Why Snehal’s Background Shapes Her View of Product Collaboration
  • 00:07:08 – PM-Designer Collaboration as Co-Parenting: The Partnership Model
  • 00:09:32 – Why Design Gets Brought in Too Late and What It Costs
  • 00:14:44 – Discovery as the New Bottleneck in AI-Powered Development
  • 00:16:23 – How ServiceNow Uses AI to Analyze User Research and Build Personas
  • 00:20:47 – Vibe Prototyping: Testing Multiple Design Options in a Single Day
  • 00:23:41 – Synthetic Personas Done Right: Stress Testing, Not Replacing, Real Users
  • 00:28:21 – When Synthetic Data Goes Wrong and Why Usability Testing Still Matters
  • 00:31:01 – Business Impact: Faster TAT, Continuous Learning, and System Thinking
  • 00:35:23 – Where PMs Should Start: Keep an Empty Chair for Your AI Partner
  • 00:39:43 – Connecting with Snehal and Closing Remarks

Why Listen to This Episode?

This one is for you if:

  • Your designer only hears about features at the “make it pretty” stage, and rework keeps eating your roadmap
  • You want AI in UX research but don’t fully trust synthetic users (good instinct, and Snehal explains exactly where to trust them and where not to)
  • You’d like to see how ServiceNow uses AI as a thinking partner to pressure test PRDs before stakeholders get the chance
  • Your product discovery process sprints straight to solutions (spoiler: most do)
  • You want a concrete starting point that requires no new process, no new tool, and no permission from anyone

Introduction to Snehal Ghag and Episode Focus

Rina Alexin | 00:00:01 – 00:01:29

Hi everyone, and welcome to Productside Stories, the podcast where we dig into the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rina Alexin, CEO of Productside, and today I’m talking with Snehal Ghag, a design leader with over 14 years of experience across enterprise SaaS, e-commerce, and AI. She’s currently the Design Manager for AI Products at ServiceNow and held previous roles at Salesforce and Amazon.

Today we’re going to talk about how to partner between product managers and designers, how to improve that relationship, and how her team is using AI to speed up the discovery process. Welcome, Snehal.

Snehal Ghag | 00:00:47

Hi, Rina. Thank you so much for inviting me. It’s a pleasure to be here.

Rina Alexin | 00:00:53

Of course. For this season of Productside Stories, we’re bringing on various voices across design, engineering, and product marketing, because as AI changes the game for product management, it’s changing product development in general. I’m excited to hear your perspective on AI and bring in the voice of design, particularly when it comes to discovery, which requires really strong collaboration between design and product. My first question is your own story: how did you end up in design?

Snehal’s Career Journey: From Artist to AI Design Leader

Snehal Ghag | 00:01:36 – 00:05:40

My story is kind of a roller coaster. I started as a designer, and before that I was an artist. I’m always an artist. I took my design education from IIT Guwahati, earning a Masters of Design, where I learned a lot about interaction patterns, user journeys, and user behaviors, and how to build experiences.

My first job at Clarisse Technologies exposed me to product development cycles, where I learned from senior designers how to build experiences for product. At that time we were building products as the market shifted from screens and laptops to mobiles, which was an interesting area.

Then my first job at Amazon India took me into real design thinking, because Amazon was planning to launch in India for the first time and I was one of the core members of that team. We started by exploring the problem areas and talking to users. In India there are multiple languages and multiple cultures, and building a product experience for that context was genuinely challenging.

“I spent like five years in Amazon working from customer side to seller side for prime customers. Most of my work was around how users search in India with their local languages on Amazon as a global product.”

From there I started building automations, recommendations, and search experiences, and I slowly started exploring the power of automation. After five years at Amazon, I moved from the consumer world into enterprise, which is where I ended up at Salesforce. There I worked on analytics platforms, including Einstein Analytics, which deepened my understanding of how recommendations surface and how to build logic behind what users see on a dashboard and want to act on. That made me much more curious about LLMs and AI.

That curiosity led me to a course in AI leadership when I joined ServiceNow, studying with Texas University on the foundations of AI and how leaders leverage AI in product development. Eventually I landed in my current role, which is exactly what I had been working toward: AI product management for design.

Why Snehal’s Background Shapes Her View of Product Collaboration

Rina Alexin | 00:05:40 – 00:07:08

Throughout your background, even though you started as an artist, everything you just described had a lot to do with understanding customer needs, which is exactly what great product managers need to be focused on. I’m hearing from your background why you would bring a really valuable voice to this conversation: you understand that something has to look good, but it has to look good with purpose. It has to make things easier for the user.

Because of that understanding, you would naturally build a strong relationship with product managers. How do you actually create that kind of strong relationship? What advice do you have for product managers who don’t currently have that with their design counterparts?

PM-Designer Collaboration as Co-Parenting: The Partnership Model

Snehal Ghag | 00:07:08 – 00:09:32

I look at product management and design as a partnership like a husband and wife raising their first child. This is something where they are thinking about the problem together, not linearly. They are looking at the problem simultaneously.

They are discovering the problem together and they have questions: “This is new to me, how can we solve this? This is something I found, did you also observe it?” That’s how the best partnerships I’ve had with product managers have worked. And that’s how I believe great partnerships come together.

“They think the problem together, they discover the problem together, they observe the problem together, and also they synthesize the problem together before even jumping to the solution.”

They want to grow their product the way they want to grow their child really well. They look at what the implications would be if the solution goes path A versus path B, and they let the product come out in its own right way. They show the product to users very early, they listen, they synthesize, and they don’t want to manipulate the problems together.

A few of my best professional friendships have come from this kind of relationship, because we could make those decisions at the right time and own them. You also have to make sure your child marries well in society. The product has to get adopted in the market well too.

Rina Alexin | 09:32

I’m going to use this analogy going forward. I absolutely love it. You’re right: if you’re thinking about it as growing a child, you have to start really early. And a lot of times when I talk to people with issues in their product development process, it’s usually because design is being involved way too late.

Why Design Gets Brought in Too Late and What It Costs

Rina Alexin | 00:09:32 – 00:10:59

Rather than involving design at the start and figuring out what the product should actually look like, organizations often bring design in when they’re already in solution-defining mode, or in the worst cases, the solution is already defined and design is asked to make it work and look user-friendly. Why do you think that happens?

Snehal Ghag | 00:10:59 – 00:14:44

I’ve observed that in some organizations, design is seen as bolted-on experience. Product teams make decisions without design in consideration from the start, and the result is directive design rather than collaborative design or a true partnership.

The impact of this is ultimately a cost: cost to the company, cost to the teams in their time and effort. It becomes expensive collaboration when design is brought in late.

The core problem is that product managers and designers bring genuinely different things to the table:

  • Product managers think from a hypothesis point of view. They are trained to create hypotheses, plan, execute implementations, and develop go-to-market strategies.
  • Designers are more empathetic to users. They are closer to the users and more oriented toward questions: What is the user actually saying? What are the edge cases? What is another way of looking at this? How can we solve this without jumping to a solution?

Designers are well trained in thinking about user mindsets, pain points, and personas. Design thinking methods leverage that from day one. Creating a hypothesis is also, to some extent, thinking of a solution too early. The questions designers bring are: Is this problem really occurring? Is this the most important problem to solve right now?

“Product managers are very passionate about their problem understanding, their hypothesis creation, planning, executing implementations. But whether that problem is really there, or whether that is the most important problem to solve, that is where product designers contribute.”

For product managers who have not been partnering with designers from the start, they are losing the opportunity to have a sounding board: a collaborative partner who can take up certain areas, especially understanding your users’ mindsets and questioning whether a problem is truly worth solving.

Discovery as the New Bottleneck in AI-Powered Development

Rina Alexin | 00:14:44 – 00:16:23

What I’m hearing is that bringing a designer into the problem space earlier gives you a sounding board trained to poke at the problem, to de-risk the ultimate solution, and to ask whether this problem is truly painful and worth solving. That’s exactly why discovery is the focus here.

Andrew Chen made the observation that because AI engineers can build so much faster, the new bottleneck is no longer how to build something but deciding what to build. Discovery is now the constraint. Is that true in your experience? Can AI actually help reduce that bottleneck?

How ServiceNow Uses AI to Analyze User Research and Build Personas

Snehal Ghag | 00:16:23 – 00:20:47

If I walk you through the product development lifecycle process at ServiceNow, what we practice day to day starts with looking at problem areas together: product owners, product managers, product designers, and engineers, all in one space. We observe problem areas together. Once we’ve narrowed down to one, we think about how to diverge into multiple sub-areas.

In a traditional process, I would have taken that problem area to six to eight customers and evaluated it through user research. Now, with AI:

  • We take the user research recordings that are already coming in and feed them into AI, specifically Claude Projects
  • Users don’t always state their problems directly. They express concerns, frustrations, and desires that require reading between the lines
  • We ask AI to think through those recordings from the perspective of a frustrated user, a novice user, or a repeat user who doesn’t want to see the same content again
  • This gives us more scenarios, more backgrounds on the problem area, more ways to stay in the problem space longer

“We try to be in the problem area more like 80% of our product development, and solution-analyze it for like 20%.”

AI-native thinking at ServiceNow means we use AI from day one as a thinking partner. We give it more scenarios, more questions, and we elaborate on the problem area during discovery. Product managers come with the problem statement, not the solutions. We build personas with AI. We test those personas with stress testing: how will this persona react to this kind of solution? How can we build different user journeys? What does the happy path look like versus the frustrated path versus the short, task-oriented path?

The goal is to give AI enough scenarios that it helps us read between the lines, think between the gaps, and offer more options for exploration. Discovery is more of an exploration, and that is how we are using it.

Rina Alexin | 20:47

So you’re taking real user research, feeding it through AI, building out personas that you can then stress test different scenarios against, and querying an AI representation of your user base. Do you validate with real users at some point later in the process?

Snehal Ghag | 21:31

Yes. Absolutely.

Vibe Prototyping: Testing Multiple Design Options in a Single Day

Snehal Ghag | 00:20:47 – 00:23:41

Once we have various user journeys, we create multiple design options. For that, we also use AI for prototyping: quick mockups that give us multiple pros and cons for different options. That makes our final design decision much more solid.

This is how we use AI across the entire product cycle. Once we have early designs, we show them to the users who originally surfaced the problem. They get to see the solution from multiple perspectives. Those multiple perspectives generate feedback that we feed back into Claude Projects, asking it to give us rationale on what would work as a pro and what the cons are that still need to be addressed.

 “With vibe coding, you can actually create three different ideas together. And it’s never a harm to show all your ideas to the users.”

What this gives you practically:

  • Multiple design options created in a single day instead of one sequential prototype over weeks
  • A-B testing or side-by-side option presentation to users, which produces richer comparative feedback
  • More options evaluated early before any implementation cost is incurred

Rina Alexin | 22:53

So you create interactive personas, validate various design options through vibe prototyping, and receive richer feedback than a single concept review would generate. I’ve been hearing from multiple teams that vibe prototyping shortens the discovery process significantly, both in terms of the time to build the prototype and the quality of feedback received. Are you finding the same?

Synthetic Personas Done Right: Stress Testing, Not Replacing, Real Users

Snehal Ghag | 00:23:41 – 00:28:21

Quality improves not from vibe coding once, but from creating multiple options and showing them together. And in parallel, we use personas to create synthetic user samples so that before going to formal usability testing, we can evaluate our designs against these different personas. Usability testing is both cost-intensive and time-consuming. With AI, we can create synthetic samples and evaluate designs against those first.

Rina Alexin | 25:10

Talk to me about synthetic data. Something I always come back to is that synthetic data is based on data inputs you already know. Wouldn’t that just amplify what you already know rather than helping you discover something new?

Snehal Ghag | 00:25:51 – 00:28:21

The way we use synthetic data is not about creating fake data. You create a persona with AI, then validate that persona with real users. The scenario we address is this: even if you have four users to test with, testing with only four is not a full validation. So you take those four actual users and elaborate their personas into 40 variations with different behaviors, different demographics, and different contexts.

For example: one user who is a 40-year-old working professional. What would 10 more users of a similar demographic but with different individual behaviors look like? You feed those behavioral variations in, and then you stress test your designs against that expanded sample.

Where this approach is most powerful:

  • Stress testing negative scenarios: the frustrated user, the busy user, the user who is not happy
  • Surfacing edge cases that a single-perspective design always misses
  • Getting 360-degree feedback when you don’t have the time or access to talk to 40 individual users

“Synthetic data, we see, is used for more of the negative use cases: if the user is not happy, if the user is frustrated, if the user is busy. All these behaviors you feed in for stress testing, which makes you think more beyond your limitations.”

The important caveat: synthetic data used without real pain points and real behaviors from actual users produces single-perspective solutions that can fail. It is a complement to real user research, never a replacement.

When Synthetic Data Goes Wrong and Why Usability Testing Still Matters

Rina Alexin | 00:28:21 – 00:30:58

That’s a very strategic way of using synthetic data: stress testing against negative user feedback to pressure test your thinking rather than simply validating what you already believe. Has that approach ever led your team down a wrong path? Have you had an experience where the synthetic data showed you one thing and real users showed you the opposite?

Snehal Ghag | 00:29:03 – 00:31:01

Not at ServiceNow, but at a previous organization we tried starting completely with synthetic data sets that had no foundation in real pain points or real user behaviors. The result was single-perspective solutions that didn’t reflect what users actually desired or how they actually behaved. Every user has different desires, and if you’re not bringing those real inputs into your synthetic data, you end up with experiences that can fall flat.

The save in that situation was usability testing. We ran usability tests where we asked users directly: “Does this relate to you? Does this reflect your experience?” And that feedback told us what the synthetic data could not.

The lesson I’ve carried forward:

  • Synthetic personas must be built on real user research inputs, not invented from scratch
  • Usability testing before implementation is non-negotiable
  • The cost of skipping it shows up later as the cost of rebuilding, redeveloping, and delaying features

“A lot of teams avoid usability testing before implementation. Then the cost of rebuilding, redoing, redeveloping, and delaying features comes into the team’s cost.”

I prefer a mix of traditional design practices and AI-augmented design practices together. AI accelerates exploration. Usability testing validates reality.

Business Impact: Faster TAT, Continuous Learning, and System Thinking

Rina Alexin | 00:31:01 – 00:35:23

In terms of using synthetic data and AI to improve the quality of your discovery process, what have you seen in terms of business benefits? Is it primarily validating more features faster, or are you seeing metrics like reduced churn actually move?

Snehal Ghag | 00:31:48 – 00:35:23

The most important metric is TAT, the turnaround time. The entire product development lifecycle becomes shorter with AI capabilities: automating, synthetically creating, diversifying, and exploring user behaviors in ways that human capacity alone cannot reach.

What this has created in practice:

  • Agentic personas that have ongoing context about what products I’m building and can give me real-time feedback on demand
  • On a single click, I can hear from my frustrated user or my satisfied user and get their reaction
  • Brainstorming sessions that are more exploratory and more elaborative without being blocked by time constraints
  • Continuous learning and continuous reasoning built into the daily product workflow

“These are the leverages that you should practice every day in your product development cycle. Use AI’s power of continuous learning, continuous reasoning, so that your brainstorming sessions are more elaborative but also shorter from a time perspective.”

The second major benefit is systems thinking. AI brings the background of a system to the surface very quickly. It lets you predict what might happen to a feature or capability before you commit. Every designer and every product manager should be a systems thinker, and AI helps develop that capacity.

Rina Alexin | 34:50

What you’re describing is that creating frustrated personas gives product managers a way to have the hard conversation they know they need to have, but in a lower-stakes environment first. If it’s an AI partner representing a frustrated user, it feels easier to explore that friction, which means you’re more prepared when you encounter it with real humans.

Where PMs Should Start: Keep an Empty Chair for Your AI Partner

Snehal Ghag | 00:35:23 – 00:39:43

Rina Alexin | 00:35:29

If you were talking today to a product manager who hasn’t really used AI in their discovery process, where should they start?

Snehal Ghag | 00:35:44 – 00:39:15

At Amazon, the practice was to keep one empty chair in every meeting for the customer. These days, you should keep one empty chair for your AI partner. That is the one who will bring more clarity, better experiences, and greater perspective to the room.

And this should not be a process. Working with AI should not be a linear step in a waterfall. It’s a habit you build for your own benefit.

For product managers just starting out, a simple first step:

  • Once your PRD is ready, before sharing it with anyone, ask AI how your designer will react to it
  • Ask how your engineers will react to it
  • Ask how your sales team will react to it
  • Ask how it will land across different locales and contexts

This is early feedback AI can give you before any human reads it. Keep the decision-making with you. Use AI for the perspectives.

The second practice: when you’re in the problem area, use AI to explore the problem more deeply before jumping to the solution. We keep problem statements concise, one-liners, because we want clarity. But our understanding of that problem should read like a novel.

“Problem, we keep it one-liner to make it very concise. But when we look at the problem, it should be like a novel. 80% of our area of work should be being in the problem, not jumping to the solution.”

For new product managers especially: use AI to discover the problem more completely before figuring out the solution.

Rina Alexin | 38:24

I love that advice. Behind me you’ll see the Productside Blueprint: that large light blue circle is the discovery process we want people to spend more and more time in. I’ve heard of people creating AI boards of directors with famous CEO personas. But what you’ve just described, a board of stakeholders in AI that you can use to stress test your thinking and improve your communication, is something I really want to encourage people to try.

Snehal Ghag | 38:50

Yeah, AI can really help stress test our thinking in so many different ways.

Connecting with Snehal and Closing Remarks

Rina Alexin | 00:38:53 – 00:39:43

Snehal, I so enjoyed our conversation. Thank you for sharing your great advice and your amazing analogies throughout. How can our listeners connect with you after this episode?

Snehal Ghag | 00:39:15

I’m always open for product discussions on LinkedIn. They can reach out to me directly. Any designers, product managers, even engineers: I’m a builder, and I love being a sounding board. A quick connect on LinkedIn is the best way to reach me.

Rina Alexin | 00:39:43

We’ll include your LinkedIn in the description for this episode. And thank you all for listening to another episode of Productside Stories. If you liked today’s conversation, please don’t keep it to yourself. Share it with a friend and make sure to subscribe so you don’t miss a future episode. I’m Rina Alexin, and from all of us at Productside: let’s do product better, together.