Quando definimos o Product Backlog de um produto, devemos nos certificar de que seus itens mais prioritários são os que irão nos levar a um mínimo produto viável: aquele que permitirá aos usuários começarem a contribuir com o projeto. Por isso, quando refinamos os itens do Product Backlog, concentramos nossos esforços nos itens que estão dentro da versão (release) na qual estamos trabalhando, ou começaremos a trabalhar em breve. A primeira versão é, justamente, a que irá constituir o mínimo produto viável. Uma vez exposto aos usuários esse mínimo produto viável, a própria interação deles com o produto nos auxiliará no refinamento das versões seguintes.
Steve Jobs costumava dizer: “Não devemos dizer sim para todas as coisas. Devemos dizer não para tudo, a não ser para o que é de crucial importância.” De fato, quando o primeiro iPhone foi lançado, ele não tinha sequer as funcionalidades de busca textual ou de copiar e colar. Outro bom exemplo é o site e aplicativo para compras coletivas Groupon, cujo mínimo produto viável foi uma ferramenta de blog (WordPress, a mesma usada nesse livro online) onde um grupo inicial de 20 pessoas combinava compras coletivas.
O gráfico na Figura 9.7 mostra a possível evolução da reação dos usuários quanto às funcionalidades de um produto. Um bom produto faz com que os clientes tenham a impressão de que ele é bacana, mas que ainda faltam algumas coisas. O fato do produto ser bacana motiva os clientes a contribuírem com sugestões para a sua melhoria. Assim, o produto chega a uma nova versão, atendendo àquilo que os clientes pediram. Novas versões fazem com que o produto evolua até atingir seu ápice. A partir daí, se não houver o devido cuidado, o produto começa a ficar infeccionado por excesso de funções, a chamada funcionalite, e os usuários começam a ficar insatisfeitos.
Figura 9.7 – A evolução de um produto e o nível de satisfação de seus usuários
