The Problem: Why a Product Manager Needs an AI That Never Forgets

I'm a Product Manager at IBM Storage. My job is to know everything about my product — what customers need, what's shipping next quarter, what broke last week, and who's waiting on a decision. That knowledge lives in three places that don't talk to each other: two corporate email inboxes, a Jira board with hundreds of epics, and my own head.

Every time I reply to an email, I'm doing the same thing: piecing together context from those three disconnected systems. A customer asks about disaster recovery support for an upcoming release. To write a useful reply, I need to remember what we discussed with them three months ago, check which Jira epics are tracking that feature, figure out if it's going to land in the next release or the one after, and then draft something that's accurate, helpful, and sounds like me.

That takes ten to fifteen minutes per email. Multiply that by the dozens of emails I get daily that actually need a thoughtful response, and you start to see the problem.

Two Inboxes, One Brain

I carry two corporate email accounts — IBM and Red Hat. Between them, I'm tracking customer relationships that span months, cross-team coordination across time zones, and release planning conversations that reference version numbers most people outside the team would never keep straight.

Here's a real example of the version mapping problem. Our products ship in lockstep, but with different version numbers:

When a customer emails me about "Ceph 9.1 support," I need to immediately map that to DF 4.22, know that it's not out yet, and recall what we discussed about their specific deployment. That mapping lives in a YAML file in my head — and heads are unreliable.

Then there's the org chart. An email from my skip-level manager gets a different response time than a newsletter from marketing. A question from a peer PM about a feature I own gets a different depth of answer than a cold outreach from a vendor. I'm constantly re-evaluating priority as emails come in, and that costs mental energy even when the answer is "not now."

The Context-Switching Tax

The real cost isn't the time it takes to write the reply. It's the time it takes to rebuild context before I can even start writing.

A typical reply requires me to:

1. Remember the relationship. Have I talked to this person before? What about? What did I promise?
2. Check the current state. Open Jira. Search for the relevant epic. Read the status, the comments, the linked issues. Figure out if the timeline has shifted since the last update.
3. Recall the product details. Which release is this feature in? Is it tech preview or GA? Are there known limitations I should mention?
4. Draft in the right tone. A customer-facing reply is different from an internal one. A reply to an executive is different from a reply to an engineer.

Each of those steps pulls me out of whatever I was doing and into a different tool. By the time I've gathered everything, I've lost ten minutes and whatever thread of thought I was holding before I opened the email.

And that's for emails I actually respond to. A surprising number of messages don't need a reply at all — meeting acceptances, CI/CD notifications, marketing blasts, auto-generated alerts. But I still have to read enough of each one to make that judgment call, and that adds up too.

The Cost of Slow Replies

In product management, responsiveness is currency. When a customer asks a question and gets a detailed, accurate reply within hours, that builds trust. When it takes two days because the email got buried under meeting invites and build notifications, that erodes it.

The same applies internally. When an engineering lead asks whether a feature should target the current release or slip to the next one, a fast answer keeps the team moving. A slow answer means they either wait (wasting time) or guess (risking rework).

I wasn't slow because I didn't care. I was slow because every reply required an archaeology expedition across three systems.

It's Not Just Email

Email replies are the most visible symptom, but the same fragmented knowledge bites me in a completely different context: epic prioritization.

Every quarter, I stack-rank Jira epics to decide what ships next. The most important input to that decision is customer demand — who asked for this feature, how urgently do they need it, at what scale, and how much revenue is attached. In a perfect world, that information lives in the Jira epic itself. In practice, it rarely does. The epic might say "requested by 3 customers" with no names. Or it lists a customer but not the conversation where they explained they need it to handle 500 petabytes across twelve sites. The actual details — the scale, the timeline pressure, the dollar figure — are buried in email threads from months ago.

So when I'm deciding whether Epic A or Epic B should make the cut for the next release, I'm back to the same archaeology. Search my inbox for the feature name. Skim through dozens of threads. Try to remember which customer said what. Cross-reference with what I heard in a call that I may or may not have written down.

The problem isn't just that my knowledge is scattered — it's that I need the same knowledge reassembled in different shapes for different tasks. For email replies, I need it organized by customer and conversation. For epic prioritization, I need it organized by feature and business impact. For customer meetings, I need it organized by relationship history. Same underlying facts, different lenses. And every time I switch lenses, I'm starting the excavation from scratch.

The Vision

What I wanted was simple to describe and — I assumed — hard to build: an assistant that has read every email I've ever received, knows my org chart, understands my product portfolio, and can surface the right slice of that knowledge for whatever I'm doing — drafting a reply, prioritizing an epic, or preparing for a customer call.

Not a template engine. Not a chatbot with a personality. A system that could absorb everything I've read and make it searchable, so an AI can cross-check the same information in whatever shape the current task demands. For email, that means drafting a reply with full context. For prioritization, that means pulling every customer conversation about a feature into one view. For customer prep, that means assembling a relationship history I didn't have to maintain by hand.

The key word for emails is "draft." I don't want an AI sending emails on my behalf. I want it to do the fifteen-minute context-gathering exercise and hand me a starting point. I review every draft, edit what needs editing, and hit send myself. The AI does the research. I make the decisions.

Why Not Just Use ChatGPT?

This is the question everyone asks. The answer is straightforward: my email contains corporate confidential information, customer data, internal roadmaps, and personnel discussions. I can't paste that into a cloud service. Full stop. IBM's data handling policies exist for good reason, and "it would save me time" doesn't override them.

Any solution had to run entirely on hardware I control, on a network I trust, processing data that never leaves the building. That rules out every hosted LLM service — OpenAI, Anthropic, Google, all of them. The model has to run locally.

When I started looking into this, I didn't know if local models were good enough. The largest model I could run on my MacBook was 14 billion parameters — a fraction of what GPT-4 or Claude use. Would a model that small be able to understand enterprise email, extract meaningful information, and draft coherent replies?

There was only one way to find out.

What's Next

The next post covers the weekend prototype: a MacBook, an open-source LLM, an AppleScript, and a vector database, duct-taped together into something that actually worked. It wasn't pretty, but it answered the question — local AI can do this job.

Chris Blum is a Product Manager at IBM Storage, working on OpenShift Data Foundation and Fusion Data Foundation. He builds AI tools on local hardware because the best assistant is one that's read every email you've ever ignored.