--- title: "Product Release Management: Record or Recollection?" description: "Product release management is assessed in diligence by verifiability rather than release frequency: whether the company can show from a record which version runs at which customer, which contractual commitment accompanies it, and when support ends. Absent that record, the buy-side prices the uncertainty through representation and warranty scope, escrow percentage and gross margin assumptions." url: https://www.beirek.com/en/blog/product-release-management-due-diligence canonical: https://www.beirek.com/en/blog/product-release-management-due-diligence published: 2026-07-14 modified: 2026-07-14 category: "Product Management" category_url: https://www.beirek.com/en/blog/category/product-management language: en-US reading_time_minutes: 8 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["product release management","technical due diligence","representations and warranties","version inventory","founder dependency","escrow percentage"] topics: ["Investment readiness and valuation review","Product management governance","Software due diligence and deal documentation"] alternate_language_url: https://www.beirek.com/tr/blog/product-release-management-due-diligence --- # Product Release Management: Record or Recollection? > **In short:** Product release management is assessed in diligence by verifiability rather than release frequency: whether the company can show from a record which version runs at which customer, which contractual commitment accompanies it, and when support ends. Absent that record, the buy-side prices the uncertainty through representation and warranty scope, escrow percentage and gross margin assumptions. *In an investment review, product release management is examined not for release velocity but for verifiability. Where a company cannot show from a record which version runs at which customer, what was promised alongside it and when support ends, that uncertainty migrates into warranty scope, escrow percentage and the support cost assumption.* --- There is a recurring moment in technical due diligence sessions: the buy-side adviser asks which version is running, as of that day, at which customer. The answer arrives from one of two places — a record, or the memory of a person in the room. In the second case the observed behaviour is close to invariant; everyone at the table turns at the same time toward a single engineer or founder, who pauses for a few seconds and then reconstructs an approximate picture by walking through the customer list one name at a time. The finding of the review is not the accuracy of that reconstruction, which is often reasonably good, but the turn itself, since what it establishes is that the information sits in a person rather than in the company. The second characteristic moment of the same session is the backward thinning of release notes. Notes covering the last three or four releases tend to be orderly, detailed and dated; a year back they shorten; two years back they give way to commit messages, or to nothing at all. A parallel pattern usually accompanies this one, namely a drift in what the version number is understood to mean. At one point in the company's history a major increment marks an architectural break; at a later point the same increment has been settled in a sales conversation, on the reasoning that it will read more persuasively in a presentation to a large account. Once numbering ceases to operate as a technical marker and begins to operate as a commercial signal, release management ceases to operate as a technical discipline as well. The mechanism underneath that drift is not negligence but a shortcut that is entirely rational under a particular set of conditions. In the early period there is one deployment target, the team is small, the map of the whole product sits in a single mind, and the person holding it can read it out on request within seconds. The cost of formal release management — drafting policy, inserting an approval step, keeping records, convening a review — is immediate and visible, whereas its benefit is deferred and probabilistic. While speed remains the survival function, choosing the shortcut is the correct allocation of scarce attention. The difficulty lies not in the shortcut itself but in its persistence after the condition that justified it has dissolved. That condition tends to change not through a single event but through a sequence of thresholds: the customer count rises, some of those customers require an installation running in their own environment, one negotiates a contractual patch window and notification obligation, an integration partner asks for a backward compatibility undertaking, and a regulated buyer treats release policy as a mandatory field in its vendor assessment form. Each of these thresholds opens a separate branch in the installed base, and the number of simultaneously live versions grows independently of team size. A frequent misreading appears at precisely this point, which is the assumption that automation substitutes for governance; a mature CI/CD pipeline answers the question of how something reaches production, whereas the question posed at the review table is what reached production, on what decision, with whose approval, and against which commitment. The ownership dimension becomes decisive here, because a release decision is by its nature a boundary decision: product defines the scope, engineering declares technical readiness, the commercial line commits the date to the customer, and support carries the consequence. None of these four roles owns the decision alone, and where no explicit decision architecture has been established, the decision migrates by default to whichever party carries the highest urgency pressure. Predictably, that party is the commercial line. The observable result is a product roadmap quietly subordinated to the customer commitment calendar, a declining ratio of planned releases to total releases, and emergency patches becoming the ordinary rather than the exceptional mode of shipping. The institutional cost of this configuration shows up first in gross margin, though never as a discrete expense line. Every additional version supported in parallel implies a second remediation path, a second test environment, a second documentation set and a second body of knowledge that the support team must hold. That cost accumulates in headcount, and since no income statement contains a line called version sprawl, it typically becomes visible only when the question is posed differently — namely, what proportion of engineering capacity produced no new functionality. The method the reviewing party uses to locate the item is correspondingly indirect: development capacity across the last four quarters is set alongside the count of functionality actually shipped, and where the gap resists explanation, maintenance and support load supplies it. The second channel is the transaction document itself. In a share purchase agreement, the representations and warranties covering software, intellectual property and delivery obligations take their shape from how far the seller is able to narrow the perimeter, and the instrument for narrowing it is an inventory. Where a record exists showing which version runs at which customer, which contractual commitment that version is matched against, and on what date its support terminates, the warranty can be limited by reference to that record. Where no such record exists, the seller cannot draw the line, so the buyer draws it, and generally draws it wide. The visible consequences are a broadened warranty perimeter, a higher escrow percentage, a pre-closing condition requiring the preparation of a release inventory, and in some structures an earn-out tied to committed roadmap items. The third channel closes inside the sales cycle and produces a self-reinforcing loop. In an enterprise procurement process, release policy, patch service levels and end-of-life notification periods are standard questions; where no written policy exists, those questions migrate into contract negotiation, are resolved there through customer-specific exceptions, and each exception opens a further branch in the installed base. The absence of policy therefore lengthens the sales cycle first, increases version sprawl second, and makes writing the policy harder in the following negotiation third. The measurement dimension enters precisely here, since the loop becomes legible only through a handful of indicators: the count of distinct versions in the installed base, the ratio of planned to total releases, merge-to-production lead time, rollback frequency, and critical tickets opened within seven days of a release. The intervention that corrects this picture is system design rather than individual discipline, and it separates into five components. The first is an approved and dated release policy defining release types — major, minor, patch, emergency fix — together with the approving authority for each type. The second is a release register that joins customer, environment, version, contractual commitment and support end date on a single row. The third is a decision ritual that separates the four roles, on the principle that the person accepting scope, the person declaring technical readiness, the person making the commercial commitment and the person confirming support readiness cannot be the same person. The fourth is the measurement set. The fifth is an end-of-life policy that fixes notification periods and migration paths in advance rather than in negotiation. BEIREK sequences its work in this area not by process order but by evidentiary yield. The first structure established is the release register, because it is the only document that converts assertion into verifiable fact, and no other artefact can take the place of a verbal account at the review table. The second is the practice of recording decisions at the moment of proposal rather than at the moment of approval; where the reasoning behind what entered and what was removed from a release scope is written after the decision, the rationale is invariably reconstructed to fit the outcome, whereas the information carrying analytical value is the option that was eliminated. The third is running the release board on a fixed cadence rather than on an event basis, since a board that convenes on trigger convenes, by definition, only in crisis, and decision quality under crisis is never a proxy for institutional capacity. Testing the continuity dimension requires a separate mechanism, and its most legible form is the actual execution of a release cycle from which the founder or the lead engineer has been removed from the decision chain. Where, within that cycle, policy can be applied as written, the scope decision can be justified from the record, the readiness declaration originates from the accountable role, and customer notifications issue from a template, the structure is genuinely person-independent. Where it cannot, the finding is not a weakness in the product but a dependency of institutional capacity on an individual, and that finding reaches valuation directly through the key-person heading, most often via retention undertakings and earnings-linked consideration. What the reviewing party is looking for under this heading is not a team that ships quickly, since frequency is already visible from product metrics. What is being sought is the company's ability to demonstrate, without asking anyone and by reference to a single record, what is running where and what was promised alongside it. Here as elsewhere, the determinant of a company's valuation is not performance itself but the demonstrability of that performance as something reproducible independently of the founder; and release management remains one of the few areas where that demonstration can be made with the least interpretation and the most documentation. ## Key Points - Once a version number stops functioning as a technical marker and starts functioning as a commercial promise, the product calendar becomes quietly subordinate to the customer commitment calendar. - A working CI/CD pipeline does not evidence release management; the tooling answers how a release reaches production, while governance answers what was released, when, and on whose authority. - The number of concurrently supported versions never appears as its own expense line; its cost accumulates in headcount and in the opportunity cost of engineering capacity. - Where no release inventory can be produced, the seller cannot narrow the warranty perimeter, so the buyer draws it instead, and that widening surfaces in the escrow percentage. - The continuity test is simple: if a release can be scoped, approved and shipped against written policy while the founder is out of the room, the capability is institutional rather than personal. ## Questions ### What exactly is examined under product release management in due diligence? The review tests six surfaces separately: whether a written release policy exists, whether it is supported by approved and current documentation, whether it is actually applied in daily operations, whether outcomes are measured through indicators, whether decision authority is attached to a named role, and whether the whole structure is reproducible independently of any single person. Where verbal assertion remains the sole evidence on any of these surfaces, that area is treated as unverified. ### Does having a CI/CD pipeline mean release management exists? No. An automation pipeline governs how a release reaches production, whereas release management governs what was released, on what decision and with whose approval, what commitment was given to the customer in return, and when support terminates. The questions posed at the review table belong to the second set. Configurations combining strong deployment infrastructure with no written release policy are common, and that combination typically generates a diligence finding. ### Through which channels does weak release management reach valuation? Three channels dominate. The first is gross margin: as the count of concurrently supported versions rises, maintenance and support load accumulates in headcount. The second is the transaction document; where no release inventory can be produced, the seller cannot narrow representation and warranty scope, which surfaces as broadened warranties, a higher escrow percentage or a pre-closing condition. The third is founder dependency, which converts into retention undertakings and earn-out structures. ### How many concurrent versions is it reasonable to support? What matters in review is not the number itself but whether the number originates in a policy or in accumulated exceptions. Where the supported version count can be explained by a written end-of-life policy, defined notification periods and a migration path, even a high number is treated as manageable. Where the number has emerged as the sum of customer-specific contractual exceptions, even a low number reads as an indicator of structural weakness. --- Source: https://www.beirek.com/en/blog/product-release-management-due-diligence Publisher: BEIREK LLC — https://www.beirek.com