Handoff to sales and development: a package of artifacts instead of a manual assembly

Step by step

1. 1. Prepare the context, not the document

   The package is assembled from the context that has accumulated in the product: the decisions, the hypotheses, the metrics, the positioning, the source fragments. That is why the first step is not writing text but making sure the context holds the reasons. If the data is missing — no positioning, no metric, no recorded decision — the package is created anyway, but with an explicit list of gaps instead of invented content. That is a requirement, not a fallback: no artifact type is filled in by default, and where there is nothing to say, the artifact says that there is nothing to say. The package creates no facts; it exposes the ones you have. Expected result: you can open the context and name the decision behind the feature you are about to hand over.

2. 2. Move the feature to the release stage

   The mechanism is a trigger, not a routine: the product manager moves the feature into the stage of ready for release, and the system creates the package of artifacts. The set of stages is configurable, and the composition of the first wave is still an open decision in the PRD. The point of the trigger is that the handoff happens at a known point in the work, and not when somebody remembers to assemble five sources from five different places. Nothing is published at that moment: the package lands in the confirmation queue first. A stage change is the moment of collection, not the moment of publication. Expected result: the package exists, the nine types are visible in the list, and it is waiting for confirmation.

3. 3. Know the nine artifact types and who each one is for

   The set for v1 is nine types, and all of them are generated from the same context and differ only in audience and template: a release note for external users, an internal changelog for the team, a battlecard for sellers, an outbound letter for clients, a brief for the sales department, an FAQ for sales, a demo scenario for sellers and PMM, a draft of tasks for development, and a release announcement for external communication. The internal changelog is part of the set; a public changelog as a separate web entity is not in it. The separation matters for the read-through: checking facts and adjusting tone are different jobs, and mixing them hides both. Expected result: for each of the nine types you can name its reader and what it has to contain.

4. 4. Check the package: facts on one side, tone on the other

   The package always passes a confirmation gate, and publication without confirmation is not possible. The product manager checks the facts, the product marketer adjusts the tone. Every assertion in an artifact is marked with its source, and when you open a battlecard you see the source of each fact together with who confirmed it and when. If the context holds no justification for the feature, the artifact carries an explicit gap such as the justification is not recorded, and in no case does a made-up reason appear in the package. The confirmation is written into the log with the person and the date. Expected result: the queue is empty, the log shows who confirmed the package and when, and the gaps are still visible as gaps.

5. 5. Choose the delivery channel

   Seven delivery channels are available: inside the product, e-mail, Slack or Teams, Notion or Confluence, a CRM such as HubSpot, Google Docs, and a web page with access by link. The channel is chosen at delivery time, and an unavailable channel does not block the rest. The choice is recorded both in the package and in the delivery log, together with the result of the delivery. Delivery happens after the confirmation, and it happens where the audience already works — that is the whole point of a mechanism built on triggers. Expected result: the artifacts sit in the channel you picked, and the delivery log shows the channel and the outcome.

6. 6. Pick the format of the task draft

   The draft for development is created in one of four formats, and the product manager chooses them when the package is prepared: a feature, a specification, an epic or a ticket with a description and acceptance criteria. The acceptance criteria are required in every format — for a feature and an epic they are present at their own level. The draft also carries the transferable context: the goal, the hypothesis and the decision, with links to them, so that the developer sees why the work exists and not only what to build. The draft goes into the integration with the client tracker, where Linear and Jira are among the supported systems. The format is not a one-time administrator setting: it is chosen per package. Expected result: the task in the tracker has a description, acceptance criteria and links to the strategy, the hypothesis and the decision.

7. 7. Delegate with an explicit boundary

   For a task, the assistant recommends the executor — a role or a person — and the format of delivery, together with a reason. If the context is not enough for a recommendation, it says so instead of guessing, and an estimate of timing, volume or probability is marked as an estimate based on context rather than presented as a fact. The delegation boundary is set per task, not globally: once you say do it yourself for one task, the journal shows what was done on its own and what was sent for approval, and the permission does not spread to the other tasks. The assistant also remembers earlier attempts: a repeated proposal is marked as already tried and it did not work, with the history of the attempt. Expected result: for the task you delegated, you can see the executor, the format, the reason and the boundary.

8. 8. Know what the handoff does not do

   Out of scope for v1: automatic publication without confirmation, automatic mailing to buyers, the generation of e-mail campaigns to customers, a public changelog as a separate web entity, and localization of the artifacts into several languages — these are open decisions in the PRD, not features that quietly work. The artifacts also do not resolve what they cannot: the package carries the gaps, and closing a gap means adding a decision or a metric to the context and rebuilding the package. Each artifact keeps its versions and the difference between the versions, so the question of what was told to sales last quarter has an answer. Expected result: you can name what is not automated and you know where a gap gets closed.

If it does not work

The battlecard says that the justification is not recorded.

This is the gap marker working as intended: the context holds no recorded reason for the feature, and the artifact says so rather than inventing one. The product marketer has two options — add the decision, the hypothesis or the metric to the context and rebuild the package, or send the package back for revision. In both cases no invented reason appears in the package. Note that the gap travels with the artifact: it stays visible to the audience until the context is filled.

A figure proposed by the assistant got into an artifact.

A market number proposed by the assistant and not confirmed by a person is marked as an AI estimate with an unconfirmed source, and the system requires a confirmation before such a calculation can be used in an artifact. Open the assumption, either attach the source or reject the value, and then check the artifacts that were built from it. The rule is general: the AI proposes, the person confirms, the code counts.

The team received nine artifacts and nobody knows which one to read.

Each type has its audience, and the type list shows it: the internal changelog is for the team, the brief is for the sales department, the FAQ and the battlecard are for sellers, the demo scenario is for sellers and PMM, the release note is for external users. The artifacts are generated from the same context and differ only in audience and template, so the content does not have to be reconciled by hand; what has to be reconciled is the tone, and that is the job of the product marketer before the confirmation.

The task arrived in the tracker without acceptance criteria.

Check the format that was chosen when the package was prepared: feature, specification, epic or ticket. Acceptance criteria are required in every format — for a feature and an epic they are present at their own level — and the format is chosen by the product manager per package, not configured once by an administrator. If the criteria are missing, send the draft back for revision: an incomplete draft in the tracker is where the discussion about the scope starts.

Sales asks something the artifact does not cover.

The artifact is built from the context, so an answer that is not in the context is not in the artifact either. The sources and the versions are kept with each artifact, and the difference between the versions shows what changed. If the answer needs a new claim, it first needs a decision in the context — then the package is rebuilt and the claim appears with its source. A short note from the product manager to sales about what was decided and where it is recorded is faster than a version of the package edited outside the product.