O documento discute o conceito de MVP (Minimum Viable Product) e como ele pode ser usado para validar ideias de produto de forma sustentável com o mínimo esforço. O MVP é definido como um produto satisfatório para os clientes que permite coletar aprendizados com feedback, e não deve ser confundido com protótipos ou versões beta. A abordagem de design evolutivo é recomendada para que o produto se desenvolva de acordo com os aprendizados obtidos.

1. Minimum
Viable
Product
como validar suas ideias e evoluir seu
possível produto de uma maneira sustentável

2. Ricardo Plansky
- 27 anos
- Análise e
desenvolvimento de
sistemas
- 10 anos com PHP
- Catho
- Testes, Design, NoSQL,
Agile…
- Futebol, cerveja, samba...

3. MVP
design evolutivo
testes

4. MVP

5. Definição
É um produto sustentável e satisfatório para os
clientes, onde seja possível coletar o máximo de
aprendizado com o mínimo de esforço.

6. PoC
(Proof of Concept)

7. Definição
É um modo prático de validar se uma ideia ou
teoria tem possibilidade de dar certo. Tendem a
serem curtas e até incompletas e não são
vendidas como MVP para o cliente final.

8. MVP vs PoC

11. M P
Viable
Marketeable
Desirable
Delightful
Lovable

12. MVP não é protótipo,
não é pra ser beta,
e sim um experimento direcionado para testar suas
suposições medindo comportamentos e aprendendo
com os resultados.

13. Mínimo Viável (max)
MVP

14. 42%das startups quebram pois não atendem
às necessidades do mercado
https://www.cbinsights.com/blog/startup-failure-reasons-top/

19. Enxergue o que os seus clientes dizem e
não apenas aquilo que você deseja ver.
Não tenha medo de abrir mão de algumas
convicções se for preciso.

21. Concierge
(Operação Assistida)

27. Piecemeal
(Aos poucos)

29. suposições
Pessoas dispostas a
consumirem
músicas por stream
ao invés de
possuí-las
Artistas e
gravadoras
dispostos a
compartilhar suas
músicas legalmente
Stream é rápido,
estável e
tecnicamente viável

30. Protótipo + Familiares

32. Wizard of Oz
(Mágico de Oz)

38. Design
Evolutivo

39. Arquitetura &
Design
Evolutivo

40. YAGNI
(You aren’t gonna need it)

41. database?
linguagem?
framework?
cache?
load balancer?

42. Detalhes técnicos da sua aplicação só farão
sentido quando tiver um alto fluxo de usuário

44. https://github.com/kenjis/php-framework-benchmark

45. https://github.com/kenjis/php-framework-benchmark

46. KISS
(Keep It Simple Stupid)

49. Cresça sua arquitetura quando
sua aplicação necessitar

50. Construa classes
agnósticas ao framework

52. Uma má abstração é
muito pior que código
duplicado

54. Testes

55. Deixe seu produto
confiável
* amanhã o Guitte fala mais

56. Conclusão

57. Obrigado!
@rplansky