Product Owner is available for questions but the team still struggles to get timely answers. Why?
INSIGHT: Why, "I'm always available for questions" is not the right approach
I’ve been building and helping teams build products for over 20 years.
I’ve been the person asking the questions. The person dodging the questions. The person who didn’t even realize there were questions until everything was on fire.
So believe me when I tell you that “I’m always available for questions” is one of the most dangerous sentences in product development.
Don’t get me wrong.
The Product Owner is a good person trying to do a good job. The development team is a capable group of people trying to do their best jobs. And somehow, with all of that goodwill in the room, the team struggles to get timely answers.
Why?
Last Sunday, I announced a new format for the Winning Strategy newsletter:
Thursday posts: Actionable insights
Sunday posts: Weekly recipes (template + facilitation guidelines + what didn’t work (for us) + metrics)
Since this is a Thursday post, it will provide insight into this particular why.
Why… even when the Product Owner says they’re available for questions, the team struggles to get timely answers.
Let’s get started.
If you are new to Winning Strategy, check out the posts below:
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
Let’s define the problem
Imagine this: I bet you’ve gone through something similar at some point.
Monday morning. Standup. A developer mentions they’re unclear on how a feature is supposed to behave. The Product Owner says, “Hey, just ping me. I’m always around.”
Monday afternoon. That developer pings. He has been heads-down building. He didn’t get a reply from the PO. The developer made an assumption around 1:30 p.m. and kept going.
Friday. The assumption turned out to be incorrect. The feature also has issues. The sprint review doesn’t go as planned. Everyone feels frustrated.
Is this a communication problem? I know it looks like one. It isn't.
Then what is it?
Availability is not a gesture
Saying "I’m always available" is a nice gesture. It is just a nicer way of saying "I don’t know when I am available."
Let me give you an analogy that's going to sound ridiculous, but stick with me.
I want you to think about how a restaurant works.
You don’t walk into the kitchen and tap the chef on the shoulder. There’s a system. You sit, you order, the order enters a queue, and the food arrives. It is predictable and reliable.
Now imagine the chef says, “Just come find me whenever you’re hungry.”
That’s what “I’m always available for questions” really is.
It puts the burden of initiation on the person who needs help, and the burden of context-switching on the person giving it. The question has to compete with meetings, stakeholder escalations, Slack requests, and whatever deep thinking the PO was in the middle of.
So PO responses become inconsistent.
PO does care, but there's no system to deliver the response in a timely manner.
As a result, the team begins to hesitate. They ask late. They ask in three different places. Or they stop asking altogether and just guess.
Good intentions without proper process produce the same result as no intentions at all.
So…
The problem we have just defined is not a communication problem. It is a process problem, and you can see this clearly when you look at the following patterns.
#1: The questions generally have no place to live
A developer asks a question in a Jira comment on Tuesday.
The PO answers that question in a Slack thread on Wednesday.
A different developer asks the same question in standup on Thursday because they never saw this exchange of question and answer.
The PO answers again, slightly differently this time, because the context has changed.
Now there are two answers in two places, neither of which is attached to the story where the work actually lives.
When questions and answers spread across Slack threads, Jira comments, meeting notes, DMs, and hallway conversations, you don’t have a communication system. You have a scavenger hunt.
And the next person who picks up that story in two sprints, or two months, will find… nothing!
#2: Nobody tracks how long questions sit unanswered
Teams are great at tracking stories, bugs, deployments, velocity. But almost no one tracks how long a question sits without a response.
As a result a requirement question that’s been unanswered for 2 days doesn’t appear anywhere… until it surfaces as rework or sprint spillover.
When this happens, you’ll notice people saying, “We didn’t realize it wasn’t clarified.” Because there was literally no process to make that visible.
You can’t manage what you can’t see, and decision turnaround time is one of the biggest invisible bottlenecks in sprint delivery.
#3: Most "quick questions" actually involve hidden decision-making
Let’s say a developer asks: “Should the confirmation email go to the account owner or the billing contact?”
Seems simple.
Except that the PO knows that different stakeholders have different opinions, nobody has aligned yet, and answering this “quick question” actually requires a trade-off conversation with two other people.
What you’ll notice: Answers that arrive are either partial decisions or are delayed by one or two days.
Many questions that appear to be clarifications are actually scope calls, trade-offs, or policy decisions in disguise. And “I’m always available” doesn’t help when the answer requires coordination, not just knowledge.
#4: Decision authority is undefined
Here’s a question you must ask your PO: “Which questions can you answer on your own, and which ones do you need to escalate?”
If the PO doesn't know the boundary…
They’ll treat every question cautiously. They’ll delay and will say, “Let me check.”
If the team doesn’t know the boundary…
They can’t tell the difference between a ten-minute answer and a three-day stakeholder alignment exercise.
So they wait. At the same pace. For everything.
This is fixable in one conversation. Most teams never have that conversation.
#5: The PO waits for certainty before responding
The PO wants to give the right answer. Not a guess. So they wait until they’re sure. Which means the team waits, except the team does not know that it is waiting.
In most cases, a “provisional answer” is infinitely more valuable than a perfect answer that arrives two days late.
But nobody told the PO that a “provisional answer” was an option. Nobody gave them the language for “here’s my best call right now, safe to build on, and here’s what we’d redo if it changes.”
They don’t want to sound negligent.
So they stay silent out of a sense of responsibility. Which is frustrating, because the responsible thing is actually causing the damage.
Here's what works in such situations
Start thinking of the PO’s availability as a service that needs to be designed.
Just like in restaurants.
A well-designed answering service has three properties:
One intake point: A single, agreed-upon place where questions go. If it’s not there, it doesn’t exist.
A response promise: A specific, realistic turnaround time. Not “as soon as I can.” An actual number.
A visible outcome: The decision gets documented in Jira. Not in a Slack thread that disappears by Friday.
When teams adopt this approach, they stop trying to “communicate better” and start reducing blocked time and rework, which is measurable.
It’s a small change, but it produces surprisingly good results.
Coming this Sunday
This Sunday’s Weekly Recipe will include a ready-to-use template called The PO Q and A System, including:
the intake process,
triage scripts,
SLA options,
a lightweight format for documenting decisions inside story tickets
You can copy and adapt it.
You’ll be surprised by how much delivery friction comes from this one blind spot and how quickly it clears up once you give it a little structure.
Have a great week, and I’ll see you on Sunday ✌️
Show your support
Every post on Winning Strategy takes a few days of research and 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.