“Why Don’t My Developers Build What I Asked For?”
There are many reasons why technology projects go over the cliff, but the inability to clearly communicate between product owners and developers is at or near the top of the list. It’s remarkable how often teams will go through cycle after cycle of bad results, waste copious quantities of time and money, and not adjust their process to change the outcome.
If, as the product owner, you’re asking for A and getting Z, it’s 100% your fault. That’s what being an owner means. So, if you find yourself frustrated with the team delivering the wrong thing, here are some probable causes and fixes.
Living In Your Own Skull
Assumption is the mother of all f**kups as the saying goes. You’ve got context from meetings with customers, your run this morning, a chat with an investor, or any other number of inputs that more than likely your developers weren’t a part of. Just because you draw something on the white board, or create a wireframe, doesn’t mean that you’ve clearly articulated the entire picture.
To get what’s in your head out, do the following:
- Slow down. By simply doing less at a time, you can work on fixing the process with less moving parts. If you have to, do one feature at a time.
- Have the team repeat back to you, in full detail, everything that needs to be done. “When we click this button, these three things should happen.” If you’re expecting four things to happen, and you didn’t hear it in their response, then you have to stop and go back over it. I can’t tell you how many times I’ve caught glaring gaps in my thinking just by having someone repeat back to me what we just covered.
- Use tools like InVision to collaborate and capture details where they can be viewed later
Infrequent Check-Ins
There’s a misconception that because you define work in chunks that you have to wait until the end of that chunk to see what’s been done. Even if you’ve done a great job of communicating, and it seems like everything’s clear, it’s still possible that the developers will make a wrong move. The longer you wait to review, the more time and money you waste, the more upset you get, and death spiral.
One of the most practical things you can do as the product owner is check in on progress more regularly. Review interim builds of the current features with the team and discuss what you’re seeing. This doesn’t have to go on forever, but until you see better results, get more involved day-to-day.
Wrong Team
It’s possible that, after implementing the best possible processes, that you still have a problem, and you’ve got to change things up on the team. I purposely put this last because it’s by far the most costly thing to adjust in the equation.
If you’ve got to make a change, make sure that you adjust your hiring process so that you don’t have the same problems with the next person. Assess your ability to work together in the interview process rather than after they’re already onboard.
Just Remember
- If you’re not getting what you’re asking for from your team, it’s up to you to fix it
- Bad results are most often the result of bad process, not bad people
- Ask your team what the problems are from their point of view
Your Assignment
The next time you take your team out for drinks after work, ask them for their candid feedback on what you can do better in communicating product requirements. Then, take one or two of the things they suggest and implement them immediately. By asking for input and then adjusting, you’ll demonstrate that you value their opinion, and they’ll be more open in the future.