I’m a technical project manager. I’ve spent years working with engineers, writing specs, running sprints, and thinking about how products get built. But until recently, I hadn’t actually built one myself.

That changed in March 2026, when I started working with AI coding agents in Cursor. In the span of about ten days, I shipped three real projects to production. Not prototypes. Not mockups. Working software, live on the internet, doing useful things.

And it taught me more about product than any framework ever did.

What I actually built

A financial markets risk engine. It pulls live data from yfinance (stocks, ETFs, forex), the FRED API (12 macroeconomic series like yield curves, consumer confidence, and credit spreads), and Coinbase (crypto). It runs a 3-layer risk scoring system — technical, macro, and fundamental — weights leading indicators 1.5x over lagging ones, and generates a static HTML report with risk signals, opportunities, and plain-English market context. It tracks 80+ assets. It’s live on GitHub Pages and rebuilds via GitHub Actions.

I started knowing almost nothing about investing. I ended with a tool that flags consumer confidence collapses, scores insider selling breadth, and tells you when the yield curve is inverted — and I actually understand what all of those mean now.

A memoir blog for my mom. My mom Kate wrote a beautiful memoir about time spent at a country estate in the 1950s. I converted her TextEdit .rtfd file (which stores images as separate PNGs — better than PDF for extraction) into a polished web page with serif typography, scanned photo galleries sharpened with Python Pillow, and AI-generated audio narration using Microsoft’s neural TTS engine. Every diary passage has a play button. A British woman’s voice reads it aloud.

This blog. Astro, Markdown, GitHub Pages. Five content categories, typed schemas, auto-generated RSS, zero JavaScript shipped to the browser.

None of these required me to be a software engineer. They required me to know what I wanted, be willing to iterate, and understand enough to evaluate what the AI agent produced.

What building taught me that specs never could

Scope creep is physical now

When I was writing specs, “just add one more field” felt like a small request. When you’re the one implementing it — or directing an AI agent to implement it and then debugging the result — you feel it. The financial agent started as “pull some stock data.” It became a 3-layer risk engine with 12 FRED series, fundamental analysis, an opportunity screener, collapsible HTML sections, mobile-responsive tables, and a plain-English banking narrative.

Every one of those additions was valuable. But I lived the scope expansion. I know exactly what each feature cost in terms of time, complexity, and bugs introduced. That’s knowledge you can’t get from a Gantt chart.

Trade-offs are no longer abstract

I had to choose: live dashboard or static HTML report? The static report builds in 35 seconds, costs nothing to host, and works forever with no server. A live dashboard would need infrastructure, auth, and ongoing maintenance. I chose static. That decision taught me more about build-vs-buy than any framework slide deck.

Another trade-off: the risk engine flagged the market as CRITICAL (score 100/100) while the Claude AI narrative called it MODERATE. They were reading different signals. I had to decide whether to reconcile them, show both, or pick one. In a spec, you write “display risk level.” In reality, you’re choosing between conflicting data sources and deciding how much confusion your user can tolerate.

Data quality is the real problem

Everyone talks about AI and algorithms. Nobody talks enough about data.

  • yfinance is unofficial — no SLA, and ticker SQ randomly 404’d one day (the symbol may have changed)
  • FRED is official and excellent, but release cadence varies by series — some data is weekly, some monthly, some quarterly
  • CAMELS ratings (bank safety scores) are confidential — you literally cannot access them as a private citizen. I had to learn that by trying.

I added three separate timestamps to the financial report — when the market data was captured, when the FRED observations were through, and when the HTML was generated — because I learned the hard way that “data as of” means three different things.

Empathy for engineers became visceral

My first deploy to GitHub Pages failed twice in a row. First because the GitHub Action only triggered on schedule, not on push — I didn’t read the workflow config carefully enough. Then because I synced two Python files but not the five others they imported. AttributeError: 'MarketHealthReport' has no attribute 'score_uncapped'. Then ImportError: cannot import name 'format_engine_risk_for_prompt'.

The lesson: when porting between repos, sync everything, not just what you edited. I wrote that down in a PORTING.md file so I wouldn’t make the same mistake. That’s the kind of knowledge that changes how you write a migration spec the next time you’re on the PM side of the table.

AI makes this accessible — but it’s not effortless

The AI agent handled the velocity. I handled the decisions. That split is important.

I chose static over live. I chose sector ETFs over individual stocks for broad market coverage. I chose Cloudflare Pages over GitHub Pages for my mom’s site because it supports private repos with free hosting. I chose to add a noindex, nofollow meta tag so search engines wouldn’t find a family memoir.

The agent didn’t make those decisions. It proposed options. I picked. And because I was building, not speccing, I understood the implications of each choice in a way I never would have otherwise.

Start with something real

Don’t build a toy. Build something you actually want to exist.

I wanted to understand financial markets better, so I built a risk engine. I wanted to preserve my mom’s memoir, so I built her a blog with audio narration. I wanted to share what I’m learning, so I built this site.

Every one of those projects taught me something specific about data ingestion, deployment, mobile UX, privacy, content architecture, or the gap between what users see and what the system actually does.

If you’re a PM who hasn’t built anything — start. Pick a problem you actually have. The point isn’t the artifact. The point is what building teaches you about products, about engineering, and about yourself.

If you’re a PM thinking about building with AI agents, I wrote about my setup and how the collaboration works. Happy to chat — get in touch.