By Michael Woloszynowicz

By Michael Woloszynowicz

Monday, May 9, 2011

Giving Developers Feedback

As a product manager, founder, CEO, developer, etc., you've undoubtedly had to provide developers with negative feedback on one or more feature implementations. What I would like to emphasize is that the way in which you deliver this feedback greatly impacts the success of that feature as well as the productivity and output of your developers going forward.

To make the advice more memorable, I've consolidated it into point form:
  • Critique is necessary for creating a great product, but done wrong it can lead to a terrible product.
  • Know that when designing and implementing a feature for the first time, both you and the developer are probably wrong. Iteration, not interpretation, is the only way to perfect a feature. Rapid iteration through continuous deployment is the beauty of writing web applications. 
  • Never design by assumption, if something is wrong explain why it's wrong based on quantitative or qualitative data. Simply saying something is wrong is not helpful, if you can't justify it based on some form of user interaction or UX pattern violation, it's probably not wrong. Good developers won't argue with concrete evidence. 
  • Try not to provide solutions, re-iterate the problem you are trying to solve and let your team design a solution. 
  • Backtracking and changing the implementation of a feature when it's ready for deployment is a form of waste. The feature will be not be perfect either way so release it to a small percentage of users and iterate from there. 
  • Few things anger a developer more than working overtime for weeks on a feature, only to have its deployment delayed at the 11th hour due to trivial issues. Unless there is a tremendous oversight (which there shouldn't be at this stage), deploy at all costs, even if only to a small percentage of users. 
  • Ask your developer how they arrived at their solution, what was their interpretation of the problem? They may know something you don't. 
  • When a developer is working on a large feature for an extended period of time, they become emotionally attached to their work. If you put down their work you are effectively putting them down. When giving feedback don't dwell on small oversights or issues, emphasize the positives and discuss what can be improved going forward. Make a list of potential changes and validate them through user feedback. 
  • If you are non-technical, always remember that there is more to a feature than meets the eye. On the surface Google search is just one text input box, that doesn't make it easy to implement. If something took longer than expected or failed, ask where the challenges were and what could have been done to avoid it. Remember, you're not just trying to improve this feature but all features going forward. 
  • If you've hired right, your developers and designers are skilled and creative people. Trust that given the right information they will produce a good product. Your job as a member of the customer development team is to provide this information through insight about the end user and their problem. 
  • Keep feedback meetings short, ideally no more than 15-30 minutes. Nobody wants to hear about how bad something is, or potential solutions for hours on end. Developers want insightful advice and then get sent off to work on it. 
  • Follow the principles of the lean startup where iteration and improvement is based on feedback loops. Remember that a loop must always start with delivering the feature.
Developers are not timid creatures that can't handle feedback, but the best developers are passionate about their work and view their work as a reflection of themselves. They genuinely want to create a great product, but to do so they need feedback, direction, and information, not conjecture.

If you liked this post, please Tweet it, or follow me on Twitter for more. 

No comments:

Post a Comment