Direct answer
As SDET (Software Development Engineer in Test) lead, treat the automation roadmap as an investment portfolio, not a single up-or-down bet: prioritize by expected reduction in the cost of the failures that actually hurt today (frequent flaky escapes, slow manual regression cycles) rather than by raw coverage percentage, fund it in small increments that ship alongside feature work instead of asking for a dedicated quarter, and report return on investment (ROI) in terms both engineering leadership and product understand, mainly time saved and incidents avoided, not "test count."
Structured elaboration
Prioritization. Rank candidate automation work by a rough cost-avoided-versus-effort ratio: what currently costs the most in engineer time or production risk (a manual regression pass that takes two days before every release, a class of defect that keeps escaping to production) goes first, ahead of comprehensive coverage of low-risk, rarely-changed code. This naturally produces a roadmap that pays for itself early, which is the strongest argument you can make for the next round of investment.
Building buy-in. Buy-in comes from evidence, not advocacy. Pick one painful, visible process (the slowest manual regression cycle, the flakiest recurring incident) and automate just that first, then show the before-and-after directly to both engineering leadership and product: how much manual time it used to cost, how much it costs now. A single credible before-and-after story does more for buy-in than a roadmap deck ever will.
Measuring ROI without inventing precision. Track a small number of things that are actually measurable: manual testing time avoided per release, count and severity of defects that would previously have escaped to production, and release cycle time before versus after. Present these as directional trends over successive releases, not as a single fabricated efficiency number, since a portfolio of automation work rarely reduces to one clean metric.
Balancing delivery pressure against reliability investment. Frame automation work explicitly as reducing a cost the team is already paying, manual regression time and production incident response, rather than as new overhead competing with features. Time-box the automation work as a fixed, small percentage of each sprint or cycle rather than asking for a dedicated block up front; a steady, visible trickle survives budget pressure better than a large ask that's an easy target to cut when a deadline looms.
Staying at the right altitude. This is a prioritization and buy-in problem, not a framework-design problem: the tool choice and test-suite architecture matter far less to leadership and product than the fact that a genuinely painful process got measurably faster and safer.
Worked example
A team's release process includes a two-day manual regression pass before every release, and roughly a quarter of releases in the past few months have needed a hotfix within a week because the manual pass missed something under time pressure. Instead of proposing a broad "increase automated coverage to eighty percent" initiative, which is hard for leadership to evaluate and easy to deprioritize, the roadmap targets that specific regression pass first. Automating the highest-traffic regression paths takes a few sprints, folded in alongside normal feature work rather than as a dedicated block. The next release cycle, the manual pass shrinks from two days to a few hours of spot-checking, and the hotfix rate in the following few releases drops noticeably. That specific, concrete win, not an abstract coverage target, is what gets the next investment approved without a fight, because both engineering leadership and product can see exactly what it bought them.
Trade-offs and pitfalls
Chasing coverage percentage as the primary metric is the most common trap: it's easy to report but doesn't track with actual risk reduction, and a team can hit a high percentage while leaving the riskiest, most complex paths untested because they were hardest to automate. Asking for a large upfront investment before showing any win is a hard sell under delivery pressure and an easy target when priorities shift. And framing automation purely as "quality work" rather than tying it to a concrete cost the business already feels (release delays, hotfixes, manual toil) makes it compete directly with features for the same attention, a fight it usually loses.
