The turn: a PMP course that leaned Agile
In 2021 I was an Operations Project Manager at SkySpecs, running drone inspection operations with in-house pilots and subcontractors across North America, Japan, Brazil and India. I was also studying for the PMP, working through Andrew Ramdayal's prep course.
The exam material was shifting toward Agile, and the more of it I studied, the clearer it got that Agile is a way of working built around software. Software is built by product teams. Moving toward product stopped feeling like a career change and started feeling like the next step in the direction I was already heading.
Asking the people who do the job
So I asked. I started meeting with the product managers at SkySpecs to see whether I could transfer in at some point. They were generous with their time and honest: their advice was a developer boot camp, or a PM seat somewhere else first.
I took the second half of that advice to heart and moved on, earning the PMP in January 2022 along the way. At DroneBase, now Zeitview, I kept the conversation going with product and UX leadership: the SVP of UX, the SVP of Product, a Director and two PMs. They all said the same thing, and it wasn't what I expected. Skip the dev boot camp, they told me. Study UX.
UX, then the product team
That advice became the UC Berkeley Extension UX/UI boot camp, from 2023 to 2024, while I kept meeting with product leadership. The boot camp changed how I think about my own claims: a persona is a hypothesis, and on my case studies every assumption is still marked until research replaces it.
I spent nine months embedded in the product team, and in 2024 product and UX leadership formally endorsed my move onto it. I added PSPO I and PSM I in 2025.
Where customer success fits
My day job is customer success, and I don't want to write it out of the story, because it's where most of my product reps come from. Every unusual client request lands with you first, and the skill that matters is triage: is this a one-off, a broken workflow, or a feature that doesn't exist yet?
Get that call wrong in one direction and you build something for a single person. Get it wrong in the other and you ignore a pattern for a year. The patterns usually show up as workarounds, described by different customers in different words.
Before the turn
The instinct behind all of this is older than the PMP. One of my early renewables jobs was weekly calibration and uptime checks on a solar meteorological station. I never saw the data; my job was to make sure the station was doing what everyone downstream assumed it was doing. A dashboard is only as honest as the last person who walked out and looked at the sensor. I still think about that every time I write a requirement.
Building the fix myself
Lately the gap between seeing a problem and getting it built has closed. My method: get the problem right, spec it in Claude, build it with Claude Code, put it in front of real use fast, and fix what the first week teaches.
The Anomaly Upload Validator is the clearest example. The tool is internal, but its specification documents are public, and the release notes are the honest part: they record exactly where the first spec didn't hold. Process shows two places where I took a claim off my own portfolio once I couldn't demonstrate it anymore.
Where I stand, and what comes next
My title is Customer Success Manager and Embedded Product Manager. I haven't held a standalone product seat yet, and I'd rather say that plainly. What stands in for it is five years of moving in one direction, and the work on this site.
Next posts, every two weeks: what my validator spec got wrong, what the UX boot camp actually changed, and why I retracted a claim on my own portfolio. Once a month I'll also go back through one year of this path, starting with 2021. If you work in renewable energy, climate, or AI-native software and care how customer problems become product decisions, I'd like to hear how it worked for you.
Kiley