The PM Who Automated Himself (Or at Least Tried To)

The PM Who Automated Himself (Or At Least Tried To)

May 28, 2025

So, I started this “Building Piper Morgan” series kind of midscene, just as I was figuring out session logs and working on orchestration, but how did I get here and has it really been less than one month? Let’s go back to the beginning:

Every product manager has that moment. You’re writing your seventh “As a user, I want to…” story of the day, and your brain just rebels.

Mine happened at 9:47 PM on a Tuesday. I was rolling up my sleeves to do the scut work of product management, drafting thorough yet concise and consistent description of tasks as Github issues. I don’t even hate work like this. You can put music on (some music). It reminds me of xeroxing documents in the repo room listening to my walkman back in (ask your parents).

That’s when the dangerous thought crept in: “What if I had a junior PM who could do this for me, or even an intern, an apprentice?” Followed immediately by the more dangerous thought: “What if that junior PM was made of code?”

OK, that’s not how it happened at all. Wise friends such as Christina Wodtke had been making the point that today’s LLM-powered AIs behave a bit like eager interns: well trained in the generalities, almost useless when it comes down to domain expertise and nuance and that got me thinking (really) about how great interns are and how helpful they can be just by taking on work you’d like to get done but don’t have the focused time or attention for, and how with real human interns they get better!

They learn by going to your meetings and taking notes and asking questions, by getting copied on your emails and tracking down facts for you and asking questions, by reading (or “ingesting”?) books you recommend and taking trainings you pay for… and asking questions.

I got to really really thinking: What if I could make me one of thems? A persistent assistant or agent (?) that learns about my context and my opinions on product best practices and … wants to be hired after the apprenticeship ends as an associate and … aspires to be a real PM someday?

As cool as it would be to have a one-of-those, it also seemed like just trying to make one at all would be a hell of a trip and a learning experience.

The vision: a digital product trainee

Disclaimer: I prefer real human interns! I work with them every chance I get. Still, there are some valuable separations of concerns. We humans are great at some things AIs can’t do and No I’m not going to mention it here while they’re obviously reading too!

But seriously, here’s what I was imagining: not some AI that would replace product managers (if only), but something more like a really eager intern who:

• Never forgets the acceptance criteria format
• Actually reads all the documentation (and remembers it)
• Can draft routine tickets without complaining
• Learns from corrections without taking it personally
• Is available at 9:47 PM on a Tuesday

I called it P-M and then I had to set up a github repository and for some reason the codename piper-morgan occured to me and thus Piper Morgan was born, or at least christened. Plus, every good product needs a name before it has features. We’ve even got a logo already!

Why build instead of buy?

Look, there are AI writing tools out there. Lots of them. But here’s the thing about generic AI tools and product management: it’s like using a Swiss Army knife to perform surgery. Technically possible? Maybe. Good idea? Eh. Also, the persistence is basically nil. You are starting over with amnesia all the time. I knew I had to build on existing tools (I’m not training my own LLM for gosh sake!). But I also knew none of the existing tools are offering what I need out of the box (sidenote, persistent projects in Claude are getting me partway there and helping me tread some cowpaths I may later pave in Piper).

What I needed wasn’t just something that could write. I needed something that could:

• Understand the difference between a bug and a feature request
• Know when something needs acceptance criteria vs. just a description
• Pull context from our actual documentation (not just vibes)
• Format things the way we format them, not some generic template

Plus, let’s be honest: I wanted to understand how these LLM things actually worked. Nothing teaches you like building. I’m a project-based learner. Well a conversational learner when it comes to ideas, but project-based if I’m to learn how to do a thing. It can’t be “Hello, world!” either. It has to be something I really want that I can’t get without learning how to do the thing.

The first sketch: conversational from day one

The initial design was ambitious in its simplicity. Instead of building yet another form-based ticket creator, I wanted something conversational. Something that felt more like pair programming with a junior colleague than filling out a template.

Me: "We need login functionality"
Piper: "I'll help create an issue for that. What type of authentication - email/password, SSO, or both?"
Me: "Both, plus social login"
Piper: "Got it. Should this support MFA as well?"

That alone would make some of the tedious work easier. And yes, a copilot tool in a programming IDE or github can already do a lot of this in a fragmented way (write a ticket, follow a template, do genericky product stuff), just as engineers already have these ways to write code more efficiently and designers — reluctant as many are for all the right reasons — are seeing rapid-prototyping features crop up in Figma et al.

