I’m shutting down Product Partner because I stopped using it.
I built it to solve a problem I have almost every day. My work is spread across several products, repositories, backlogs, and planning documents. The reasoning behind a decision might sit in a conversation from six weeks ago. The unfinished part of a project might be in a handoff, while the next step is buried in the backlog. Before an LLM could help, I often had to reconstruct all of that context for it.
Product Partner was supposed to be the colleague who already knew. When I needed to pick up a project, draft a spec, or decide what belonged in the backlog, it would understand the history and take the first pass. I could spend more time deciding what to build and less time briefing the tool helping me build it.
The problem was real. I just ended up solving it somewhere else.
What I built it for
I started Product Partner on May 1, 2026. Three days later I tagged version 0.1, and by May 18 it was deployed.
It had persistent memory, ranked briefings, inspectable sessions, structured proposals, and a live Linear connection. It could draft backlog items and record decisions. Any proposed change went through a review step before it reached the backlog, and I could apply, modify, reject, or undo it.
That review model was useful. Product Partner was not just a chat window pointed at Linear. I had built a real product around the idea that an AI colleague should remember how you work without being allowed to change things silently.
I had also built most of it before proving anyone wanted it.
I had a target customer, but I did not have paying users, retention data, or enough customer evidence to claim Product Partner had found a market. I cannot say customers rejected it because I never got far enough to learn that.
What I did learn came from using it myself.
When I needed to resume a project or work through the backlog, I increasingly opened Claude or Codex. Product Partner remained available, but it was no longer where I did the work. Since I had built it around one of my own problems, my behavior was hard to ignore.
I could keep improving the product. What I could not do was point to evidence that improving it was the right use of my time.
Why Claude and Codex took over
Claude and Codex did not replace Product Partner on their own. Neither arrives knowing my backlog, remembering the previous session, or understanding how I want unfinished work captured.
I built that around them over time.
At the start of a session, the agent checks the project handoff and related backlog items. It verifies the handoff against the repository instead of assuming an old note is still accurate. An MCP server gives it direct access to the live backlog. After the work, it updates the existing ticket or files a loose end, and the next session starts from the resulting handoff.
With that in place, Claude and Codex have much of the continuity I wanted from Product Partner, and they can use it while doing the work itself.
They can inspect the repository, draft a PRD using the workflow I already built, run the CI checks, review the result, and update the backlog without moving the task into a separate product. They also have access to the other skills and MCP servers I use. When I improve one of those workflows, it becomes available across my projects.
None of that flowed into Product Partner automatically.
If I wanted the same PRD process there, I would have to port it. If I wanted the same CI workflow, I would have to build that integration. Every new first-party feature, third-party tool, or custom skill available to Claude and Codex created another thing Product Partner would need to match.
At some point, the work was no longer about making Product Partner better at its core job. It was becoming an effort to maintain a second agent environment that would usually be behind the two I already used.
The bet I got wrong
On the Product Partner project page, I wrote:
Incumbents will catch up on the prompting layer in a quarter. The work that compounds is the integration plumbing they don’t want to build themselves.
That turned out to be wrong for the product I had built.
The integrations still matter. What changed is where they need to live. My backlog does not need a dedicated AI product sitting in front of it. It needs a reliable way for the agents I already use to read and update it.
MCP gives Claude and Codex access to the same live planning data. Handoffs preserve where a session stopped. Git provides a record that can be checked against the handoff. Project instructions and skills preserve how I want the work handled. The backlog remains the source of truth instead of being copied into another product’s memory.
Once those parts were working together, Product Partner’s separate interface and memory system were duplicating something I already had closer to the work.
That does not mean the replacement is objectively better in every respect. Product Partner had a more deliberate review interface and clearer undo behavior. My current system is custom, depends on several pieces working together, and would be too much setup for many people.
For my workflow, those disadvantages were outweighed by being able to work in the same environment where the context, tools, and implementation already lived.
The market moved while I was building
By August, I had added a PRD workflow, CI checks, project-specific skills, and more MCP connections around Claude and Codex. Each addition made those agents more useful across all my projects. Product Partner received none of those improvements unless I rebuilt them there.
I was moving fast on Product Partner, but the alternatives were improving too. I could add features every week and still lose ground on the reason to use it.
My mistake was treating speed of implementation as speed of learning. I should have put Product Partner in front of other people sooner. The next time I build around a gap in Claude, Codex, or another platform, I want to write down which platform changes would weaken the product and revisit that list before I build the next layer.
There may still be a useful product here for a different customer. People working outside development environments may not have access to the same tools. Less technical users may want a managed experience instead of assembling hooks, project instructions, skills, and MCP servers. Teams may need shared permissions and governance that my one-person system does not provide.
Those are plausible directions, but they are different product theses. I would need to validate them from the beginning rather than use them to justify keeping the current product alive.
Why I’m stopping
I’m retiring the Product Partner app and its project page. I am keeping the code and the record of what I built, but I am no longer treating it as a product in progress.
The problem I set out to solve has not gone away. I now solve it through the agents I already use, connected to the backlog and workflows I have built around them.
Keeping Product Partner alive would mean maintaining a separate version of that system without evidence that anyone needed the separation. I do not have a good product reason to do that.