Turning Tech Modernization Initiatives into Strategic Investments: A Product Mindset for Engineers
- janel238
- May 28
- 10 min read
Updated: 3 days ago
Every year, companies spend millions on tech modernization - yet most of that investment lacks clear strategy, prioritization, or impact metrics.
At GoFundMe, I recently had the pleasure of working with their exceptional engineering team on a challenge many orgs face: how to prioritize and communicate technical initiatives (modernization efforts, platform upgrades, tooling improvements, and infrastructure investments) in a way that earns alignment, focus, and investment. Engineering-led work competes for the same resources as product work. If we can’t explain why something matters - why now, why this way, and what the outcome will be - it’s hard to win support.
The Problem: Engineering Investments Fail to Land
Most engineering leaders I work with aren’t short on ideas. They’re short on frameworks for making those ideas legible to the rest of the business. Which means big investments get greenlit based on gut feel or perceived urgency - and then executed without the structure needed to know if they’re actually working. This doesn’t just waste resources. It erodes trust. According to McKinsey, nearly 70% of digital transformation efforts fail to meet their intended outcomes, often due to lack of clear goals, prioritization, and accountability. We can - and must - do better.
You’ve seen this movie before - in each of our organizations we have capital to invest in improving our tech stack, whether it’s earmarked for “tech modernization” or “tech excellence” or “digital transformation”, and we have plenty of ideas on how to spend it. Gartner forecasted that global IT spending would reach $5 trillion in 2024, with a growing share earmarked for modernization, developer productivity, and platform resilience. But investment ≠ impact without clarity and alignment. As engineers, we instinctively know where we need to invest - whether it’s in scalability, performance, security, stability & reliability, or developer experience that could materially improve how we build and ship.
This is a common pattern. Engineering leaders know where the technical debt lives. They know what’s slowing teams down or putting the system at risk. In fact, a 2021 report by Stepsize found that 58% of engineering teams say technical debt negatively impacts their team's morale, and 66% say it slows down product development significantly.
But too often, these ideas compete poorly with shiny new product features - not because they’re less valuable. It’s because they are not framed in a way that helps us make the best possible decisions or to champion at the leadership table. Clarity drives better decisions. When we skip the problem definition or leave out success metrics, we risk solving the wrong problem - or solving the right one in a way that misses the mark. And to secure alignment, investment, and momentum, we need to communicate these initiatives as clearly and rigorously as we would a product feature, in a way that makes their value clear.
For those engineering orgs who are lucky enough to just get a tech initiative budget allocation each year, without having to sing for their supper, their ideas for how to spend said budget are just a long list of ideas - unstructured, unprioritized, and tackled in the order it was written. Not based on strategic priority. Not based on business need or ability to enable our current strategic business objectives. Just… in random order or based on he-who-yells-the-loudest.
And in the cases when something does get prioritized and funded, success metrics are rarely defined upfront. Or they are defined alright, but as outputs (did we build & deploy service X for the website to call), rather than outcomes (did we increase page load speed by Y seconds). Only 12% of engineering teams regularly define success in terms of business or user outcomes, according to a 2023 State of Engineering Productivity report by Code Climate. I have offered the challenge (and a $20 bet!) many a time to my engineering partners but haven’t yet met a tech initiative that can’t ultimately be tied back to a business or customer problem (or opportunity) – and that’s where the real magic is. The best technical investments show a measurable impact. Not every initiative will drive a revenue KPI directly. But every one should affect something meaningful - system health, developer velocity, operational efficiency. These are the foundations of sustainable business outcomes. Without this, when we solely focus on outputs (Booleans like “did we migrate system x” or “did we deploy tool y”), there’s no clear way to evaluate progress, no way to make smart mid-course corrections, and no real accountability - either to continue the project into the next quarter, invest to do more of this in other areas of the tech stack, or to stop and pivot when we see it’s not delivering the value we expected.
The result of these issues? Teams ship technically elegant solutions that are invisible to the business. Stakeholders lose confidence, and budgets start to shrink. In fact, 50% of CIOs say technical projects without clear business metrics are the first to be cut in budget reviews (PwC Digital IQ Survey, 2020).
I saw this firsthand at another org: a major investment was made in observability tooling to reduce downtime. But no baseline metrics were defined. Months later, despite shipping solid infrastructure, the team couldn’t demonstrate whether MTTR had improved, or on-call fatigue had decreased. The initiative was quietly defunded the following quarter.
And when the next critical investment needs support, engineering’s case falls flat - regardless of how urgent or justified the work may be. Why? Because, as one recent study found, executives report their top frustration with engineering leaders is the inability to clearly tie technical initiatives to business outcomes (Harvard Business Review Analytic Services, 2022). But it doesn’t have to be this way.
This is where the product mindset becomes essential. At its core, it’s about connecting effort to impact. Defining the problem. Clarifying the outcome. Identifying how we’ll measure success. These are not “product skills.” They are strategic leadership skills.
The Opportunity: Think Like a Product Leader, Even for Internal Tech Work
In the product world, we obsess over understanding the problem, defining the outcome, and measuring what matters. We iterate. We test. We stop doing things that don’t work. All in the name of investing in the right things, for the right reasons, at the right time, with the right outcomes in mind.
Why should engineering investments be any different? If anything, they’re even more strategic. They affect every team, every product, every future user/customer experience. When we invest millions into tech modernization, developer experience, or platform resilience, we’re shaping the foundation for everything the business will try to do in the next 1–3 years. That’s not just important work - it’s high-leverage work. But unless we apply that same strategic rigor and product discipline - clear framing, sharp prioritization, measurable goals - we’re flying blind. And worse, we’re spending real time, energy, and money… with no clear way to know if it’s working.
When engineering leaders adopt a product mindset, three big things change:
You stop working through the list and start making strategic choices.
You stop treating every idea as equally urgent and start thinking in terms of outcomes, trade-offs, and return on effort. You anchor your work to outcomes, not just ideas. You make decisions that ladder up to the business strategy - not just what’s loudest or latest = better decisions about where and how to invest.
You create visibility and accountability.
Success is defined before the work starts – in terms of the outcomes you’re aiming to drive. That gives you the leverage to adjust course, double down, or stop - based on real impact, not opinion. This doesn’t just make your work easier to defend - it makes it easier to manage. Teams know what success looks like. Stakeholders know what to expect. And leadership sees you not just executing, but leading - with the data and discipline to back up your decisions.
You grow your influence.
You’re not just a technical executor. You’re not just asking for support – you’re co-owning the roadmap with a shared understanding of what drives value. You become a strategic partner who can frame trade-offs, surface insights, and co-own outcomes = stronger partnerships with product and business leaders.
And perhaps most importantly: your team feels the difference. They’re not just grinding through tickets - they’re solving meaningful problems. They can see how their work contributes to real outcomes, and that clarity fuels engagement.
Gallup research backs this up: employees who understand how their work connects to organizational goals are 4.6x more likely to feel empowered and engaged, and they’re far more likely to stay. On the flip side, employees who don’t see that connection are 2.5x more likely to feel disengaged and leave within a year (Gallup, State of the American Workplace).
Let’s make it real with a developer experience example since that’s often one of the hardest to justify and easiest to deprioritize. And a critical one, as research from a Stripe and Harris Poll shows that developers spend more than 40% of their time on maintenance and debugging, and poor developer experience is estimated to cost companies over $85 billion annually.
Imagine your team proposes investing in a new internal dev environment tool. It promises faster spin-up time, more reliable builds, and fewer environment config issues. The idea makes sense. So, it gets greenlit.
Fast forward two quarters. The tool is built - but adoption is patchy. No one’s quite sure how much time it’s saved. Some engineers love it; others haven’t switched. Execs ask what the return has been. You don’t have the numbers.
Now rewind. Instead, you define the problem upfront: “It currently takes new engineers an average of 1.5 days to get a dev environment up and running.” You define success: “Reduce environment setup time by 70% within one month of rollout and increase NPS of onboarding experience from 6 to 8+.”
Now when the tool rolls out, you track adoption, time saved, and satisfaction. You find that teams using it are shipping their first PRs a full day earlier. You share those results. Now other teams are asking to onboard, and your leadership team is asking, “What other experience bottlenecks should we fix next?”
That’s the difference. Same investment. Very different story. And it all starts with thinking like a product leader.
The Solution: Build Your Product Muscle
I know all too well that engineers and engineering leaders are constantly balancing delivery pressure, firefighting, and tech debt. But just like going to the gym each morning when you’d rather be sleeping, carving out the space to invest in this critical mindset shift (and practical tactics) is short term pain for long-term gain.
Investing in Tech Excellence Roadmap workshops isn’t just about sorting through technical initiatives (though we do that too). It’s a leadership workout. It gives engineering leaders a chance to practice this mindset in a tangible way - taking real initiatives and framing them with the clarity and structure they’d expect from a great product manager. We turn ideas into hypotheses, connect the dots between assumptions and success metrics by building out logic flows, and we practice storytelling to sharpen and stress-test our thinking. It’s not theory. It’s high-impact, hands-on learning embedded in work they already need to do.
And it’s transformative. Because when engineering leads start thinking this way, they don’t just get more traction for their ideas. They grow into stronger, more strategic partners - able to lead not just the “how,” but the “why.” In organizations where engineering leaders consistently link technical work to business impact, those teams are 2.3x more likely to be included in strategic decision-making (Harvard Business Review Analytic Services, 2022).
The workshops I recently ran at GoFundMe helped their engineering leaders put this into practice. Not in theory. Not with case studies. With their own roadmap.
The bonus? While we were creating structure for tech investments, we were also developing stronger leaders - engineers practicing the same critical thinking, storytelling, and accountability mindset that makes great product managers indispensable.
“These workshops help build leaders while building the tech roadmap”, GoFundMe SVP of Engineering Janahan Vivekandan
It’s not just about doing the work better. It’s about leading better.
In each session, across different organizations in different industries, with different tech investment objectives, I’ve seen a real shift because engineering starts thinking like product managers:
From “We just need to do this” → to “Here’s the outcome we’re driving”
From “This helps our infrastructure” → to “Here’s how it improves delivery, or stability”
From “This matters to engineering” → to “This matters to the business, & here’s why”
Engineering leaders walk away with a set of initiatives framed for real decision-making - prioritized, aligned, and backed by the logic needed to make a compelling case.
Want help translating your tech backlog into this kind of strategic story? That’s exactly the kind of work I do with teams. But even if you don’t bring me or someone else in, bringing this mindset in will change the game for you – and that’s a win! Here’s how you can infuse the mindset if you're a senior leader (CTO, CPO, CFO, etc.) funding engineering work:
Ask to see the framing behind major tech initiatives. Is there a problem statement? Success criteria? A tie to business outcomes? If not, you’re likely spending without strategic clarity - and missing an opportunity to grow your engineering leaders while you’re at it.
You’re already doing the work. The real question is: are you doing it in a way that builds trust, drives outcomes, and grows leadership along the way?
If your team is sitting on a long list of good ideas but struggling to prioritize or get traction, this mindset shift might be exactly what’s missing. For engineers ready to level up how they scope, frame, and win support for technical investments, there are a few ways we can work together: In-context 1:1 coaching, join one of our small-group public workshops, or we can create a tailored session for your full engineering team.
Sign up for our July 17 workshop now!
Curious? Let’s riff. I’m happy to talk through what might fit – you can reach out at janel@peerlesspartners.net.
And for now, just this: if your engineers aren’t thinking like product people, you’re leaving strategy - and influence - on the table.
📚 Sources
McKinsey & Company
"The keys to a successful digital transformation." October 2021.
https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights
Gartner
"Gartner Forecasts Worldwide IT Spending to Grow 8% in 2024." October 2023.
Stripe & Harris Poll
"The Developer Coefficient: How much is your developer experience costing you?" 2018.
Stepsize
"State of Technical Debt 2021."
Code Climate
"2023 State of Engineering Productivity."
Harvard Business Review Analytic Services
"Engineering’s Role in Strategic Business Decisions." Sponsored by Jellyfish, 2022.
https://hbr.org/sponsored/2022/08/how-engineering-leaders-can-gain-strategic-influence
Gallup
"State of the Global Workplace: 2023 Report."
https://www.gallup.com/workplace/349484/state-of-the-global-workplace.aspx
PwC Digital IQ Survey
"2020 Global Digital IQ Survey."
https://www.pwc.com/gx/en/services/consulting/digital-iq.html
Comments