My process for pitching projects as an engineer

This winter break has finally given me the mental space I needed, so I wrote another work-related article this month¹, yay! This time, I’ll focus on my personal process for pitching projects as an engineer.

Ever had a great idea at work but struggled to get it on the roadmap? As an engineer in an environment where product work is primarily driven by product managers, I’ve learned how to turn ideas into team priorities. The good thing is: there is no need to be a lead engineer for that!

From idea to proposal

Every project starts with an idea aimed at solving a specific problem². Focusing on small, self-contained problems is much easier than tackling something that spans the entire product or system. Addressing larger problems becomes easier with experience and practice.

I mainly do some research and talk to people. Sometimes, as an engineer who enjoys coding, I might also do some initial “hacking” to explore the idea and uncover potential issues. Though not strictly necessary, I find this helpful for uncovering technical blockers (I also love making cool demos 🙈).

The goal of this phase is to move the idea from a vague notion to a solid, credible solution for a well-defined problem. From experience, neglecting this step often leads to a half-baked proposal that lacks clarity and fails to gain traction.

Gaining initial buy-in

My strategy for socializing and building support for an idea usually involves three groups: my peers, my Product Manager (PM), and my manager. I typically move from peers up to my manager, adjusting my approach based on the feedback I receive along the way. This iterative feedback process is essential to me. It stress-tests the idea and maximizes my chances of success, even if the initial concept requires significant revision.

I aim to convince one or two peers. The burden of proof is entirely on me to sell the idea, which is why the previous step is so important. When the idea moves to the broader team or to the PM, having a peer vouch for its value shifts the dynamic from one person’s suggestion to a team-vetted proposal.

Once I have peer buy-in, I start a conversation with the PM. Product Managers are focused on business value, not engineering details. They usually need answers to the following questions:

• What is the value added?
• Why should this be prioritized now?
• What is the estimated time to production?

I’ve found that a concise document³ outlining the final state and answering these specific questions works best for engaging the PM. This is convenient because it’s the same format I use when approaching my peers, so I usually keep the same living document.

Securing manager approval

Once I have my peers and product manager on board, I approach my manager to discuss planning. In collaboration with the PM, my manager ultimately owns the team’s roadmap.

This isn’t the first time my manager hears about the idea, though. I maintain a proactive communication strategy, ensuring I give them a heads-up about developing ideas and significant technical explorations early. This prevents my manager from being caught off guard or, worse, hearing about a developing initiative secondhand from other stakeholders. It also allows them to provide early, high-level strategic guidance that might steer the proposal in a more productive direction before significant effort is invested.

The aim is to engage them at the right time: early for awareness and strategic input, and formally when a well-supported, high-quality proposal is ready for definitive planning and commitment.

Final thoughts

This is my approach to increase the chances of a project to make it onto our roadmap. Do note that this approach won’t always succeed. Ideas are sometimes rejected, and that’s okay.

With that said, I’d encourage interested folks to come up with what works for them, but that’s probably a safe start. If you’re one of them, remember that likely no one will care more than you do, so don’t drop the ball!