Product work is now the harder part.

In many teams AI now writes a large share of the code, and the tools improve every few months. A feature that once took a team a quarter can take one person a couple of weeks.

That shortens the lead a company gets from building something first. A competitor who needed six months to copy a feature may now need a few weeks.

When building is quick, the slow and risky part is deciding which customers to serve, which of their jobs to take on, and exactly what the product should do for them, including in the unusual cases where many of the real decisions sit.

This is product management's work. When every competitor can ship quickly, products differ in smaller ways, such as a better understanding of one type of customer or a rule that is handled correctly. Getting those details right takes careful reasoning.

AI agents turn a specification into working software quickly, whether or not it's right. If a domain concept is misunderstood, a business rule is missing or two requirements contradict each other, the mistake goes straight into what gets built.

However good AI gets at suggesting what to build, it needs an accurate account of the domain and the product to check its suggestions against.

AI already helps with this work: it can summarise a competitor's website, pull the jobs out of interview notes, or draft a glossary or a use case. The results end up in chat histories and documents. The competitor summary is in one conversation, the glossary in another, the use cases in a shared folder and the specification in a pull request. None refers to the others, the next conversation starts without them, and when two disagree, nobody may notice.

Documents can hold all of this, but a question that spans them, such as which capability serves no customer need, means someone, or some assistant, reading everything, and still perhaps missing a page.

Kheel turns that work into linked records that you and your assistant build up as you go, and that the next conversation starts from. The case study below shows what that looks like on a real decision.

Keeping track of competitors is one of Kheel's capabilities. One of its smaller questions: how does someone know that a competitor's record has gone out of date?

1. The need. Each competitor has a keeper, who keeps its record true and needs to know when it has fallen behind. Capability: what it's for
2. The rule. “A competitor is behind when something happened after it was last looked at.” A move dated after its latest read, or after someone last confirmed that read still holds, puts it behind; editing its details doesn't. Business rule R11
3. What was left out. A flag on each move, to tick it off once dealt with. One date for the whole competitor answers the same question, with nothing to tick. Considered and rejected
4. The decision. Work out “behind” from the moves and the last look whenever it's asked for, rather than store it. Stored dates would make the queries simpler, but they're more things that can drift out of step. Design decision D5
5. What was built. The competitor list flags a competitor with moves since it was last looked at, and an assistant asking “who has moved since we last looked?” gets the answer the screen shows. Built from the design

Each step links to the one it serves. When the rule changes, the decision and the code that depend on it can be found, and an agent unsure what “behind” means goes up to the rule rather than guessing.

We separate statements about a product into three levels, each answering a different question. Mixing them up is a common source of problems in specifications, and an AI agent can only tell them apart if they're kept apart.

The free analysis and mockup skills come from the same work. We use them to build glossaries, map jobs and draw screens with an AI assistant, and we've made them available for anyone to use.