Hi, there!
I’m Mandy, Principal Product Manager who takes product ideas from zero to adoption. Most recently, I grew a supervised agent from proof of concept to a beta validated product with 20% weekly adoption in 6 months. 15+ years in B2B, with a CS degree and MBA.
I’m most often brought in when the picture is fuzzy: I turn ambiguous or technical work into a clear frame everyone can act on, from engineers to the board.
Below, I share two case studies and several colleague quotes to give you a sense of how I get results.
Supervised agent for contracting businesses
I joined an engineering-led AI agent team and helped take it from proof of concept to validated beta product in 6 months.
Read on to see how I used scrappy evals to improve retention and output quality for a new nondeterministic product, one embarrassing shortcut that tanked a lot of first conversations, and how I enabled the entire 300-person company to participate in this critical strategic bet.
Opportunity
Companies across the trades use the company’s web and mobile app to manage their photo-documented projects, such as new home construction, commercial roof resurfacing, landscaping services, cleaning services, or apartment complex HVAC work. Those job site photos and related data hold the full history of every project.
The problem is that office managers spend more time than they’d like answering crew questions, chasing status updates for clients, managing subcontractor schedules, and finding good before & afters for their Facebook page. On top of that, field crew members need to be able to get answers when they need it, which might be on a scorching hot roof or in a dark crawlspace, where typing is impractical.
We built an agentic platform that begins as a supervised agent: a chat and automation layer on top of a jobsite context layer, so contractors can ask questions and hand off coordination work by voice or text.
The strategy behind why we chose this bet is confidential, so I’ll stick to what I did and what that enabled us to learn.
My role
Principal Product Manager for the agent aka AI platform team, made up of the VP of Engineering, a Sr. Director of Engineering, Software Manager, Software and Machine Learning Engineers, and a Product Designer. I was also supported by product marketing, product analytics, sales, support, and customer success. The team was engineering-led and moving fast.
My job was to get customer insights to the team, expand access (we doubled our goal), and turn “here’s what we shipped this week” into something the whole company could follow and plan around.
Actions & results
At a glance: from proof of concept to a beta product validated with thousands of companies and 20% weekly adoption in 6 months.
- Defined “good” for a nondeterministic product. I proposed outcomes (weekly return rate, task completion, sentiment) and tied targets to alpha, beta, and general availability gates.
- Built evals in stages. I started with scrappy manual offline evals that involved manual review and SQL select queries against production tables, moved to online evals using LLM-as-judge and error analysis, then graduated to Langfuse. Conversation error rate dropped 25% in 2 months, while beta access grew roughly 10x.
- Found the leak in the first conversation. Early on, 63% of people dropped off after their first conversation. I traced much of it to a confusing “new automation” shortcut. After the redesign, overall retention improved, and automation adoption nearly doubled.
- Listened to our customers. I conducted alpha user interviews and a synthesis of past user research, confirming demand and identifying top opportunities.
- Found viability. I proved we could drive feature adoption breadth, which is highly correlated with trial conversion. For example, through intentional Featured Actions, an alpha user created his first checklist with the supervised agent.)
- Made the work easy to trust across the organization. I communicated via weekly demo videos, a delivery plan that executives used for resourcing decisions, a live demo for all 300 employees, cross-functional ideation sessions, and go-to-market team transparency. Core workflows were transferred to 2 other product teams, with enablement in place for all 10 product teams to build on top of our AI platform.
“I so appreciate how you keep this team coordinated, pointed at the right things, documenting and celebrating it all. You are absolutely kicking ass! Working with you has been a delight!” —Jeff, VP of Engineering
What I’d tell you over coffee
I changed my mind about how fast to open up access.
A few months in, impressed by what the supervised agent could do, our CEO and CPO wanted the agent in front of as many customers as possible, as fast as possible. My partner, our Sr. Director of Engineering, and I were both cautious, especially after months of staring at conversation quality. Instead of charging ahead with orders or quietly dragging my feet, I said it out loud: “I think the team and you have different quality bars, and I want to make sure you can see the risk you’re taking on.” They said, “Yep, let’s do that.”
Then I did the homework. I dug through conversations to size the risk, and the data didn’t back up my gut. Our conversation error rate had dropped 25% in the previous couple of months. Also, thin project context was our weakest spot. We’d be adding brand new users without much project data, so context mattered a lot less than for established companies with years of job site photos and conversation history.
So I went back and said, “Oh. You’re right. I was so close to quality that I overestimated the risk.” We set up monitoring for platform scalability, the one thing that still scared us, and ramped from 2% to 100% of top-of-funnel accounts in under a week. As many as 33% of active new accounts were using the supervised agent. The CEO’s push turned out to be the right call.
I like being upfront when I’ve misjudged something. It makes it feel safer for everyone else to speak up, and being wrong early and cheaply is how you build a product that people like.
Pay ranges HR leaders use
Intro
I inherited a pay ranges feature that customers turned on but never really used, and I ended up replacing a very smart algorithm with a straightforward one.
Read on to see how I figured out why users were bailing, what it took to change a method designed by the company’s own compensation experts (including the CEO/co-founder), and why “simple” was the right answer.
Opportunity
The company’s product helped HR leaders make better compensation decisions, with machine learning doing some of the heavy lifting. Pay Ranges (as you’d guess: a minimum, midpoint, and maximum salary and equity percentage for each job) built off of proprietary market data were meant to be the centerpiece, allowing high-growth startups to win new talent while protecting their runway.
At a glance, the feature usage data looked great. Almost everyone turned on Pay Ranges. But what the analytics couldn’t show was that almost no one adopted them as their actual ranges for making compensation decisions. Onboarding conversations with our customer success (CS) team might drag on for weeks, and users quietly abandoned what we thought was our most valuable (and stickiest) feature.
The first version grouped similarly paid jobs together and smoothed the numbers using a method designed by our in-house experts. It was clever, and it worked well for the large enterprises they used to consult for. But it wasn’t working for our small customers.
My role
Senior Product Manager at a 40-employee Series A startup. I inherited Pay Ranges while it was in development and launched it, working with a remote team of US and Vietnam-based engineers and a designer, with support from product marketing, CS, and sales.
Actions & results
At a glance: With simplified Job-Based Pay Ranges, nearly 100% of new Pay Range customers adopted them, onboarding got days shorter, and follow-up support questions dropped 50%.
- Listened to real people and watched them get stuck. I ran 20 user interviews in my first 90 days and worked with CS to hear where onboarding fell apart and what users expected.
- Found the core problem. HR managers couldn’t explain our grouping method to executives and managers, and the results weren’t precise enough to trust, so it never made it past their desk. For example, she might get one set of ranges for both Quality Assurance Engineers and Software Engineers, who are typically paid differently, with midpoints that don’t match the numbers she sees in our market data lookup feature. Trying to address their confusion with clear copy further showed us where it was too complicated.
- Designed something simpler. I helped design a new algorithm that created simple job-based ranges with midpoints matching target market data (exactly what our customers asked for and were building themselves in spreadsheets!), plus new UI copy to explain it in plain language.
- Kept the experts in the loop. I shared what we were learning and measured everything against outcomes, not opinions. Almost every new Pay Ranges user chose the job-based ranges over the original grouped ones, so we knew we had a winner, and our (slightly surprised) in-house experts were just as pleased.
- Shipped it fast. The new version took a couple of weeks from concept to launch. CS reported a 50% drop in follow-up questions, and onboarding went from about a week to about a day.
“Mandy: You did it! Thank you for your leadership, inclusivity, thoughtfulness, communication and killer product/project management.” —Kate, Group Product Manager
What I’d tell you over coffee
This one felt controversial at the beginning. The original method came from our CEO and in-house compensation analysts, experts who had spent years in compensation consulting. They knew more about pay than anyone in the company, certainly more than me, and I was telling them our customers wouldn’t use their approach. But our startup customers looked nothing like the founding team’s former consulting clients.
What helped was not arguing about whether the calculation method was good. It was good! The question was whether a busy HR leader on a tight budget could explain it to their CFO.
The dashboard said Pay Ranges were a hit. Almost everyone had turned them on, so on paper we were winning. But turning something on and using it to set real pay are different things, and we had no clean way to measure the second one. So I went analog. I leaned on our customer-facing teams and asked users to show me what confused them.
What I carry forward is asking what a metric is actually counting before I trust it. The chart told me how many people turned Pay Ranges on. A customer saying, “wait, what does this mean?” told me why they stopped there. I want both: the numbers to show me where to pay attention, and the people to tell me what I’m looking at.