Does my Dev team suck?
What can I do if I have an underperforming dev team building my product?
Does it seem like your dev team hasn’t been…performing up to speed lately? Are you seeing frequent user complaints and rework to fix problems created based on the work being pushed to production?
Here are three takes on what may be contributing to your product development team's poor performance and what you could do to help improve the situation:
Constantly changing priorities can kill dev team morale (and their productivity).
What’s the problem?
Here’s a scenario: you gave the green light to your dev team to build. The next day someone in the C-suite knocks on your door with the most excellent idea to ever be spoken of in your industry, and they want it made and shipped “tomorrow.” You have to round up the dev team to explain what the new changes are and put a full stop to the freshly started work.
If you’ve had a conversation with a team dev who has gone through this, you’ll quickly understand the trauma this can cause. The more often this type of pivot happens, the less trust your team will have that you’re making the right decisions on what should be built, and the relationship will begin to erode.
How might we make it better as product managers?
Having more frequent conversations with stakeholders who may be prone to make last-minute requests can assist with alignment between you both. The alignment will help better understand your stakeholder that you are having teams build the right products, and slowing down the consistent changes will give your dev team time to focus and bring your vision to life.
Your dev team is not close enough to understand your users and cannot make the best connection between your user and your requirements.
What’s the problem?
Your dev team is reading your fancy business requirements document and trying to figure out what they should build. However, as in many organizations, your developers have only looked at your product and what the code has produced and has never seen a user touch the software.
Additionally, I have often seen developers who may be vital in backend development take on frontend work. They do not have a basic understanding of best practices from a user experience perspective. Give them the time to build on what you’re asking for, and you’ll find this out pretty quickly (and unfortunately).
How might we make it better as product managers?
As product managers, we know it’s on us to ensure our product directionally brings our users to that delighted state. User experience is one of the critical components here, and I have a few suggestions:
Bring your dev team into a few conversations with users as you are beginning to shape your request. This will help the dev establish some empathy with the user.
Working with your dev team on the formatting/quality of the requests you are passing to them to ensure you are supplying enough information is critical. Adding one line in the typical user story format is not enough to provide the best product gets built, so invest the time to build better work items.
After launching, loop back with user feedback and enhancement performance metrics to close the loop. If things are going well, the team can see morale, and if there’s an opportunity to do better in the future, they should be made away and take these learnings into the next sprint.
Your dev team doesn’t seem to understand the product’s direction/strategy.
What’s the problem?
Maybe your dev team is excellent at coming up with solutions that fill precisely what your user needs based on your write-up. Awesome! However, what happens when you are interested in expanding into a broader or larger user base, and the built solution needs a complete rebuild because of limitations that weren’t sorted out when the team first discussed the work? A lot of time (and money) will be spent building things again and will not bode well for the product manager/dev team relationship.
How might we make it better as product managers?
As a product manager, you need to be willing to have conversations with your dev teams and invest the time in building their understanding of where you want the product to go in the near and long term. Although they may wish to negotiate and agree to make an MVP solution, you should be able to help put the understanding into the back of their mind that this solution, if successful, may need to be able to scale quickly.
Conclusion
Product managers can contribute to growing and developing stronger development teams. Investing the time in having deeper conversations and empathizing with your developers can build relationships between the groups, bring consistency to the product, help with more efficiently bringing enhancements to market, and ultimately help you get the most delightful product possible to your users.
Unrelated to the Product Party Substack, I did want to share one great article I found by Justin Etheredge called “20 Things I’ve Learned in my 20 Years as a Software Engineer”. As product people, we invest significant time in understanding the people we build for. However, we should also invest time to grow relationships with the people making our products. The better our relationship with dev teams, the more willing the team will be to invest their time and effort into creating solutions our customers will love.
Want to discuss the article above more? Click to leave a comment below and let’s go!
Follow Product Party on Twitter