Unexpected Responses to Requirements

 

At the World Bank, I was product manager for the content publishing platform for the thousand+ World Bank sites and we had a seemingly-endless list of requests from the hundreds of content contributors for improvements.  The list of requests always grew more than it shrank.  One time, the lead developer said he had an idea to completely change the first page people saw when they logged into the CMS.  But no one had asked for this.  I have to admit, I was nervous about prioritizing this change over our huge backlog of requests.  In the end, we went with it.  Guess what?  The CMS users were thrilled.  It helped both power and occassional users.  And no one complained that item #428 or whatever wasn't implemented to make room for this change.

 

There are probably lots of lessons to glean from this little story, but the one I'd like to emphasize here is that it's ok to give an unexpected response to the "requirements" that you people may lob at the central team.  Sometimes it's even ok to ignore what people are saying and instead give them what they need.  They might be delighted (at least for a while!) rather than everyone complaining about request numbers.  Of course, this requires finess, skill, and a bit of luck -- and you can't ignore your stakeholders in general.  But when getting into the decisions of what gets implemented, listening to the deeper needs of the teams are more important than literally what everyone is saying.

 

----------------------

 

I'll be writing more about defining requirements and also improving engagement with internal teams.  In the meantime, you can download this new report: Better Engagement for Ongoing Website Improvements.