Cet article est également disponible en français
The Technical Product Owner usually is a former developer or project manager.
In this case, it’s possible that this Technical PO creates his/her stories describing how to produce the functionality.
Indeed, as a former or even active technician, his/her technical expertise is recognized and sometimes asked by the company or his/her manager; like to justify her evolution to this position.
It is then important for the Scrum Master to reveal this situation, before the problem indue the “Scrum doesn’t work for us”.
As I explained in my talk (in French) : Being agile, more than doing agile, I’ve never seen a true Scrum team fail a product (a great team often fail => culture of failure, but here, I think of delivering nothing at all, or the wrong product).
Describing how to do it, the Technical Product Owner removes the possibility for the development team to invent, to create and to assume the product or the feature. It also removes the responsibility from developers. Indeed, if the feature doesn’t work, it was not their choice to do it like this. The team must commit to deliver something they do not necessarily master.
It is then important for the Scrum Master to support this Technical PO to become a functional PO. This goes through the learning of story writing, splitting, etc.
And if this doesn’t work ‒because not anyone can become a Product Owner‒ or if this Technical PO is, in fact, a TPPO (Technical Proxy PO), I recommend to remove this person from the team, to go to find the true PO and to educate him/her regarding the goal of him/her job and why he/she must abandon his/her office et to mix with the team. “DOESN’T THE PRODUCT WORTH IT?” is a perfectly valid question to ask the moment someone contests (see Scrum Life #17 of JP Lambert, with english subtitle available).