Blending Data Science Education with PM thinking

Most PMs are flying blind.

They have a question about how a feature is performing, so they file a ticket. They wait three days for a Data Scientist to write a SQL query. They spend another two days going back and forth because the requirements were misunderstood. By the time they have an answer, the momentum is gone.

This "latency tax" is the silent killer of good products.

On my team at Adobe, we don't have dedicated data scientists. At first, that looked like a resource gap. In reality, it became my biggest advantage. I stopped asking for data and started building the tools to find it myself.

The Problem with "Requesting" Data

When you outsource your curiosity to another team, you lose the nuance.

A data scientist can tell you the retention rate is 40%. But as a PM, you’re the only one who knows that "retention" for a professional editor in Japan looks completely different than for a hobbyist in the US.

If you can’t query the data yourself, you’re stuck with whatever "standard" dashboard someone else thought was important six months ago.

Why You Need to Build Your Own Instruments

A few months ago, I was looking into Photoshop retention. I realized the core team didn't have a specific way to track how early engagement predicted long-term churn.

I didn't wait for a roadmap slot. I built a custom retention analysis tool from scratch. I've carried out similar exercises for every flagship product that I have worked on at Adobe over the past 4 years. These include Photoshop, Illustrator, Firefly, Adobe Express, Premiere Pro and Lightroom.

Because I was the one digging through the raw numbers, I noticed something the Illustrator team had missed: their model for predicting customer value had a massive discrepancy in how it looked at tool usage.

I didn't just find a bug; I found a strategic flaw. If I had been waiting for a weekly report, I never would have seen it.

The In-Product Funnel is Where Growth Lives

Most people look at the business funnel as a straight line: Traffic → Acquisition → Retention. That’s too shallow.

I look at the "In-Product" funnel. I want to see the friction between starting a tool and actually finishing a task.

Did the user export?

How deep was the session?

Did they exit unsuccessfully?

When you cross-reference those actions with tenure and subscription type, you stop guessing. You start knowing exactly why a user in a specific country is giving up.

Influence Without an Engineering Team

I don’t have a dedicated engineering team. To get anything done, I have to convince other PMs to prioritize my initiatives.

Data is the only lever that works in that environment.

I don't walk into meetings with "opinions." I walk in with a Diagnostic Snapshot. When I can show a product lead exactly where their users are dropping off—backed by my own analysis—the conversation shifts from "Should we do this?" to "How fast can we build it?"

The Verdict

Being a "Technical PM" isn't about knowing how to code for the sake of it. It’s about shortening the time between a question and a decision.

If you own the strategy but don't own the data, you’re just a middleman. I’d rather be a one-man show who can own the process from the first line of code to the final execution.

Speed is a feature. Don’t wait for a dashboard to tell you what to do. Build the dashboard yourself.