Director of Product · San Diego, CA

I'm the technical glue on product teams.

I'm Cole Parsons, Director of Product at QuinStreet / Modernize Home Services. Stakeholders usually know what they want. I work out the smallest technical version that proves the idea and where it's likely to break, then explain it to the engineers who have to build it. These days I build a lot of the prototypes myself.

See the work Get in touch

01 · About

How I got into product

Portrait coming soon

I went to Purdue for aerospace engineering and found out pretty quickly that physics is hard. I could do it. I just didn't want to do it for a living. One summer an internship put me in a business-analyst seat next to a product team, and one of the developers offered to teach me HTML, CSS and JavaScript for an hour a week. We kept that up for about twelve weeks.

I switched to economics with a concentration in management information systems. Since then I've done QA automation, business analysis at a startup, and two associate PM jobs in Austin, and I've sat close to engineers in all of them. I joined Modernize in 2022.

Modernize is a lead-generation marketplace for home services. If you've heard of Angi, it's the same idea. For most of my time there, if something was on modernize.com, my team owned it. In 2026 I became Director of Product and moved over to our paid-media platform and our applied AI work. One PM reports to me.

Day to day, that means a lot of asking about the case nobody has scoped yet, and a lot of SQL to check whether a number means what we think it means. I write decisions down in shared docs, because our engineers and QA are spread across the US, India and Mexico, and nobody should have to wait for San Diego to wake up to get an answer.

  1. 2026 →
    Director of ProductQuinStreet / Modernize

    Our paid-media platform, applied AI, and the plan to move an acquired company's core workflow onto our systems.

  2. 2024–26
    Senior Product ManagerQuinStreet / Modernize

    Most of modernize.com: lead forms, contractor profiles, local search pages, cost calculators and the B2B sites.

  3. 2022–24
    Product ManagerQuinStreet / Modernize

    Consent compliance, contractor tools, and a messaging migration that turned into a compliance project.

  4. 2021–22
    Associate PMPetDx · Austin

    Ran NetSuite and Salesforce implementations at the same time, plus integrations with about a dozen other systems.

  5. 2021
    Associate PMVitu · Austin

    Product owner for an international .NET/Angular team building electronic titling and registration software for Texas.

  6. 2017–21
    Internships and BA workBefore product

    Engineering and QA internships, including test automation in C# and TypeScript, then business analysis at a low-code startup.

02 · Skills

What I'm good at

Each skill has an example from my work. The bigger projects are in the next section, so most of these are smaller moments from other projects.

Systems and integrations

  • Changing a data model without breaking what depends on it

    Regional contractor profiles were getting flagged as duplicate content. The quick fix was to reuse an existing canonical URL field, but other systems already relied on it. I spec'd a separate, nullable field just for SEO.

  • Integration contracts

    For an acquired site's contractor listings, I wrote the contract between matching, our profile service and the marketplace. Asking for "the first profile for this vendor" returns the wrong one for clients with several, so requests carry vendor, trade and campaign type. We reused the pattern for local search.

  • Failures nobody sees

    Some ad blockers treat our marketing-automation form endpoint as an ad and drop the submission without an error. I had us measure how often that happened before deciding whether to fix it.

Data

  • SQL

    Before we invested in contractor reviews, I queried how many profiles had a Google review score linked. It was about 41%, averaging 3.18 out of 5. That became the baseline for the reputation work.

  • Definitions

    While writing BI requirements for a duplicate-leads report, I asked which timestamp counts as "lead created." The vendor checked and found three different lead-age values in its own data.

  • Reading test results

    A test on an acquired site looked like it had sunk conversion. A BI partner and I found the drop started three or four days before the test, while search volume was falling. We restarted it, and I wrote a checklist for auditing test winners that the team has reused since.

Building with AI

  • Prototypes

    I build working prototypes with Claude Code. Claude writes most of the code. My part is the design and checking that it works. One coverage-alert prototype with a human approval step turned into the requirements doc engineering wrote tickets from.

  • Deciding where the model goes

    I try to use AI to build the automation, rather than have it be the automation. In a lead-gen analysis skill I built, a script calculates every number, and the dashboard re-checks each figure the model quotes and marks it right or wrong.

  • Picking a first use case

    Our first production AI project keeps contractor promotions up to date. An engineer built it. I picked the use case and set up the measurement. Coverage went from 50 clients updated by hand to more than 275, for about $20 to $50 a month.

Running the work

  • Scoping in phases

    When we turned an analyst's weekly spreadsheet into software, phase one took the ad platform's CSV as a manual upload with no API, and the spec said not to touch her live files. The web app comes later.

  • Sprints

    I've run 100+ two-week sprints with engineers and QA in three countries. The team once estimated that about a third of a quarter's capacity went to unplanned work, so I proposed that new requests need VP sign-off and go in a change log.

  • Reporting misses

    I reported our AI chat agent at about 60% of its revenue goal, and wrote down that one analytics tool counted 90 leads from it where another counted 20.

Tools Claude Code, Cursor, SQL (Redshift), Tableau, Heap, server-side GTM, Figma, WordPress, Jira, Confluence, Notion, Miro

03 · Work

Selected projects

The first four show most of what I do. The last one is the project I'd run differently if I did it again.

Platform migration · 2026 · Requirements and architecture lead

Moving an acquired company's workflow onto our platform

QuinStreet acquired HomeBuddy, and about 300 of its client accounts are moving onto our systems in batches over three to four months. Every week, HomeBuddy's client ops team builds around 150 ZIP code targeting groups that media buyers load into the ad platforms. Leadership made that process a launch gate: no client moves until it works on our side. I own the requirements.

I interviewed client ops, media buying, HomeBuddy's analyst and engineers on both platforms, and wrote up about 70 group definitions, 45 business rules and 43 edge cases. The head of client ops said my version of their process was about 90 to 95% right. Then I walked all 48 steps against our paid-media platform. None of them worked as-is.

The hard part is the stretch when some of a group's campaigns are in the old system and some are in ours. Leadership didn't want a feature that reaches into both, so our platform exports its half and client ops merge it with the legacy half. I worked out which steps are safe to run on each half and which have to wait for the merge. Overlap counts are the clearest case. A ZIP with two old campaigns and two new ones has four overlapping campaigns, but each system only sees two. I also split the build into two tiers, so the February deadline doesn't depend on the budget-cap model, which is still being designed. The first batch is planned for early 2027.

  • Fit-gap analysis
  • Data contracts
  • Cutover planning

Platform · 2023–25 · Product owner

Turning contractor pages into a shared service

Contractor profiles (logo, bio, photos, reviews, promotions) started as a page homeowners only saw after we'd matched them with a contractor, so nobody had much reason to invest in them. Then the FCC's consent rule looked like it would make homeowners choose contractors before submitting a lead, and profiles suddenly needed to be good.

Over about two and a half years, my team of two back-end engineers, a front-end engineer, QA and a designer turned them into a service that five products read from: the homeowner dashboard, our organic pages, local search, an acquired site and a new contractor-facing editor. Along the way we added lookup APIs, a daily job that syncs profile status with the marketplace, review sources beyond Google, and promotions.

For the next version of the marketplace, I designed the data model as client, then vendor keys, then services, with optional overrides per campaign. A profile resolves from campaign to service to a global default. Geography stays in the marketplace, which removes the need for a separate profile per region. Those copies were most of the sprawl.

  • API and data model design
  • Many downstream consumers
  • SQL audits
  1. Campaign override
  2. Service profile
  3. Global default
  4. 5 products read from it

Integration · 2023 · Product lead

A messaging vendor switch that turned into a compliance project

We have a product that texts and emails homeowners on a contractor's behalf as soon as a lead comes in. In 2023 we moved it to a new messaging vendor, right as US carriers were tightening the rules for business texting. Partway through the launch, our account manager at the new vendor was laid off.

I changed the launch to a soft launch for new accounts only and wrote the go/no-go rule down ahead of time: if the vendor couldn't confirm our numbers were pending registration by noon on Friday, we'd suspend. Delivery on the unregistered numbers was around 30%, so we rolled texting back to the old provider, kept email running, and I briefed the account managers.

Then I got past general support to the vendor's compliance team and found the real reason our registration was rejected: consent-sharing language in our privacy policy. We switched registration routes, registered five accounts and then ten to learn the process, and moved contractors over one account at a time, each only after its number was approved.

  • Vendor integration
  • Rollback planning
  • Carrier compliance
  1. Soft launch, new accounts only
  2. ~30% of texts delivered
  3. Roll back by the agreed rule
  4. Fix registration
  5. 1 account at a time

Applied AI · 2026 · Builder and PM

A research agent its main user stopped using

Our top enterprise seller was spending 10 to 15 hours a week researching accounts. I built a Claude Code plugin that writes account briefs, maps decision-makers and runs market scans, with the research split across parallel sub-agents. Every claim has a source and a confidence label.

He used version one five or six times, then went back to the Claude project he'd set up himself. His went deeper on people, and mine was skimming search results and sometimes returning executives who had already left. He once found a CEO that a brief missed, someone who used to run a former client's company. His email to that CEO was opened 18 times and answered within two days.

So I sat with him and wrote down how he decides who to contact and in what order. That became the design for version two. A person needs two independent sources before they get ranked, a profile of the wrong person counts as a hard failure, and an eval set targets 90% accuracy on identifying CEOs and board members. I also said no to using his personal LinkedIn login for scraping.

  • Agent design
  • User research
  • Evals
  1. Verified2+ independent sources
  2. Likely
  3. Inferred
  4. Unknownasks instead of guessing

Local search · 2024–25 · Product lead

Local search pages that didn't convert

