Organizing Stakeholder Requests
15 May, 2020
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.
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.
- 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.
Marc LeBrun, VP Engineering at Flow Kana, describes how he empowered teams to make decisions and uplevel their process by adopting a low-tech approach to agile practices.
VP Engineering at Flow Kana
Kowsheek Mahmood, Principal and CTO at ArchetypeTech, explains how he adapted an ineffective team by determining and implementing team-evaluation processes to better align the team on product delivery.
Principal & CTO at ArchetypeTech
Viacheslav Bessonov, Chief Technology Officer at Algalon Capital, outlines how he improved communication internally - with his fully distributed team, while also improving communication with the customer - located across various time zones.
Chief Technology Officer at Algalon Capital
Maria Petrova, Principal Product Manager at Zalando describes how she built an organizational design from product and stack in a way that tech and product effectively function in a collaborative environment.
Principal Product Manager at Zalando
Maria Petrova, Principal Product Manager at Zalando recounts a problem that she has encountered with several different teams regarding request management and stakeholder management.
Principal Product Manager at Zalando
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.