Product folks are still wondering for the most part how we are supposed to partake of these new efficiencies.

Which dots to connect

I knew I wasn’t making an LLM. I’m making something that uses LLMs to do its thing. I needed to call out to one or more platforms with developer API keys. (I had already set one up to play with an earlier experiment wth OpenAI.)

The landscape in early June of 2025 looked something like:

• OpenAI (ChatGPT): The obvious choice, great marketing, everyone using it
• Hugging Face: Open source appeal, but need your own hardware
• Anthropic Claude: The dark horse, claiming better reasoning
• Others: Various alternatives I won’t name to avoid dating this post

My AI imagines that I “spent a weekend reading documentation, comparing APIs, and doing what product managers do best: making a comparison matrix that I’d eventually ignore in favor of gut instinct” according to an earlier draft of this post, but that’s pure fabrication.

The truth is I really didn’t care yet which tool I used as long as it proved the concept. I had an OpenAI key already and my boss, who is wise in the way of these things, later suggested I lean toward Anthropic but to me they’re all black boxes, services that my thing will use to drive its own engine. Whatever works for now is fine, just don’t lock me in.

The architecture bet that paid off

Here’s where I made what turned out to be the smartest decision of the whole project: I built it vendor-agnostic from day one.

Instead of coding directly against OpenAI’s API, I created what I called an “LLM Adapter” — basically a translation layer that could talk to any AI provider. Seemed like overengineering at the time. My inner YAGNI voice was screaming.

class LLMAdapter:
    def __init__(self, provider: str)  # 'claude' or 'openai' or 'whatever'
    def generate_response(self, prompt: str, context: List[str]) -> str
    def switch_provider(self, new_provider: str) -> None

Spoiler alert: When I hit a rate limit during testing I was able to gracefully switching providers a few weeks later and keep testing. That “overengineering” saved my bacon.

The proof of life moment

The first version was embarrassingly simple but it already “did something”:

• Some synthetic product documents (made-up requirements docs)
• Basic question-answering using RAG (Retrieval Augmented Generation)
• A command-line interface that would make a 1980s hacker proud

But then I asked it: “What are the requirements for user authentication?”

And it answered. Correctly. Pulling from the fake docs I’d fed it.

The first time anything works at all, though, always excites me. I remember when the Noni chatbot at 7 Cups started using NLP to carry on realistic conversations (with an amnesiac), what a thrill that was.

What I thought I was building vs. what I was actually building

What I thought I was building: A simple tool to draft GitHub tickets faster.

What I was actually building:

• A testbed for understanding LLM capabilities in professional contexts
• A forcing function to document our processes (can’t automate what isn’t defined)
• A mirror showing me just how much implicit knowledge goes into “simple” PM tasks
• The beginning of a rabbit hole that would consume the next month and counting.

The dangerous thing about feeding your own itch

Once Piper successfully drafted its first real ticket, the feature ideas started flowing:

• “It should review existing tickets too”
• “What if it could analyze our backlog?”
• “Could it learn from my corrections?”
• “Maybe it should understand our codebase…”
• It should know about its own project!

Classic PM scope creep, except I was both the product manager and the customer. No one to blame but myself.

Why this matters

It’s not hard to imagine that we can automatethe mechanical parts of product management — the formatting, the translating, the copy-paste-modify cycles. Not the thinking parts. Not the strategy. Just the… typing.

What if we could delegate the typing to something that never gets tired, never forgets the format, and is always available? Not to replace us, but to free us up for the actual product thinking?

That alone would be a big win to me. Then, imagine our delegate could actually start climbing the value chain and gradually start handling more nuanced aspects of the work?

The beginning of a journey

That Tuesday night experiment became Piper Morgan. What started as “I hate writing boilerplate” evolved into a genuine exploration of how AI could augment (not replace) product management work.

Over the coming weeks, I’d:

• Discover why RAG was necessary (spoiler: LLMs make stuff up)
• Conjure up a web interface (chatting on command lines is so 1980)
• Learn exactly how much implicit knowledge we embed in “simple” tickets

And I’d also realize at some point that I was trying to hack a glorified github machine into a real PM assistant, but not yet. First I decided to share what I was working on with the rest of my team.