Yes, But Later

Written on 2022-07-08 • conversation

Time is a product manager’s best friend. It allows us to say no in a way that helps others to let go of their ideas; it’s the best idea in the world, because my favourite person in the world thought of it: me! I tell others yes, but later in stead of no.

You have a conversation with Alexander, a colleague.

“Do we automate manual tasks because it defocuses developers?” Alexander wonders.
“Yep!” you answer.
“I noticed that we sometimes do x. Can we automate it?” he continues.
You answer, “No,” with clarity.
Out of nowhere Alexander drops the bomb, “Why not?”
A soft voice in your head self-reflects, “Help.

The team performs the task seven times in a year. It defocuses three people. It is also complicated to automate and it comes with a maintenance cost.

I have three of these conversations per week. If I handle them like this, I explain the same thing every week. And I am the asshat not willing to engage with obviously the best idea and best person in the world. If you think a roadmap solves this: think again. People have ideas and fire away in your Slack DM’s. There is a better way to handle this.

“Do we automate manual tasks because it defocuses developers?” Alexander wonders.
“Yep!” you answer.
“I noticed that we sometimes do x. Can we automate it?” he continues.
You answer, “Yes, but later.”
Alexander replies pleased, “Great!”

In my experience, time is an overlooked aspect of decision making. We can use time to say no and help people feel heard.

Inevitably someone will say “Great! When?” This is probably the number one reason why roadmaps (that never pan out) do exist: to satisfy the people who think they have really, incredibly important ideas. That’s a great topic too, but later.

Leave a comment