Respondendo diretamente, é o principal responsável pelo produto. O Product Owner designado para o Scrum, caso não seja o cliente final, deve ter plena consciência de sua representatividade e responsabilidade, ser o mestre do domínio do produto em desenvolvimento. Em todo e qualquer projeto, criamos algo visando a um público cliente. Raríssimas vezes investimos na criação de algo que atenderá, apenas, a nós mesmos. Assim, é normal na construção de um Product Backlog que ele seja alimentado a partir de pesquisas diretas com os potenciais consumidores ou beneficiários de nosso projeto ou produto. O Product Owner deve ser capaz, a cada revisão de um Sprint, de incorporar a alma coletiva do cliente final.
O Product Owner é também quem paga diretamente o desenvolvimento do produto, ou é responsável pelo orçamento de um grupo de investidores no projeto. Ele tem a palavra final e é quem dá o aceite final às entregas nas revisões de Sprint. Aqui não tem balela, nem choro nem vela. O Product Owner pode ter errado na definição de uma história que entrou no Sprint Backlog e ele deve ser plenamente alertado de seu erro, mas, se ele não aceitar a história, ela não está completa: será redefinida e encaixada em um próximo Sprint. Isso não é tão horrível quanto parece. Especialmente, no início de um projeto, todo mundo chuta muito. Todos têm uma ideia absolutamente inexata do que desejam. É por isso que os Sprints iniciais são de muito ajuste, negociação. O Product Owner deve entender que errou na sua definição, que houve um investimento na construção daquilo que foi construído errado, mas ele não deve se contentar em passar ao cliente a sua incompetência. A equipe Scrum, por sua vez, mesmo apontando a definição inicial equivocada, não deve condenar o Product Owner, mas auxiliá-lo na construção do que será o perfeito resultado final. Se o Scrum foi bem vendido ao grande patrocinador, isso não é tão difícil quanto parece. Independentemente de qualquer coisa, depois do segundo Sprint, essa negociação vai ficando bem fácil.
O espaço para o erro é uma das principais razões de mantermos curta a duração do Sprint. Devemos falhar rapidamente, evitando nos prolongarmos nos erros. O custo de um erro que perdura por uma semana é infinitamente menor do que aquele que é levado ao longo de todo o projeto.
