Priya Sharma

Product Philosophy

Every feature is a bet. Treat it like one.

Before anything gets built, I want to know: what's the hypothesis, how will we measure it, and what would make us kill it? At Cloudpath, I killed a feature the CEO had highlighted at a board meeting because the data showed 8% adoption. We redirected the team to automated commitment purchasing -- it hit 31% adoption in one quarter.

Customer discovery is not a phase. It's a practice.

I've conducted 150+ structured customer interviews across three companies. Not "quick chats." Structured programs with consistent guides, clear objectives, and synthesized outputs that actually change the roadmap. At my first PM job, there was no discovery practice at all. I built one from scratch. The interview template I created was still in use two years after I left.

Frameworks should clarify, not constrain.

I use RICE, ICE, opportunity scoring, jobs-to-be-done -- whatever fits the decision. But I don't worship any of them. The activation framework I defined at Cloudpath (Connected, Value Seen, Value Realized) became the primary lens for all product decisions. Not because it was clever, but because it mapped to how users actually experienced the product.

Selected Work

Case Study 01

Nexus Data · 2023-Present

Scaling a connector catalog without scaling the team

The Problem

50+ connectors in the catalog, but a 6-month development backlog. Enterprise customers kept requesting niche integrations -- industry-specific ERPs, regional payment processors -- that couldn't justify internal development time. Three competitors had launched partner ecosystems. We were falling behind.

What I Discovered

I interviewed 8 integration partners and 6 enterprise customers. Two key insights: partners wanted a typed SDK with clear abstractions, not raw API docs. And customers with internal platform teams were willing to build connectors themselves -- if they could own and maintain them privately. The path wasn't "build more connectors." It was "build the tools that let others build connectors."

What I Shipped

A 12-page product spec covering SDK architecture, partner onboarding, quality certification, and revenue sharing. I scoped the SDK to a 10-week build while handling documentation, partner outreach, and certification criteria in parallel. We launched a private beta with 5 partners, iterated through 3 breaking changes in the first month based on their feedback, then opened the program publicly.

The Outcome

14 third-party connectors published in 6 months. $1.2M in influenced pipeline in the first two quarters. Internal connector backlog shrank by 40%. The SDK became a sales differentiator -- our team started demoing the partner marketplace in enterprise deals.

14 partner connectors

$1.2M influenced pipeline

40% backlog reduced

Case Study 02

Cloudpath · 2021-2023

Killing a feature the CEO loved

The Problem

I'd shipped Commitment Advisor v1 -- a feature that recommended optimal reserved instance purchases based on cloud usage patterns. Six weeks of a 4-person team. The CEO had personally highlighted it at a board meeting. Three months later: 8% of users who saw recommendations acted on them. Engagement was declining week over week.

What I Discovered

Cohort analysis showed no measurable difference in retention between users who engaged with the feature and those who didn't. Then I interviewed 12 users who saw recommendations but didn't act. The core issue was trust: committing $50K-$500K in cloud spend based on an algorithm they couldn't fully audit felt too risky. They didn't want recommendations. They wanted the platform to just do it -- with guardrails.

The Hard Call

I presented three options to the CEO and CTO: iterate on v1 with transparency features, pivot to automated purchasing with approval workflows, or deprecate entirely. I recommended the pivot, backed by interview data and competitive analysis. The CEO had publicly championed v1, so this was not a comfortable conversation. But the data was unambiguous.

The Outcome

We deprecated v1. Automated commitment purchasing with configurable guardrails reached 31% adoption in its first quarter -- nearly 4x what v1 ever achieved. It became a key enterprise differentiator because competitors lacked guardrail flexibility.

8% v1 adoption (killed)

31% v2 adoption (shipped)

12 user interviews

Case Study 03

Cloudpath · 2022

Redesigning activation by defining it first

The Problem

Cloudpath tracked "signed up" and "paid" as the two lifecycle milestones. Nothing in between. When the CEO asked why signups weren't converting, nobody had a precise answer because nobody had defined what "activated" actually meant.

The Framework

I analyzed the highest-retention cohort against the highest-churn cohort. The behavioral sequence that predicted retention was clear: connect a cloud account, see $1,000+ in savings, act on a recommendation. Users who completed all three within 7 days retained at 82%. Users who didn't: 31%. I defined three activation stages -- Connected, Value Seen, Value Realized -- each with a behavioral definition, target conversion rate, and owner.

