Feedback is a skill, not a personality trait
Petra Wille's talk at WaysConf 2026 was about what she has learned coaching product leaders across Europe. None of it is new on paper. The way she packaged it is why it stuck, and why I'm still using a feedback model from my first job.
One line from WaysConf has stayed with me longer than any slide. Petra Wille said that you have to share your strategy document something like 21 times before people actually get it.
Twenty-one. Most product leaders I work with share it once, at the kickoff, and then wonder why the teams drift by the second month.
Petra is a product leadership coach and the author of STRONG Product People, and her talk at WaysConf in Kraków was about what she has learned coaching some of the best product leaders across Europe. I almost didn't write about it, because it isn't new on paper. That turned out to be the point.
Say the strategy until you are sick of it
Here is why the 21 times matters. A strategy you announce once is a document. A strategy you repeat in every planning session, every review and every hard prioritization call becomes the thing people use to decide on their own.
That is the whole reason to have one. If teams cannot quote the strategy back to you, they will fill the gap with whatever the loudest stakeholder asked for this week. I have written about what happens next in if everything is a priority, nothing is.
The practical version: tie every big decision back to the strategy out loud. "We are not doing this, because this quarter we are solving X." By the time you are bored of saying it, people are starting to hear it.
Feedback is a skill, not a personality trait
The idea from the talk I am still chewing on is this one. Feedback is not something some people are just good at. It is a skill you can learn, and practice, like interviewing or writing a test card.
The structure she uses is Situation, Behavior, Impact, followed by a suggestion. Where and when it happened. What the person actually did. What effect it had. Then what you would like to see instead.
A product example, so it is concrete. "In Thursday's roadmap review (situation), you presented the new feature without the interview findings (behavior). Sales left thinking the decision was already made, and I couldn't explain why we picked it (impact). Next time, could you open with what we learned from the five customers?"
Compare that with the version most of us default to: "You need to involve stakeholders more." It is true, and nobody can act on it.
The model I learned at my first job
This part hit home for me. Years ago, at my first job ever, when I was still a student, my then boss taught me a feedback model called OILS: Observe, Impact, Listen, Suggest.
I still use it today, at work and in my personal life.
It is close to Petra's structure, with one step I have come to value most: Listen. After you say what you observed and how it landed, you stop and ask for their side before suggesting anything. Half the time the suggestion you had ready turns out to be wrong, because there was context you didn't have.
That step is also what makes feedback work inside a product trio. A PM, a designer and an engineer giving each other feedback are peers. Nobody can just tell the others what to do, so the conversation has to be a conversation.
Stay on your side of the net
Her second point was a tennis image I liked a lot. Stay on your side of the net. Only say what you observed and how it landed on you. Don't guess at the other person's intent.
"You don't care about users" is a guess about someone's intent, and it starts an argument about their character. "The brief had no user evidence in it, and I couldn't defend it when the sales team pushed back" is your side of the net. It is harder to argue with, because it is simply true.
Product work is full of opportunities to cross the net. Engineers "don't care about the business". Leadership "doesn't trust the team". Stakeholders "just want their feature". Every one of those is a guess, and every one of them makes the next conversation harder.
Be a shaper, not a victim
The third point was the one aimed at the people in the room rather than at their teams. Be a shaper, not a victim. If something is off, don't just complain about it. Challenge it, and bring a suggestion.
I see the victim version a lot with product managers. The roadmap came from above, the deadline was set without them, the stakeholders keep adding scope. All of it may be true. None of it changes until someone walks in with an alternative and the evidence behind it.
That is the real authority a PM has, since it is not the formal kind. I made the same argument from another angle in product managers, you are not the mini-CEO of product: your leverage is enabling good decisions, not owning them.
Where to go from here
Petra pointed to two resources worth your time.
The first is Connect by David Bradford and Carole Robin. It grew out of the Interpersonal Dynamics course they taught at Stanford's business school, better known to students as "Touchy-Feely".
The second is the set of product leadership tools on her own site, including the Product Leadership Wheel, which is a useful way to see where your own gaps are before someone else points them out.
None of this is groundbreaking on paper. Situation, behavior, impact has been around for a long time. But the way she packaged it made it stick, way more than most of the frameworks I hear at conferences. A framework you remember on a bad Tuesday beats a better one you forgot.
Feedback, strategy communication and leading without authority are most of what new product leaders end up learning on the job. If you would rather not learn all of it the hard way, that is what Product Coaching & Advisory is for.
