👋 Hi, I'm James.


I occasionally write about lessons learned on the journey to live a healthier, happier and more intentional life. 


📍 Austin, TX 

🌎 ✈️  👨‍💻 💸 🗽 📚 💡 🏄‍♂️ 🏋️ 🚲 🧘‍♂️ ☀️ 🌊 ⛰️ 🥩🍷

  • James von der Lieth

How Product Managers Can Earn Developers' Respect, Gain Influence and Stay Organized

Updated: Dec 2, 2019


I wrote this piece in late 2018. At the time of the writing I was working at a company with ~150 employees. There were 8 software developers, a product designer and a few other shared resources working on the products I was responsible for at the time.

Product Management is Leading by Influence, not Authority

I can’t code one bit. So in baseball terms, I was starting behind in the count when I came on as the first product manager with zero product development experience. Before we raised money and had a development team, I was managing a team of 8 people who were all older than me. Back then, I was used to my team bend to my will because I was the boss; but in product management, people have to listen to you voluntarily because they trust you. Makes sense. I can’t code — why should they listen to me? Still, it was a completely new dynamic for me.

Being Organized and Influential as a Survival Mechanism

I realized early on that in order to earn the respect of the developers as their product manager peer, I had to be the person who can make things happen in the organization and get coworkers, and more importantly customers, excited about their hard work. In other words, I could make up for this coding deficit by building rapport with as many customers, team members and stakeholders as possible. I had to bring glory to their work.

But how do you do that when you’re in an onslaught of tasks, problems, bugs, training, requests, and questions? In order to create the time and energy to build influential relationships, I needed to build a principle-based organizational system. Here are some strategies and specific tactics from my work-in-progress system that improves a little bit everyday.


  • Product vision is important, but organizational excellence is truly what gives team members initial faith in you.

  • There is no excuse for something slipping through the cracks — even if someone gives you something in a format that you don’t prefer.

  • That said, mistakes happen and you will drop the ball once in a while. Take responsibility immediately, apologize, then figure out how to fix your system so it doesn’t happen again.

  • To gain influence, people must trust that if they give you a problem/idea you will get it prioritized and taken care of. Trust is earned.

  • For assigning tasks to developers: Kanban Boards > Google Sheets > Email > Slack

  • Don’t be the person who “taps people on the shoulders” about non-urgent items. Queue up items for set meetings. Allow team members to reach flow state without bothering them.

  • Meetings are often a complete waste of time. People who don’t value their time will try to get meetings on your calendar.

  • When possible, OHIO = Only Handle It Once. Every time I deal with an issue, I ask myself, “What one thing can I do to make this issue irrelevant in the future?”

  • Organizational systems should allow you to see high-level AND drill down to the detail

  • Be flexible! Rigidity is what happens to dead bodies.

  • Don't agree with everything; don't disagree with everything


  • Any task that I can’t complete in less than 2 minutes goes in Hive Kanban Board. If it can be dealt with in less than 2 minutes, I just do it.

  • I always try to kill meetings that get put on your calendar before they happen if it can be solved with a 2 minute chat or email. The setup of the meeting, small talk, etc can make meetings a huge waste of time

  • Your Calendar should not be used for tasks. It should only be used for hard events that have a definite start time. All tasks should go on the Kanban board.

  • If it makes it on the calendar, it happens. On Time. Period

  • Stack meetings together, when possible. This way you can be in a “meeting mode,” and then have blocks of empty time to focus on synthesizing.

  • Whenever there are no meetings scheduled, work remotely. If you are physically present, people will fill your time with problems. If it's really important it will get to you.

  • Write ideas down first before starting on them. An idea sounds great when it first pops into your mind, but unless it's clearly urgent, give it a few days to see if it still seems like a good idea. No one wants to be led by a person who is all over the place and is constantly changing priorities.

  • Make sure people feel heard by taking the time to respond with an acknowledgement and thoughtful response. Give them explanations for how their problem will be fixed in the short term and in the long term product vision

  • For every product issue I have the reporter go through Zendesk. This way the product support team can be the first line of defense.If I’m still compulsively checking Slack on the weekends, I’ll just delete it from my phone until Monday morning

  • Archive every email once its dealt with

  • Train everyone in the organization not to blow you up on slack unless it's extremely urgent. Every problem should go to our internal support team in Zendesk. If it's not getting resolved after sometime, they can reference the ticket in a slack.

  • Unsubscribe from every email that isn’t informative or doesn’t give a non-automatable action item

  • Recently, we started using new, private Slack channels for each big development project so all communication is transparent and available to the QA engineer. This has worked great, since there are often multiple projects moving at once and it's difficult to follow threads in large channels.

  • Right now, I still use Google Sheets for all our roadmaps. Its definitely not the most effective process, but Jira doesn’t yet have a good enough solution for external stakeholders.

  • Use notifications for their true purpose of notifying you with critical information. If it's not critical, turn the notification off or filter it out.

  • Kanban board has 5 columns: Un-started, In Progress, Designer, Waiting On, and Complete. “Designer” is for small tweaks I want to go over with the product designer, rather than sending sporadic annoying slack messages. “Waiting on” is for items in other people’s courts that affect my results or promises I’ve made. Each day I’ll start by checking statuses of items in “Waiting on” then move on to prioritizing items in “Un-started”.

  • Learn which team members consistently don’t need to be followed up with. Stop using the “Waiting on” status for them. They will get it done, and it's one less thing you need to track.

Other Great Resources to Learn Product Management

Subscribe to New Blog Posts

Thanks for subscribing!

Recent Posts