The idea was a local search engine for home services. Think Kayak, but for finding a roofer near you. I specced a template system that renders thousands of trade and city pages, with fallbacks from location to keyword to trade so missing data doesn't turn into thin pages. Cities are grouped by media market, because one ZIP code per city breaks in metros where a suburb is really part of the bigger city. I also changed lead attribution so we could track where traffic came from separately from which page converted it, and the rest of the site adopted that pattern.

Listings launched in April 2025. By August, conversion was down 36% and only about 600 of the pages had been indexed. Getting click tracking to work with the listings integration alone took about three months. In November I used Claude Code to go through 40 meeting transcripts from the project. It found six places where a requirement turned into a bug, and one of them was mine: I'd committed to an integration before I understood its architecture. The review ended with nine recommendations, including a feasibility check with engineering before a spec gets written.

  • Programmatic SEO
  • Attribution
  • After-action review
  1. 40 meeting transcripts
  2. 6 requirements that became bugs
  3. 9 recommendations

Smaller projects

Conversion data for Google

I scoped a lead-level table for Google's bidding to sit next to an existing real-time feed. Most of the work was definitions, like what one row means and keeping revenue separate from conversion value. Google only gets click IDs and hashed contact info. When engineering pushed back on my architecture, I checked my notes and found Google hadn't said what I thought it said. We went with a hybrid.

FCC consent rule

In late 2023 the FCC voted to require consent for each individual company. I turned the ruling into requirements and a consent design, and got legal to approve or reject seven checkbox mockups. The rule never took effect. The redesigned form kept an exit step that brought back 7.3% of people who were leaving in its first few days.

Spreadsheet to software

Handing an analyst's weekly pacing spreadsheet to engineering, I found Connecticut ZIP codes with no media market, a status that could never be reset, and a revenue-per-lead comparison that divided by ZIP count instead of lead count. All three went into the plan before anything was automated.

Coverage history

A ticket for coverage history had been narrowed to logging alert emails. Emails show what changed, but they can't tell you what coverage looked like last Tuesday. I proposed saving each run's coverage file to S3 so we didn't need new tables, and point-in-time snapshots went into V1.

Cost calculators

We lost the data source behind about 15 cost calculators and had to rebuild them on a new API quickly. Later I designed an LLM-based estimator with a ZIP-level cache and a static fallback, projected to cost $4 to $22 a month to run.

Duplicate leads

The plan was to reject duplicate leads automatically. An analyst found that some of them still convert, so we changed course: flag the lead, follow up with the source, and reject only if nothing improves.

Clients, vendors and internal systems are described generically. I'm happy to go into more detail in a conversation.

04 · Questions I ask

Questions that changed the plan

A few things I've asked in planning and design reviews. Where someone else spotted the problem first, I've said so.

Q1The churn flag fires on 62% of calls. How many are real?

A vendor's keyword-based indicator flagged possible churn on 62% of our recorded calls. I built an AI call-insights prototype to check, and about 1 in 12 flags was a real churn moment.

The prototype is now on the AI team's backlog to be built properly.

Q2What happens to a campaign that's over budget?

The draft rule dropped any campaign over its weekly budget from the targeting groups. Matching doesn't work that way. Above 100% a campaign gets deprioritized, but it still gets leads as the only buyer in a ZIP until it reaches 130%.

I wrote the requirement as "include a ZIP if at least one buyer is under 130%." The engineers in that session confirmed a few related gaps.

Q3What does a failed refresh look like?

Our coverage alerts only fire when something changes. Our ops lead noticed that this makes a failed refresh look exactly like a quiet day.

I asked engineering for a prevention plan and split the work into two alerts, one for refreshes that fail and one for pushes to publishers that fail.

Q4Where does one budget turn into two invoices?

During the HomeBuddy migration, a client's budget could end up split, with a monthly hard cap in one system and weekly budgets in the other. That's two invoices for one budget.

The controls: keep each client entirely in one system, cut over on Mondays, and track any split in a register.

Q5What if either site goes down?

A partner wanted to link its local pages to our contractor profiles as a "static test." I asked who gets credit for the lead, whether there's a cap on the traffic we send, and what visitors see if their site or ours goes down.

Each answer went into the partnership scoping as a contract clause.

Q6Should an AI agent have write access to our ad accounts?

Someone suggested using agentic browser tools for ads operations. With full write access, one bad run could delete campaigns, and that can't be undone. The official ads integration only allows reads.

I recommended doing the task by hand until it's well understood, then turning it into a skill, then connecting it with a person reviewing each change.

Q7Can a five-way test tell us which change worked?

Our A/B platform was running multivariate tests where several things changed at once, and people were drawing conclusions about individual changes. The variables weren't isolated, so the tests couldn't support that.

The platform PM put interaction detection on the backlog, and I proposed a queue of ready-to-launch tests so we'd stop bundling changes together.

05 · Contact

Get in touch

I'm interested in product roles that sit close to engineering, especially on platforms, integrations, data and AI tooling. Email is the easiest way to reach me.

hello@coleparsons.com LinkedIn (opens in a new tab)