Stillborn

Podcast 2 — In conversation

Speaker A: The bereavement experience of stillbirth is one of the most inadequately supported in modern healthcare, despite significant improvements in recent decades. Parents who experience a stillbirth often describe a peculiar social isolation — the grief is real and profound, but the absence of a living child means that others sometimes struggle to recognise the magnitude of the loss. In many healthcare systems, stillbirth does not automatically trigger the same bereavement support as the death of a living child, despite the fact that the bond between parent and child has been forming throughout the pregnancy and the grief of its ending is no less real.

Speaker B: The figurative use of stillborn is interesting because it does something that relatively few single words can do — it simultaneously conveys the fact of failure and the specific quality of that failure, which is that the thing failed at the moment of launch rather than after some period of promising life. A failed initiative could have succeeded for years before failing; a stillborn initiative never had a moment of success. The word places the failure at the origin, which is both the most tragic location for a failure and often the most revealing — it suggests that something was fundamentally wrong from the beginning, not that something went wrong later.

Speaker A: Stillborn versus abortive — what is the distinction?

Speaker B: In figurative use, both describe things that fail to come to fruition, but with different emphases. Abortive suggests a process that was terminated before it could complete — an abortive attempt is one that was tried but stopped short. Stillborn suggests something that appeared to arrive but arrived without life — it got to the moment of launch or delivery but failed at that moment rather than during the attempt. An abortive coup attempt is one that was tried and suppressed; a stillborn peace plan is one that was announced but immediately failed to get any traction. The distinction between failure during the attempt and failure at the moment of delivery is what separates them.

Speaker A: What is a common mistake about using stillborn figuratively?

Speaker B: Using it too casually or too broadly for any project that fails early, forgetting that the word carries the weight of its literal meaning. A project that fails after three months of promising development is not stillborn — it lived for three months. A plan that encountered opposition and was revised rather than abandoned is not stillborn — it survived the challenge and adapted. Stillborn specifically means arriving without life — failing at the moment of launch, the moment of birth, before any life was demonstrated. Using it for early but not immediate failures misapplies the word and, in contexts where the literal meaning might be in anyone's mind, risks an unintended and painful resonance.

Speaker A: Any close synonyms in the figurative sense?

Speaker B: Abortive, doomed, ill-fated, and dead on arrival all cover similar territory. Dead on arrival — sometimes abbreviated DOA — is the closest equivalent in informal and journalistic use: a policy described as dead on arrival is one that arrives in the legislative process without any prospect of passing. Ill-fated suggests that failure was predictable from the beginning — the ill-fated venture, the ill-fated expedition — with a sense of tragic predetermination. Doomed carries a similarly fatalistic quality. Abortive focuses on the incomplete process. None of these has quite the specific combination of anticipated arrival and arrival without life that stillborn captures — the grief of the expected thing that came and came too late.

Podcast 3 — Prompt engineering

Speaker B: Welcome to the workshop. Today we prompt AI using the word stillborn — building the deployment failure detectors, launch readiness validators, project viability assessors, zero-engagement content analysers, and failed-at-start diagnostics that identify initiatives, deployments, and products that arrive without momentum and need early intervention or graceful retirement.

Speaker A: So stillborn tells the AI to build the launch failure detection systems — the deployment monitors that detect when a release gets no traffic after launch, the content analytics that identify zero-engagement posts, and the project health systems that flag initiatives showing no signs of life in their early stages?

Speaker B: Exactly. It signals launch failure detection, zero-adoption monitoring, and early viability assessment. Let me start with a deployment vitals monitor.

Build a deployment vitals monitor: immediately after a new deployment goes live, start monitoring key health indicators — request rate, error rate, response time, and active user count — and compare them against the baseline from the previous version. If any indicator is significantly worse than baseline within the first fifteen minutes, or if request rate fails to reach a minimum threshold within thirty minutes of launch, automatically trigger a rollback and alert the engineering team. Generate a launch health report showing the vitals at each minute for the first hour after deployment.

Speaker B: Deployment vitals monitor tracks request rate, error rate, response time, and active users against baseline, triggers automatic rollback if vitals degrade within fifteen minutes or traffic fails to reach minimum within thirty, and generates a per-minute vitals report for the first hour — the AI builds the baseline comparator, the degradation detector, the traffic threshold checker, the rollback trigger, and the launch report.

Speaker A: The traffic minimum threshold check — triggering a rollback if the request rate fails to reach a minimum within thirty minutes — catches a different class of stillborn deployment than the performance degradation check: a deployment that arrives without traffic may have a routing misconfiguration, a DNS failure, or a load balancer issue that means the new version is simply not being reached by users, and the absence of traffic is itself the signal that something is wrong even if the error rate is zero.

Speaker B: Zero-traffic rollback trigger as the misconfigured-routing stillborn deployment detector. Now the launch schema.

Design a product and feature launch tracking schema: a launches table recording each launch with an ID, name, type as feature, product, or campaign, the launch timestamp, the target audience size, the responsible team, and the launch status as live, rolled back, or retired. A launch_vitals table recording hourly vital measurements for the first seventy-two hours with the launch ID, timestamp, request count, error rate, conversion rate, and active user count. A launch_thresholds table recording the minimum expected metrics for each launch type at one hour, twenty-four hours, and seventy-two hours after launch. A stillborn_launches_view showing all launches that failed to meet their one-hour threshold and the specific metrics that fell short.

