Organizing Stakeholder Requests

Problem

The team I am currently working with is responsible for content personalization; at the same time, it enables on-site visibility and traffic distribution for different stakeholders who produce content related to clothing and fashion. Obviously all of these content creators want to get as many impressions as possible while promoting something that they have created in the most efficient way.
What happened on my team was that there was a challenge with the way we act upon feedback when stakeholders began directly addressing developers with their problems and specific feature requests. Our developers were super responsive and tried their best to implement different things to support those requests. What we ended up with, however, were a bunch of shortcuts and fixes all over the place.

After some time in that life, the solution team was becoming really hard to maintain. It was quite difficult to ship new implementations and updates, and at the same time, the product user experience got extremely complicated. We were blindly focusing on implementing fixes and shipping short-term solutions.

Actions taken

As a product manager, I jumped onto this problem and decided that the biggest challenge was that we weren’t dedicating enough time to research the actual user problem before jumping to the solution. While collaborating with stakeholders developers did not spend time figuring out what would be the actual workflows, objectives, and end goals and that has led to suboptimal technical implementations.

We decided to enforce a bit of bureaucracy in order to think of ways to collect requirements and do requirement engineering in different ways.

We ended up with user story maps as the best way to describe requirements. We used Google Spreadsheets as the most convenient way for both technical and non-technical people alike. We began with the following columns on a spreadsheet:

• User Type → Who is the person trying to achieve something?
• Workflow → What are they trying to perform? What are they doing right now?
• Goals → Sometimes people use really crazy things to do very simple tasks. How can we figure out all of these inconsistencies in the goals they are trying to achieve?
• Ideal Workflow → We still want to be able to give them the opportunity to provide the ideal solution they see the best fit.
  

Lessons learned

• From this, we were able to associate a user story to the use case. Essentially, we created a new process on how we now collect requests from stakeholders.
• This helped us to create a small database of user stories in the spreadsheet. We then reviewed it monthly with the development team to find clusters where the problem is large and affecting many users or when it’s a smaller case. After monthly reviews, we were able to create tickets using user stories. This helped to more easily run the development and made everything more controllable.
• Lowering the number of requests made the whole process a lot more transparent for the stakeholders. They were now able to check if there was anyone with a similar issue and were also able to implement important things which helped a lot with prioritization.
• Using story maps helped to shift the whole focus from the idea of the solution to the analysis of the problem itself.
• If there is no way to facilitate the whole process, the development team ends up really overwhelmed and it can hurt the product strategy, as well as, the whole look and feel of the user experience in the long term. What I have learned over time is the importance of shifting the whole discussion towards the current workflow and what you are trying to achieve. As soon as you understand those two things, it’s easier to brainstorm a solution.