Run a technical health check before the next roadmap
A product roadmap assumes the delivery system can absorb new work. If builds are slow, tests are unreliable, deployments require heroics, or incidents consume the same people who must deliver the roadmap, every date starts from a false baseline. A short technical health check makes those constraints visible before commitments are made.
Measure delivery flow
Review change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework. The current DORA software-delivery metrics provide a useful common language for throughput and instability. Use trends for one product or service, not league tables between unrelated teams.
Inspect code and dependency risk
Identify modules with concentrated change, low test confidence, unclear ownership, obsolete dependencies, and manual release steps. Confirm that the repository can be built from documented instructions and that secrets are not embedded in code or pipelines. Sample a few recent changes from ticket to production to expose hidden handoffs.
Test the deployment and recovery paths
Verify that staging resembles production where it matters, releases are reproducible, database changes have a rollback or forward-fix plan, and backups can actually be restored. Review the last incidents for detection time, decision quality, recovery steps, and unresolved actions.
Map security boundaries
Document identities, privileged roles, public endpoints, third-party integrations, sensitive data, and software supply-chain controls. CISA’s Secure by Design guidance is a reminder that customer security outcomes should influence product architecture and defaults, not remain a late penetration-test item.
Check observability against user journeys
Dashboards should answer whether important journeys work, not only whether servers are running. Confirm ownership for alerts, remove noisy signals, and make sure logs, metrics, and traces can be correlated during an incident. Review on-call load and recurring manual work because burnout is a system constraint too.
Review data health
Find critical tables and pipelines without an owner, quality checks, retention policy, or recovery objective. Measure failed jobs, reconciliation gaps, and manual corrections. A roadmap dependent on unreliable data needs foundation work scheduled explicitly.
Turn findings into roadmap capacity
Classify each issue by user impact, likelihood, recovery difficulty, and delivery drag. Then divide the roadmap into value work, risk reduction, and platform improvements. Give every foundation item an observable outcome—for example, restoring from backup within an agreed time or reducing deployment rework—rather than a vague “refactor” label.
The result is not a long audit document. It is a shared baseline, a small set of priority risks, and a roadmap the delivery system can support. Qomra Tech uses this approach to help founders replace optimistic estimates with an evidence-backed plan for reliable growth.