Product Management: Where “Yes and” becomes “Yes, but…”

“Yes! Brilliant idea, Joe! But show me the data to support your claim…”

“Yes, I think that feature concept is hot, hot, hot! But, I need to be sure it’s right for our specific users.”

“Yes, I can see you’ve put a significant amount of time and thought into this design, but until I can get it in front of some test users, I need us to hold on implementation.”

Do you see a pattern here? That subtle hint of resistance is basically the soundtrack to the life of a product manager. May I introduce to you the infuriating “yes, but” statement; the evil twin to the more popular “yes, and” statement, which is commonly found in brainstorming workshops and based on improv tactics in which no given answer or idea is wrong. Now, for the record, I love the improv tactics. In fact, I love nothing more than unpacking the ideas that are stewing in the back of your brains and collecting them for my backlogs. I believe there is a justifiable time and place within a product’s life cycle for that great barrage of concepts.

Still, as a product manager, I’m always ready to chime in with a lyrical “yes, but…”

I see the disappointment wash over the wide-eyed faces of my colleagues when I challenge a budding concept for a new product feature. I hear the vibrancy dissipate in the voices of the designer or architect who feels they need to head back to the drawing board. And I sense the hesitation in our clients or partners when I ask for more time, data, or research, but all they hear is “dollar, dollar, dollar.” No, breaking hearts is not the most exciting aspect of my job, but aligning a team to a single worthwhile cause and focus? That’s where I win them all back.

In my ongoing attempts to explain to my friends and family what I do for a living, I find that sometimes people refer to product managers as the “champion of the product.” Think of it this way — someone who “champions” for a cause or people is considered to be an advocate, a voice for the unheard, a person who fights on behalf of something or someone else. In that way, a Product Manager’s role is to speak for a specific user base for a product, and advocate for features, enhancements, or even a vision that will help to satisfy those users’ needs.

The ultimate goal: A more valuable product

For product managers, the intent is never to be the bad guy, though it may commonly appear as such. Our sole intent is to look out for the best interests of the product first and foremost, and to remove any and all personal interests from the conversation. We challenge teams for the burden of proof that a concept might provide real value to a product and its users — the most important factors in determining the success of a product — even if it means navigating through some confrontations along the way.

Your product manager takes no great pleasure in saying no. Rather, a product manager’s greatest satisfaction is in proving value, which comes from the testing, insights, and evidence that validates the decisions we’ve made along the journey. Hard numbers outweigh personal opinion every time. Sometimes we get even more of a thrill from the data that shows where a concept didn’t work and where we need to pivot (hopefully in early stages of product testing!). Gathering these insights helps to better inform the product roadmap to ensure we are always building towards a better, more valuable product, which in turn, provides additional updates that require more rounds of testing, which better informs the next steps, etc. It’s all cyclical.

‘Yes, but’ doesn’t always mean ‘no’

In making the tough decisions and selecting a small number of priorities for the team to dive into, the product manager is protecting the overall focus of the team, and the likelihood for success for the product. It is better, in this case, to concentrate on perfecting a product that expertly does 1–2 things that data suggests your users truly need or want, than to manage a product that does 7–10 things “just okay.” In that way, your product manager should always be communicating a solid product vision that the team can get behind and be inspired by.

When your product manager pushes back on your concept or idea, they aren’t simply dismissing your contributions. “Yes, but” does not always mean “No.” More often it means we need more information to support a claim, or we need to take some time to investigate a need, or it might mean we have to deprioritize a concept in favor of another high priority item. “Yes, but” translates much more realistically to a simple “Why?”

Yes. All of the above. But, sometimes, of course, it may also just mean “no.”

Originally published at bynd.com.