The Experiments

I ran 4 sequential A/B tests over 8 weeks, each building on the previous winner. Quick savings estimate within 60 seconds of connecting. Placement testing. "Top 3 recommendations" preview. Email notification timing. Each experiment ran for 2 weeks with a minimum sample of 150 users per variant. Every experiment was pre-registered with hypotheses, success metrics, and guardrail metrics.

The Outcome

7-day activation rate went from 34% to 51%. Time-to-value dropped from 6.2 hours to 2.8 minutes. The activation framework became the primary decision-making lens for the entire product team. Marketing adopted it to segment email nurture campaigns. The experiment series became the template for how the team ran experiments going forward.

34% → 51% activation rate

6.2hr → 2.8min time to value

Product Frameworks I Use

On discovery: I don't trust any insight from fewer than 8 interviews. Below that, you're hearing anecdotes. Above that, patterns start repeating. I aim for 12-15 per research question, then stop.

On prioritization: I build the scoring model fresh each quarter because the criteria change. Reusing last quarter's RICE weights is a shortcut that leads to stale priorities. The conversation about what matters now is the point.

On experimentation: Pre-register everything -- hypothesis, success metric, guardrail metric, sample size. If you decide what "good" looks like after seeing results, you're not experimenting, you're storytelling.

On killing features: Sunk cost is the enemy. I've killed features I personally shipped and championed. The Commitment Advisor v1 kill was uncomfortable, but 8% adoption after three months doesn't lie.

How I Work

Discovery

Structured interview programs, not ad-hoc calls. Consistent guides. Affinity mapping in Miro. Synthesized into themes that feed directly into prioritization. I've run 150+ of these across three companies. At Uplink, I built the practice from nothing -- 35 interviews that surfaced the product gap responsible for most competitive losses.

Prioritization

I build decision frameworks specific to the situation rather than applying RICE mechanically. At Nexus Data, I faced three competing demands with capacity for 1.5. I scored each on revenue impact, retention risk, engineering leverage, and strategic alignment -- then proposed a hybrid that satisfied all three stakeholders. The key is making the criteria explicit so the conversation is about the inputs, not the conclusion.

Experimentation

15+ A/B tests designed and run. Sequential testing when the space is large. Pre-registered hypotheses, guardrail metrics, minimum sample sizes. I'm as interested in the experiments that disprove the hypothesis as the ones that confirm it. Killing Commitment Advisor v1 was one of my best product decisions.

Technical Fluency

I write SQL daily -- complex joins, window functions, CTEs across PostgreSQL, BigQuery, and Snowflake. I understand REST APIs, webhooks, event-driven architecture, and CDC well enough to spec them, review technical designs, and debug retention drops alongside the lead engineer. I'm not an engineer, but I speak the language fluently enough to collaborate deeply.

Background

I studied Industrial Engineering at Northwestern with a minor in CS -- systems optimization, statistical methods, human-computer interaction. My capstone project was a scheduling tool for outpatient clinics that reduced simulated wait times by 14 minutes. I was VP of Projects for the Product Design Club and mentored through Women in STEM.

2023+

Senior PM, Nexus Data

Series C data integration · 220 people · Connectors Platform

2021-23

PM, Cloudpath

Series B cloud cost optimization · 130 people · Recommendations Engine

2019-21

APM → PM, Uplink

Seed-stage workflow automation · 40 people · Integrations

2019

Northwestern University

B.S. Industrial Engineering, Minor in Computer Science

Currently

Reading

Running a PM book club with friends. This month: Working Backwards by Colin Bryar. Last month's discussion on Inspired by Marty Cagan got heated when someone argued discovery sprints are cargo-culting. I disagree -- the problem isn't the sprint format, it's teams running them without clear hypotheses.

Cooking

Slowly reverse-engineering my grandmother's dal makhani. She never wrote anything down, so every batch is part memory, part experimentation.

Thinking about

How developer platforms create leverage without losing quality control. The SDK work at Nexus Data taught me that the hardest part isn't building the platform -- it's building the developer experience around it. I'm interested in how the best platform companies solve this.

Get in Touch

I'm exploring product roles in B2B SaaS, data infrastructure, developer tools, and AI. Open to remote, hybrid in NYC, or relocating to SF or Seattle for the right opportunity.

hello@priya-sharma.com