
Ask HN: How do you cope with non technical product owners? - pythonbase
As software developers &#x2F; producers, how do you deal with non technical product owners who do not understand the intricacies of how the software works, troubleshooting etc?<p>A recent example is where a product owner always blame latest deployment whenever something went wrong in the system - even if the issue was caused by a release several months back.<p>Also, is it a good idea to have the PO on Skype, reporting bugs and glitches on the go?<p>How do you deal with such stress?
======
davismwfl
Having people blame the latest deployment is only natural. And the fact an
issue is found during testing on the latest deployment but your research finds
the problem was introduced months ago doesn't matter. If the user just found
it, their perspective is it was just introduced. You cannot fault people for
having that opinion with no other facts. And if the user found the problem
prior and reported it and you didn't address it, then many people will report
it again and again wanting it fixed and this usually turns into them
distrusting the engineers so they want to sit on calls to make sure you hear
them.

As for having real time Skype type reporting of issues, this can go both ways
but usually happens for a reason. I personally prefer they produce a document
with their first cut of issues, and then we look at them and get on a quick
call to go over it and then if we see something isn't clear we can walk
through it right there. Usually when they do this as a rule, there is either a
past history where they felt engineering didn't listen or they feel they have
to be directly involved or things aren't getting done.

Non-technical Product owners is the norm in most enterprises and as companies
grow you will almost always have non-technical product management. Some are
better than others, but part of the job of engineers is to manage those
relationships and expectations. That is partially why senior engineers or team
leads are paid more and have advanced further, they know how to manage the
business side of the tech job better. Not that they like it, but they get it
and do it.

If you want the person to stop doing real-time reporting, give them a way to
report issues clearly and in a way that makes them feel in control and that
you are listening. For example, give them a simple (not complex) template to
fill out for the defects, and then setup a meeting with them in two days (or
some short timeframe) to go through everything they reported and give them an
update. That meeting may only be 20 minutes for you to walk through each
defect with them verbally and see if there are any questions or follow ups and
for you to categorize the problem for them. But doing this makes the product
owner feel that you are listening and that you understand which is most of the
reason I have found they like to try and report on a call in real-time etc.
You categorizing the problem is part of what they usually are wanting, e.g.
low impact to high impact, it doesn't mean giving timeframes until you have
time to investigate more, but telling them this is a complex problem versus a
simple problem helps them feel good about what is happening.

99% of tech to business is learning to communicate in a language the other
side understands, and I don't mean treating people like they are stupid, I
mean putting it in terms that helps them understand how it impacts them. For
tech to business, it is in terms of time, money & complexity. Complexity being
the biggest because if they ask you for a fix but it only affects 5% of
clients but it will dominate the schedule for the next month, they'll punt on
it 9 out of 10 times to get everything else done first.

Managing the stress is learning how to communicate and understand what the
product owner wants and giving it to them before they feel compelled to come
to you.

