I have big plans for this code

I was recently scrolling on reddit and came across this fantastic comic strip. A tweaked version of the TheyCanTalk.com comic, called “Plans”, the original, of course, doesn’t mention code or refactors, more dams.

I immediately sent it to my product owners as a (partial) joke, as it made me think of how I often present a block of work to them, without thinking how best to communicate it effectively.

In my mind, the beaver saying no more refactoring, just can’t fathom why the refactor is necessary, which is a communication mishap. Bob Iger has a nice way to sum this up:

Your strategy is only as good as your ability to articulate it

This doesn’t mean you need to simplify what you’re saying to product owners/managers like they’re five. They live in a different world to us software developers, their prioritizes, lexicon, and contexts are different. Software developers need to acknowledge that, and be aware of these differences to ensure we’re communicating effectively. This often requires adjusting a message to its audience.

I’ve been very fortunate to work with incredibly talented (and forgiving) product owners in my career, who always take the time to understand my asks before giving me a decision. From this I have learnt some things that help clarify an idea to them, which I can boil down into three main points to follow whenever I need to “sell” a technical initiatives to a PM.

1. Speak their language. Technical specifics aren’t the most valuable content right now. Adjust your message to be more business focused. There is a place for the technical specifics sure, but don’t lead with them. Minimize use of unnecessary acronyms or at very least define each of them first.

2. Demonstrate business value - The value of this grand and mighty project you’re proposing might not be immediately identifiable. Don’t be surprised when you’re asked to quantify its value and impact. Don’t think of it as them saying it’s not impactful, understand it as the impact is not clearly understood, if it’s not for them, then it certainly won’t be easy for them to advocate for it. A wonderful shortcut here is figure out a way to tie it to some of your organization’s quarterly or annual strategic goals. After all, if this project doesn’t help with these goals in some way, should we even be doing it?

3. Manage risk. Always be on the lookout for any way to reduce scope and keep iterations small. This makes the project much more likely to be slotted into a roadmap as it doesn’t disrupt the large amount of work your PMs do to manage the roadmap. I’ve found being more risk-adverse means fewer injections that sap even more of your development teams’ sprints.

In the end, I’ve never really seen this as needing to convince people. It is always about communicating effectively with product managers. Give your PMs the ammunition to defend the direction when asked, let them advocate for it, the same way; we should be advocating for the products they own.