Does anyone have any experience modifying a culture where internal feedback is frequently delivered in a harsh or unpleasant manner? We perform weekly playbacks of features that are in development, for instance. People are always ready to point out issues that are incorrect, broken, or objectionable during those playbacks. This typically leaves the developer feeling disheartened about the task they may have laboriously completed over the weekend. What actions as a Product Manager can I take to change this culture?
10 Likes
Many companies have this issue, including the one I work at. This is how I handle the situation and believe me it has worked for me.
-
Define your expectations for the type and quantity of feedback you desire. Ex: Jerry will next discuss the status of Feature X. As this is still a work in progress, it would be helpful to Jerry and me if you could provide comments on the copy so that our customers can fully understand this experience. I’ll address any questions you may have about the strategy thereafter.
-
Take those who are not meeting your expectations aside and coach them one-on-one.
-
Transform feedback into written form so you can process, absorb, and communicate feedback more effectively.
-
Refrain from inviting negative people to the feedback meetings. Meetings occasionally need to be changed up. Dev leadership would rip designs to pieces during our poisonous design review sessions. That cost us some good talent. It is unwise to do so.
-
Get input early and frequently, in general. First, confirm your overall UX strategy and technical plan. Then come the visual, polish, and copy.
-
Have the courage to speak up in the meeting on behalf of your team. There are occasions when the group persuades itself into an agreement that will require a total rethink of your feature.
A. By being aware of the limitations and goals in advance, you should try to move ahead of it as much as possible. Sometimes fresh information surfaces that you were unaware of, and if that occurs, it is your fault.
B. You need to intervene and either refocus the group on the strategy or pull it offline if they are reopening decisions that had already been made.
10 Likes
@Luisneilson, I love the idea of Setting standards for giving constructive criticism as well as offering one-on-one coaching to say, “Hey, your input is excellent, but it’s just the way it’s communicated.”
9 Likes
Because of this, I immediately left a company. They spoke of “Radical Candor,” but all of the feedback was just people trashing off one another. While building trust is mentioned in Radical Candor, it never actually happened. It came from one of the founders and was also top-down. I made an effort to improve it by posing the question, “What would this need to look like for you to not have this criticism?” but no one ever offered a solution. I quit the company in about two months since it was so toxic and run by that one founder. I don’t even list it on my CV.
9 Likes
@MartyRoss, my biggest worry is that this toxic culture will force us to lose talented folks. Radical candor is what I want, but it must be matched with efforts to boost people’s self-esteem and positive feedback.
8 Likes
I try to adopt an attitude of “us against the problem.” Was there a communication breakdown if something is broken or wrong? Was there opportunity for assumptions in the requirements? Work with the developers to determine where and why things went wrong and how to communicate more effectively in the future. I find that the situation is nearly never one-sided.
Why not, if something isn’t built to their specifications? Does the functionality still function but isn’t the most aesthetically pleasing or user-friendly? Was the developer given sample screenshots to demonstrate what to expect?
Have whoever is providing the “feedback” collaborate with the developers to identify the root cause of the problem.
It’s simple to make a long list of problems. That is not feedback.
8 Likes
Do you attempt redirecting the negativity towards the process?
I’ve found that to be effective in the past, but I’m looking for new strategies.
7 Likes
Feedback is subjective.
Bring in data to demonstrate the successes, good things, etc. Make a celebration out of it and make it a recurring ritual.
Additionally, you can get user feedback. I used to peruse the App Store, Google Play, and Reddit reviews a few times per week and share the gems with the team.
6 Likes
Can you clarify further? Who or what stakeholders are giving their feedback? What kind of comments are made? Functional shortcomings? Design flaw? The criticisms: Are they based on facts or are mere opinions? What steps do you take to prepare? Do other PMs experience this more often, or is it just your team? In the first place, why are stakeholders included in a review of work in progress?
5 Likes
It seems to occur during every meeting we have. At architectural reviews (where our developers and architects participated), design reviews, sprint demos, and epic/feature demonstrations, I’ve observed it. There is a culture of mocking others’ work. The majority of it appears to stem from those who have been there the longest. I’m not sure if it’s just a normal aspect of their culture.
4 Likes
Also take into account who will be attending these sessions. We hold various sessions with various stakeholders, and each group has distinct expectations regarding the progress of the project.
Our scrum level demos with architects are problem-focused and emphasize how we’re approaching or resolving issues. The idea is to correlate with architecture where our approach isn’t in any way problematic, even though the feature work in these is frequently still rather rudimentary.
Additionally, we have release demos, which draw significantly larger audiences but are intended to showcase a product that is prepared for release. If this is broken, you will be called out. If someone didn’t like the design, they need to have voiced their displeasure during an earlier architectural assessment or the product design review that was held to obtain approval for the Ui / ux.
Better socializing of the work before these sessions is another thing that can be done. There will be a lot more unfavorable responses if everyone approaches what was being constructed from scratch. Identify the key actors and get to know them beforehand.
4 Likes
@AnushkaGarg, whether it’s a sprint demo, release demo, or design meeting, I’ve seen that toxic feedback tends to permeate every meeting. Most of it comes from development and services staff members who have been there for a LONG TIME (like 10+ years).
4 Likes
Then, I advise introducing it to them beforehand. Don’t let them see the feature for the first time at these important meetings. It will help greatly bring down any surprises.
4 Likes
With whom is this? We have a rule for anyone who is not a member of the development team, QA, product owner, or management if it is a typical sprint demo. No talking, no interaction.
For the other people, I hold separate sessions.
The loudest critics, in my experience, were either those who had been around the longest or lacked vision. There are many negative comments or misconceptions about how iteration works.
However, every team member should be able to understand how to sort through that to extract value. Regardless of how unpleasant it can be to hear from those who can hardly perform their basic duties what you ought to have done in the past.
3 Likes
@NaomiNwosu, that is what I see. The people who have been working with the product for a long time (10+ years) are primarily the services personnel that implement and manage the product for our clients. Their advice is quite valuable, but it’s also brutal and frequently kills off innovative, outside ideas.
3 Likes
Regarding that, I agree. My current project involves rebuilding our main legacy product, which is around 15 years old. When I proposed the idea two years ago to the service teams, they informed me right away that it would never be possible to entirely alter how our platform’s identity management operates in order to create new opportunities. The most anticipated enhancement to our new platform by both customers and business development partners has been built out for around six months now.
3 Likes
What benefit do you derive from a demo that prohibits feedback or inquiries? The stakeholders will view the demo. Set the scene for what you plan to display, including any ongoing projects, completed items, etc., and invite feedback and inquiries.
3 Likes
@JesusRojas, I am their team representative, so they can express any concerns or feedback to me. Being interrupted every two minutes by eight stakeholders and nine developers is not productive, in my experience. I schedule a separate meeting with a stakeholder if they truly want to get down to the nitty-gritty, but this rarely occurs.
Everybody has their own set of priorities, way of thinking, and things they must complete right now, but most of the time they just want to know that things are happening and when they may get it. Additionally, I maintain a close relationship with my stakeholders, so they are never startled by what is displayed.
This aids the group in avoiding HIPPOs.
2 Likes
Define some instructions for attendees.
-
Put issues first, not people.
-
Providing constructive, practical feedback
-
Encourage participation early in the development phase; get feedback when conducting discovery. So it won’t appear to be criticism.
Your development staff, on the other hand, needs to develop a thicker skin. It’s important to deliver constructive criticism, which shouldn’t be taken personally (as long as it’s done so civilly). Work with EM to mentor Devs on how to use harsh people’s input to their advantage while avoiding getting on their last nerve. How to answer in a way that takes into account the expressed concerns, defuse the situation without giving in to every demand, and manage presentations and the audience.
Then, provide those other groups individual input on their behavior (without the developer’s knowledge). It can be informal conversations about how to modify the meeting/feedback culture to achieve the maximum value and a high level of mutual respect/morale for well-intentioned but not so EQ behavior. You can give criticism regarding inappropriate or unacceptable behavior straight to their management. may possibly collaborate with EM on that as well.
1 Like
@DhirajMehta, that was super cool. Will definitely try to follow it.
Thank you all for your replies and insights.