From Product Manager to Context Dealer: How AI Changed My Role

Introduction: The Shift in My PM Role

As a Product manager, I am building proofs-of-concept (POC) and constantly hunting for context.

That's what my role is about now. I am reluctant to create roadmaps, write any required documents, and manage the backlog in Jira.

Previously, writing those requirements docs, sitting on mockups to ensure they matched the requirements, writing user stories, and many other related tasks were part of the creative process.

I enjoyed that. That was a reason I kept going in my craft for now more than a decade: from an L1 support engineer to a Senior product manager.

Now I am looking and constructing something that a "team can build in the near future." Everything else stepped aside. I don't enjoy it anymore.

From Jira to IDEs: My Daily Weapons

My PM toolkit is a bunch of IDEs (VS Code, IntelliJ IDEA, Cursor, etc.) with multiple AI-related plugins like Claude Code and Continue. Bruno is used for API calls, Bedrock, Ollama, a bunch of MCP servers run locally, and a bunch of custom internal tooling.

And now I don't like being dragged out of it, doing traditional PM stuff.

Recently, I was procrastinating on writing another BRD. Instead of writing, I spent a week trying to find Context and use it to build a new feature.

Only after that did I approach the BRD generation with an LLM, recognizing that I needed to communicate my idea to stakeholders in a formal way. The outcome was not great, but good enough to share with the others.

Really, I don't want to spend much time on that. I focused on extracting values from various ideas and seeking the Context to make that happen.

What It Means to Deal in Context

I can call myself a Context Dealer.

It's someone who tries to locate disintegrated pieces of information spread across various systems and enterprise units and transform them into a valuable Context. So we can use that Context to improve our AI capabilities.

You need to approach those who own that data, ensure its quality, format, and maintainability. Data is the King: I don't want to feed my AI Agent with messy and unreliable Context.

I am less concerned with writing code and prompts. My two primary concerns are operational costs (read my previous article about that) and quality user experience, which the right LLM, a well-written prompt, and precise Context can achieve.

Building Relationships and Managing Data Flows

Extracting is about building relationships with data providers (making deals), leading to a new data governance process. Sometimes it is about data analysis and mapping.

At first, it seems easy, as there are a lot of low-hanging fruits around. But very soon you start to realize gaps such as non-documented pieces of knowledge, ill-written docs, incorrect, incomplete, outdated, or absent data.

The absence of data is better than incorrect data. Because first, you are aware you lack some data. For the latter, you might not be aware.

Gathering new data is a demanding and time-consuming process. AI tools can help there: you can blend results from several MCPs and generate the desired outcome. But I don't need to explain the risks of AI-synthesized data.

When you have gathered, processed, and utilized the data, you can pass it further to leverage it in other AI agents. It is like a flow of streams that emerged into a vast river. And as a Context Dealer, you are in charge of your data flows from which you can benefit.

Giving Old Ideas New Life with AI

Every PM has a graveyard of features and opportunities that have never seen the light because of various reasons. I am reviewing never-implemented BRDs, postponed and cancelled Jira tickets, and notes to seek what we can potentially revive in that New Brave AI World.

Something became irrelevant from a business perspective, something is not relevant because of AI itself. But there are some old-forgotten gems, and when you rediscover them, the first thought is: "We can give it another try".

You can vibecode a POC by yourself, and test whether it is feasible and does the job as intended. Then you go to your Team and closest stakeholders to align with them. If there is a consensus, then comes BRD and other procedures to communicate with the senior stakeholders and a broader business audience.

It is cheaper and more effective. I like that so much rather than writing another BRD and a bunch of user stories. Now, a POC is an outcome of my PM work, not just docs and mockups.

Vanguard of a Changing Profession

We all heard from every corner that product management has changed. As contemporaries, we may not realize the full scale of that change at the moment. We need some time, maybe a few years, to understand and process what has been shifted and how persistent those implications are.

A Python course I took in 2015 and my involvement with APIs for the last half of a decade put me in a beneficial position. There is a slogan that PMs need to become technical or go extinct. My career was quite unconventional, but now, as the environment has transformed, I am in the right place and time.

Context Dealer is a good metaphor for how I feel in my position right now. Another metaphor: I'm like the vanguard of a giant army: riding ahead to scout the land, secure supplies, and clear the path forward. Not someone who is just looking at and drawing the path through the maps in a general's office.

How do you feel about those changes?