2

Right now I'm product owner of a software product with other 3 developers, an architect and a product manager. I'm concerned that the product manager is too focused on having the product on time, up to the point that is affecting the technical quality and even our ability to deliver on time.

For example:

  • when discussing how to implement a new feature we presented several options for discussion. When I mentioned that option Red would give us other features for free she jumped in saying than then we must ignore it, because we must deliver soon. She ignored the fact that Red was too the simplest/faster/safer to implement and test.
  • on the same meeting, I presented the option Blue, the favorite of our architect (he was on vacations). But ten seconds into it she mention too complex, we have to deliver soon and asked for next.
  • I discovered that we inherited a component with "warnings disabled". After panicking I wrote three stories for fixing it, and sent a mail to the team to discuss how to handle it. But on the meeting she started yelling no no no, that it wasn't a feature to deliver and that why I'm writing those things... We didn't discussed the issue, and it goes to the bottom of backlog, although our architect mentioned after that it was important there is nothing we can do about it.

And everything in a single week, and I don't know how to handle it, both personally (I'm having nightmares and sleep issues because of this) and at work. I guess that I could discuss it with my manager but I'm not sure it is a good idea.

Improve this question
2
  • 3
    What's your role compared to the PM? What are the PM's rights/duties as defined by your organisation? The way I am used to this, the PM is a stakeholder, and the PO is the stakeholder manager. is this right?
    – Benjamin
    Commented Jan 19, 2020 at 18:49
  • As we handle it: the PO is the one that writes stories, act as a proxy to the architect, and interacts with other teams (feature requests, etc). The PM manages the schedule, scope, resources and interact to higher level PMs. The scrum master manages what goes into the sprint. The architect designs and review. As the architect usually is shared between several projects usually the PO sometimes takes his place. The PO and the scrum master are developers in the team, the architect and the PM are not expected to develop code. All the team can review, but only some can approve code in.
    – estebarb
    Commented Jan 19, 2020 at 19:07

3 Answers 3

Reset to default
5

Try to have split meetings. One is discussing how you do it, another is what you do it. Try to explain that when you let your creative energies go wild, you may find optimal/faster solutions you wouldn't otherwise find. It's hard for people to get used to it at first, but splitting this allows you exploring and finding better solutions. If you spend 1h per week on this, and save 1 day per week, you have a great payoff! And make sure to always examine this in sum. Because of course, during this creative session you will have stupid ideas that get sorted out. That's fine and expected.

If this doesn't help, a PM and a PO even may not make technical decisions. The PM requests features/qualitiy benchmarks (performance, security focus, reliability, etc...). Sometimes you have to enforce that a PM doesn't get a say for certain decisions, he may only influence the input parameters. How important are development speed, reliabilty, etc...? The team then decides.

Improve this answer
2
  • It may be too late in the development cycle to start this, in this case, but it's good overall advice.
    – computercarguy
    Commented Jan 20, 2020 at 20:20
  • It depends. A lot of "urgent" projects take way langer than expected. Let's say its planned for 3 more months, actually takes 15, and you get the changes implemented in 8 months: Still a lot of time to profit from the changes. Of course, you will face resistance. Option 1 is usualy easier when done tactfully. Option 2 requires the backing of your IT department head (or similar)
    – Benjamin
    Commented Jan 20, 2020 at 20:56
4

Document, document, document.

So when your product fails to be delivered on time, which seems quite likely, then the finger points straight at the product manager.

If your product is in any way security related (and any product is) then compiling a component with warnings disabled is a recipe for disaster. I'd talk to QA that they should demand that this doesn't happen.

And why on earth is your product manager deciding how a feature is implemented? Surely that should be done by the architect and developers?

Improve this answer
4

First make sure you are giving the PM all the information they need in a way they understand it.

So for your first example you said that you presented option Red, and said the benefit was that it gave you other features for free, at which point the PM rejected it. Did you also make it clear that it was the fastest way to deliver the feature? Or did you take their rejection at face value and move on. You should definitely make sure the PM has all the information they need.

In fact, since it is obviously clear that the PM's priority is speed of delivery, you should have presented Red as the fastest way to get the feature, and saved anything about getting a free feature for second mention.

In the second case, what did you present as the reasons for the architect's preference? Saying "it's the architect's favourite" doesn't mean anything. You have to give the reasons they like it. Is it fast to develop? Does it lay the foundation for future work? Is it more secure? Something like "It may seem complex but it's actually a fast way to develop."

Thirdly, developers are responsible for code quality. If Option A will take three weeks to deliver a feature but it will be good quality, and Option B will allow delivery in two weeks but terrible quality and take four weeks to reasonable quality, give them the 4 week estimate for option B. If you are pushed say that it could be done in two weeks, but they must then have a two-week cleanup period.

All this assumes the PM is not managing your technical activities at a day-to-day level, in which case you just need to do what they say.

Improve this answer
4
  • 1
    My concern is more on the line of "bad culture". Usually we split the technical discussion from the planning discussion: it allows us to roam about where we want to get eventually and explore the tradeoffs of our solutions. My concern is that in this case the technical discussion is killed, so we are rushing into the "fastest solution", any one, without even knowing the tradeoffs or possible issues ahead. And changes at later stages are more expensive than changes at a whiteboard.
    – estebarb
    Commented Jan 19, 2020 at 22:04
  • 3
    +1 if they cite delivery speed and pick something with a slower delivery speed, it's probably your communication that needs work.
    – mxyzplk
    Commented Jan 20, 2020 at 1:21
  • A PM can't stop you having a technical discussion but you don't have to have it with them. Discuss the technical aspects and then present the PM with options in terms that make sense to them.
    – DJClayworth
    Commented Jan 20, 2020 at 4:14
  • To piggyback on @mxyzplk-JusticeforMonica, gear your discussion points to their needs, wants, and desires/demands/concerns. If they only care about the timeline, mention how the better option is faster to develop, not that it's someone's favorite thing. If something takes a long time to develop, belay their fears by telling them how much time it'll save later, with "later" explicitly being before the product ships. Also mention how much faster it'll go through QA. Basically, talk about how techniques speed up development, rather than how it's "better".
    – computercarguy
    Commented Jan 20, 2020 at 20:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .