6 posts tagged with "AI"

One problem with software development is (and still is) that related artifacts are distributed across various tools. Tasks are set in Jira, documentation in Confluence, and code in GitHub or GitLab. The requirements and documentation are unequivocally spread across those.

If managed right, that is not a huge deal. Unfortunately, I rarely saw such cases in practice. Frequently, the requirements management on large enterprise projects goes rogue as soon as its initial owner/founder passes on. That contributes to a mental block that some developers had issues with (or simply don't like) reading requirements.

And I could relate to that: the additional cognitive load of tracking all the task details from various sources and putting them into one picture. Plus, those requirements might be badly written. Some context might be missed, taken for granted, and so on.

I understand those who ignore the specification and go directly to the source of truth or their proxy. Don't support, but understand.

Fighting in the war for unification, I became an advocate for the docs-as-code approach where appropriate. Your service docs, as Markdown files, are under the same Git versioning as the source code. As a definition of done, the developer updates the docs along with the code. They no longer forget to update the docs. Plus, the docs are in code and are more clearly structured. At least, on my projects.

That trick did not meet the requirement, though. I've never tried to implement that in practice; I only did a few thought experiments. My main issue is that, unlike the documentation, which aligns with the functional parts of an actual system, the requirements do not match the architectural design.

Simply put, requirements may span multiple modules, so where the heck am I supposed to store them? And if they concern several repos? My thought experiment ended up with a separate Git repository for requirements, which is the worst idea, even compared to Confluence.

Now, in 2026, docs are essential to the context for AI tools. So the proponents of docs-as-code had an advantage there, since they skipped a step involving Confluence MCP.

AI also changes the perspective on requirements.

As a major PM responsibility, roadmap planning has become controversial over the years. As much as I enjoy short-sight planning for the next quarter, I hate yearly roadmap planning.

The latter became a cargo-cult ritual that starts with whispering in October and, as a giant wave, hits everyone in a product organization, continuing in November until final approval in December each year. It sounds straightforward: prioritize a list of initiatives and put them on a timeline. The trick is to make it not look like a commitment.

There are probably hundreds of books dedicated to that topic. The only thing I've learned over half a decade: despite the effort you put into planning, it will end up in the trash before Q1 ends.

With all the unknowns driving a roadmap to a nonsensical outcome and keeping higher management under the illusion of control, we now have AI in the equation. It accelerates development output, pushing the bottleneck further down the line. With that change, estimating the whole thing becomes even more problematic.

When my team started working on the AI feature, I was mostly concerned with writing clear, precise prompts. As shown, maintaining them throughout the development and operational lifecycle becomes a larger, unanticipated problem.

You will learn which issues with updating prompts you might encounter when you push your AI agent from MVP to Production. Below, I am sharing my findings on the operational side of the prompt management.

That title isn't clickbait: it's what actually happened. Over the last three months, I've spent 90% of my time obsessing over whether our AI search returns the right results. Not writing PRDs. Not in stakeholder meetings. Just testing, scoring, and re-testing AI outputs.

Only recently did I learn that there is a trending term for what I am doing: AI evals. I thought that was "quality assurance" or "testing". But AI Evals is a sexier name for selling courses.

Jokes aside. The main reason the industry began separating it from traditional QA frameworks is the non-deterministic nature of the output. Different results from the same input were considered as the definition of madness.

Now it is our new reality.

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.

This article is a summary of my PM experience on designing an artificial intelligence (AI)-based capability for an existing product from the proof-of-concept (POC) stage to a minimal viable product (MVP).

When you are adding an AI feature to an existing product, you can either:

• introduce an entirely new functionality
• extend existing functionality with AI possibilities.

In my case, the latter is true: we aim to introduce AI search to enhance user experience. It sounds pretty trivial, I acknowledge that. The challenge is that search is the critical functionality for that product.

Therefore, we need to introduce a new search method to provide users with more value than the existing one. If AI search works "just good enough," then a traditional one could be considered a failure.

The improvement must be substantial, because of …