Por onde atacar o problema: no design, na implementação ou na entrega do serviço?

Otimizar uma funcionalidade ou resolver outro problema? E seja qual for a escolha, por onde primordialmente atacar agora? Design, implementação ou entrega do serviço? Como seguir este racional é útil, na prática, ainda que no mundo digital esta divisão não seja tão bem definida.

Por onde atacar o problema: no design, na implementação ou na entrega do serviço?
Photo by ALAN DE LA CRUZ / Unsplash

Essa edição da PM Letter é oferecida pela nossa parceira Tera.

O Tera Festival acaba de começar e você pode ter acesso a cursos gratuitos na área de produto, dados, programação e design. Essa é a oportunidade para você se desenvolver, mudar de carreira e aprender com os melhores experts do mercado!

Nos dias 13, 14 e 15 de março você já poderá aprender sobre Product Management com o expert Murylo Schulttais (Group Product Manager Sênior no iFood).

Além do curso do Murylo, a Tera criou um line-up completo com mais três cursos gratuitos.

Garanta sua vaga!


A Talita Oliveira escreveu aqui no Product Oversee um artigo interessante sobre como balancear a otimização de uma funcionalidade existente com começar a atacar um novo problema. Ela procurou dar dicas bastante práticas, e eu particularmente gostei da conexão com riscos: super otimize problemas críticos, e entenda o que pode tolerar quando não for o caso.

Isto me levou a pensar num outro aspecto relacionado, que é por onde atacar o problema (usando as lentes do framework fit-for-purpose): por qual dimensão das que compõem a experiência final do usuário:

  • Design: "o quê" se vai entregar, com qual critério de qualidade (o que é crítico e o que se pode tolerar), e quais requisitos funcionais se vai atender.
  • Implementação: "como" se vai entregar, quais as opções técnicas que serão adotadas, quais são os tradeoffs, e tudo o relacionado a materialização daquilo que se desenhou.
  • Entrega do serviço: "qual é a experiência de consumo do usuário", incluindo questões como a confiabilidade no serviço, e tantos os outros possíveis requisitos não-funcionais que devem ser atendidos.

A conexão, ou a implicação, a que estou aludindo é que talvez exista uma tendência ao viés ao novo, em se buscar ajustes na implementação ou mesmo até que se melhore o design. É uma viés natural visto onde tipicamente está o dia-a-dia da pessoa de produto, muito mais próximo destas etapas de começo do fluxo de trabalho, do design até a implementação.

Um possível problema está em que, via de regra, quanto mais subimos nesta espécie de stack que compõe a experiência final do usuário, maior tende a ser o custo de modificação. Assim que procurar entender quando realmente precisa-se voltar até o nível de design, ou quando a implementação precisa ser revista, melhorada, ou quando somente ajustes no nível de entrega do serviço já é suficiente, pode fazer uma grande diferença na efetividade de um time de produto.