Speaker B: Launch tracking schema stores launches with type and status, hourly vitals for the first seventy-two hours, minimum expected threshold definitions by launch type and time window, and a stillborn launches view showing one-hour threshold failures with specific metric shortfalls — the AI builds the four-table schema.

Speaker A: The stillborn launches view — showing all launches that failed to meet their one-hour minimum thresholds and the specific metrics that fell short — is the post-mortem starting point for understanding launch failures: rather than reviewing all metrics from all launches, the view surfaces exactly which launches had early signs of no-life and which specific indicators were below the expected floor.

Speaker B: Stillborn launches view as the targeted post-mortem entry point. Next, the launch readiness interface.

Design a launch readiness and go-no-go decision interface for a product team: display all items on a pre-launch checklist organised by category — technical, marketing, legal, and support readiness — with their completion status. Show a go-no-go recommendation based on how many checklist items are complete and whether any blocking items are outstanding. Allow team leads to mark items as done, waived, or blocked and to add notes. Display a launch countdown timer and a real-time vitals panel that activates at launch time. Provide a rollback button with a confirmation step that remains accessible throughout the launch window.

Speaker B: Launch readiness interface shows categorised pre-launch checklists with go-no-go recommendation, done-waived-blocked item actions with notes, a countdown timer, a real-time vitals panel at launch, and a confirmation-step rollback button — the AI builds the checklist manager, the go-no-go calculator, the item actions, the countdown, the vitals panel, and the rollback button.

Speaker A: The go-no-go recommendation based on checklist completeness — automatically surfacing a recommendation rather than requiring the team to judge from the raw list — gives the launch decision a structured basis: a launch where eighty percent of technical readiness items are complete but zero legal readiness items are done should produce a clear no-go recommendation, and the automatic calculation prevents the common failure mode of launching despite incomplete readiness because the pressure to proceed was greater than the impulse to check.

Speaker B: Automatic go-no-go recommendation as the pressure-override-prevention mechanism. On to zero-adoption detection.

Create a zero-adoption and stillborn feature detector: track the usage of every feature released in the past ninety days. Flag features that have never been used by any user as stillborn. Flag features that reached initial users but show a declining active user count over consecutive weeks as fading. For stillborn features, investigate whether the issue is discoverability — the feature exists but users cannot find it — or genuine lack of demand. Generate a monthly feature adoption report showing adoption rates, user retention per feature, and a recommended action for each stillborn or fading feature — promote, improve, or retire.

Speaker B: Zero-adoption feature detector flags never-used features as stillborn and declining-usage features as fading, investigates discoverability versus demand for stillborn features, and generates monthly adoption reports with promotion-improve-retire recommendations — the AI builds the usage tracker, the stillborn and fading classifiers, the discoverability analyser, and the monthly report.

Speaker A: Investigating whether a stillborn feature's problem is discoverability or genuine lack of demand is the diagnostic step that prevents the wrong intervention: a feature that no one can find but that users want when shown it needs a discoverability fix — better placement, better onboarding; a feature that users can find but choose not to use needs a demand reassessment — perhaps it solves a problem users do not have.

Speaker B: Discoverability-versus-demand diagnosis as the correct intervention type selector. Now something whole.

Build a product launch management platform: manage the full lifecycle of product and feature launches from planning through post-launch analysis. Support pre-launch checklists, go-no-go decisions, deployment vitals monitoring, automatic rollback triggers, adoption tracking, and post-launch retrospectives. Identify stillborn and fading features and recommend interventions. Generate executive launch reports showing success rates, rollback rates, and feature adoption across all launches in a quarter.

Speaker B: Product launch platform manages planning, checklists, go-no-go decisions, vitals monitoring, rollback triggers, adoption tracking, retrospectives, stillborn and fading feature identification with recommendations, and quarterly executive launch reports — the AI builds the full launch lifecycle management platform.

Speaker A: Post-launch retrospectives — structured reviews of what went well and what failed after each launch — close the learning loop that prevents the same launch failures from recurring: a team that deploys a stillborn feature, retires it, and immediately moves to the next one without retrospective will repeat the same planning or development failures that produced the first stillborn; the retrospective is the mechanism by which launch quality improves over time.

Speaker B: Post-launch retrospective as the launch quality improvement learning loop mechanism. Last one — content viability analyser.

Write a content viability analyser for a publishing platform: after each piece of content is published, monitor its performance for the first forty-eight hours — views, shares, comments, and time on page. Classify content as thriving if it meets engagement thresholds, growing if it is on an upward trajectory, plateauing if growth has stalled, or stillborn if it has received no meaningful engagement within twenty-four hours. For stillborn content, generate a diagnostic report suggesting whether the issue is headline quality, timing, topic relevance, or distribution reach. Recommend actions to revive stillborn content or retire it gracefully.

Speaker B: Content viability analyser monitors views, shares, comments, and time on page for forty-eight hours, classifies content as thriving, growing, plateauing, or stillborn, generates diagnostic reports for stillborn content identifying probable cause, and recommends revival or retirement actions — the AI builds the performance tracker, the classifier, the diagnostic analyser, and the action recommender.

Speaker A: Classifying stillborn content by probable cause — headline quality, timing, topic relevance, or distribution reach — makes the diagnostic actionable: a stillborn article with strong distribution reach but low click-through rates points to a headline problem; one with low reach but high engagement among the few who saw it points to a distribution problem, and the different diagnoses require completely different interventions.

Speaker B: That is the goal — one sobering word, better-managed launch and adoption systems. Keep it in your kit.