Plato Elevate Winter Summit has been announced (Dec 7th-8th)


Back to resources

Organizing Stakeholder Requests


15 May, 2020

Maria Petrova

Maria Petrova

Principal Product Manager at Zalando SE

Maria Petrova, Principal Product Manager at Zalando recounts a problem that she has encountered with several different teams regarding request management and stakeholder management.


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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader

Related stories

Improving Team Execution in a Remote Environment

29 November

Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.

Vadim Antonov

Vadim Antonov

Engineering Manager at Facebook

Firing Somebody for the First Time

23 November

William Bajzek, Director of Engineering at Sapphire Digital, remembers the first time that he needed to make the ultimate sacrifice on behalf of the well-being of his team.

Team Reaction
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

What it takes to become a great product manager

19 November

James Engelbert, Head of Product at BT, shares his deep understanding of the traits of a successful product manager and how to get aligned with the organization’s path to success.

Product Team
Personal Growth
James Engelbert

James Engelbert

Head of Product at BT

How to Work With People Who Are Different Than You

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, shares how effectively he collaborated with a newly-joined team as a diverse candidate.

Acquisition / Integration
Cultural Differences
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

One-On-Ones for Engaging Employees: How Good Managers Run Them

11 November

Matt Anger, Senior Staff Engineer at DoorDash, shares some of the benefits of having one-on-one meetings and tips on how both parties should run them.

Goal Setting
Matt Anger

Matt Anger

Senior Staff Engineer at DoorDash

You're a great engineer.
Become a great engineering leader.

Plato ( 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.