Fit framework - Estágio 1: Problem/Solution fit
Value/Solution Fit

Como definir e validar o conjunto mínimo de funcionalidades para entregar a Proposta Única de Valor e resolver os problemas do cliente sem desperdiçar recursos de engenharia?

Localização desta seção no contexto do Fit framework

A próxima figura mostra o posicionamento do estágio 1 no contexto do Fit framework para desenvolvimento de startups e suas fases.


Figura 1459: fases do estágio 1: Problem/Solution Fit do Fit Framework 

Esta seção descreve o preenchimento dos campos 1 (problema) e 2 (segmento de clientes) do Lean Canvas no contexto do estágio 1: Problem/Solution Fit do Fit Framework

Figura 1459.3: representação dos campos do Lean Canvas preenchidos na fase de Value/Solution Fit ​ no estágio 1: Problem/Solution Fit do Fit Framework

Introdução 

O Lean Canvas é uma adaptação do conhecido Business Model Canvas (Osterwalder & Pigneur, 2010) com o objetivo de modelar a lógica do negócio de startups em estágios iniciais.

Esse método foi descrito em uma seção principal da flexM4i sobre o Lean Canvas. Esta seção foca no detalhamento das atividades e aplicação de métodos auxiliares usados para preenchimento do campo “Solução”, dentro do contexto do Lean Startup.

O objetivo é mostrar como aplicar o Lean Canvas no desenvolvimento de uma inovação, seja ela produto ou serviço.

Conheça a seção principal sobre Lean Canvas antes de ler a seção atual, onde discutimos:
– quando utilizar o Lean Canvas
– por que utilizar o Lean Canvas
– quais as principais características do Lean Canvas
– características da fase inicial de uma startup e por onde ela começa a ser desenvolvida
– uma descrição sucinta da sequência de preenchimento dos campos do template
– premissas, dicas e cuidados para aplicação do Lean Canvas
– uma discussão sobre outras sequências possíveis

 

Nesta seção apresentamos a visão geral do template do Lean Canvas e a descrição resumida de preenchimento do campo “Solução”, que foi publicada na seção principal.

Em seguida, mostramos as atividades e os métodos e ferramentas auxiliares.

Visão geral do template do Lean Canvas

A próxima figura ilustra o template do Lean Canvas. Atente para numeração colocada, que foi a sequência descrita na seção principal. Essa é uma possibilidade de sequência de preenchimento dos componentes, mas há outras possibilidades.

Figura 1382b: template do Lean Canvas

As cores do templates indicam se os campos se relacionam com:

  • criação de valor
  • entrega de valor
  • mensuração do valor
  • defesa do valor
  • captura do valor
Conheça uma descrição detalhada na seção específica sobre o Lean Canvas.

Proposta Única de Valor (PUV)

O Lean Canvas adota uma abordagem enxuta para formalizar modelos de negócio para startups. Seu objetivo primordial neste momento não é o detalhamento completo do negócio, mas sim a mitigação de riscos e incertezas nos pilares essenciais que definirão uma proposta sustentável. Nesse esquema, o Campo 3, a Proposta Única de Valor, é central, pois estabelece a ligação crucial entre os problemas identificados no cliente e a solução que a startup se propõe a entregar.

Ela se estabelece como a promessa de valor inequivocamente superior do seu produto ou serviço, explicando de forma clara e concisa o que o torna distinto e preferível em relação às opções disponíveis. Fundamentalmente, a PUV é a resposta direta e convincente à indagação primordial do cliente: “Por que devo optar pelo seu?”

Este momento, no Fit Framework, é o encaixe entre o problema e a proposta de valor. Ele marca a passagem da compreensão de uma dor significativa para a formulação de uma promessa de valor que o cliente perceba como desejável, clara e superior às soluções que ele usa atualmente.

Nesta parte do Problem/Solution Fit, concentra-se no encaixe entre o problema e a proposta de valor. Ele representa a transição da identificação de uma dor relevante para a criação de uma promessa de valor que o cliente reconheça como desejável, facilmente compreensível e superior às alternativas existentes.

Portanto, preencher este campo não é um simples exercício de redação. Representa, na verdade, uma hipótese estratégica que deve ser cuidadosamente elaborada e, posteriormente, validada por meio de experimentação.

Solução no contexto do Lean Canvas

O campo 4 do Lean Canvas,  Solução, reúne o conjunto mínimo de funcionalidades, características ou capacidades (features) que a startup propõe para entregar a Proposta Única de Valor (PUV) e resolver os problemas validados no Customer/Problem fit (Campos 1 e 2). 

Diferente dos demais campos, a Solução não nasce de observação direta do cliente, mas de design e tecnologia aplicados às evidências já coletadas sobre o problema e sobre a proposta de valor.

É fundamental distinguir os três elementos que formam a espinha dorsal do modelo de negócio nesta fase inicial:

  • Problema (Campo 1) é a dor real, recorrente e relevante vivida por um segmento de clientes; justifica a existência da startup e origina-se de observação e entrevistas. 
  • Proposta Única de Valor (Campo 3) é a mensagem curta e memorável que promete como a vida do cliente vai melhorar, é o “porquê” ele deveria confiar na solução; é a ponte entre o problema e a solução. 
  • Solução (Campo 4) é a forma concreta – funcionalidades, tecnologia, design – de materializar essa promessa; é o “como” a startup entrega o valor. Em uma frase: o cliente tem um problema; a startup promete resolvê-lo (PUV); a startup entrega essa promessa por meio de um produto ou serviço funcional (Solução).

Como tudo o que a equipe tem, nesta fase, são ideias ainda não testadas, a recomendação do Lean Startup é não definir a solução por completo: basta esboçar as principais features associadas a cada problema, vinculando uma solução definitiva ao problema o mais tarde possível, adiando compromissos de engenharia até existir evidência real de que vale a pena construir.

Solução Mínima

Construir a solução completa é demorado e arriscado: pode-se desperdiçar recursos criando a solução errada ou incluindo funcionalidades desnecessárias. Por isso, no Campo 4  trabalha-se com o conceito de solução mínima – apenas o suficiente da solução (ou um proxy dela, como uma captura de tela ou um vídeo) que possa ser colocado na frente de clientes reais com o único objetivo de medir a reação deles. Para cumprir seu papel, a solução mínima precisa ser realizável (será validada por clientes reais), parecer real (quanto mais real, mais precisamente pode ser testada gerando feedbacks de melhor qualidade), propiciar iteração rápida e minimizar desperdício, e usar dados reais do Problema e da PUV já levantados.

A maioria dos clientes sabe articular bem os problemas que vivencia, mas dificilmente consegue visualizar soluções ainda abstratas. Por isso, o objetivo desta etapa é usar uma demonstração que ajude o cliente a visualizar a solução e validar se ela de fato resolverá seu problema.

Em termos do Fit Framework, podemos tratar MVS, MVP, MMP e MMR como uma família de soluções mínimas progressivas.

  • MVS: minimum viable solution
  • MVP: minimum viable product
  • MMP: minimum marketable product
  • MMR: minimum marketable release

É importante considerar que cada uma representa uma dimensão diferente de maturidade e que a MVS não seja confundida com o Campo Solução do Lean Canvas.

Lembrando que a startup não desenvolve uma única solução mínima. Ela desenvolve sucessivas configurações mínimas, cada uma destinada a reduzir um conjunto diferente de incertezas.

Demonstrações, MVP, POC e Produto Mínimo Viável

Esses termos costumam ser usados de forma intercambiável, mas descrevem coisas diferentes, confundi-los leva a decisões equivocadas sobre o que construir. Demonstração é um evento voltado para fora, destinado a uma audiência (clientes, investidores, parceiros) para gerar interesse ou fechar negócio; constrói-se para descartar, priorizando velocidade sobre qualidade. Protótipo é voltado para dentro: existe para a própria equipe responder “podemos construir isso?” ou “devemos construir X ou Y?”, provando viabilidade técnica de forma também descartável.

Prova de Conceito (POC) é um exercício interno para verificar se uma ideia é tecnicamente viável antes de desenhar um produto ao redor dela, envolvendo o público interno, com vida curta e sem geração de receita. Produto Mínimo Viável (MVP) é a versão mais “enxuta” de um produto apresentada a usuários reais (early adopters), contendo apenas as features essenciais, para coletar o máximo de aprendizado validado com o mínimo de esforço; ao contrário da POC, é evolutivo, serve de fundação real do produto e pode gerar receita. Em síntese: a POC responde “isso funciona tecnicamente?” para um público interno; o MVP responde “os clientes querem e pagam por isso?” para um público externo. Uma demonstração (o evento) pode perfeitamente ser o palco para mostrar um MVP (o produto), mas não se deve confundir formato com conteúdo. 

O MVP ainda se classifica em dois tipos. O tipo 1 (baixa fidelidade), do estágio Problem/Solution Fit, é simples e pouco fiel à versão final, e valida interesse e demanda a partir da percepção da equipe sobre problema e PUV, landing page, vídeo explicativo, teste de fumaça e teste A/B são exemplos. O tipo 2 (alta fidelidade), do estágio Solution/Product Fit, é mais próximo da versão final e valida features associadas a necessidades já priorizadas com clientes, inclusive disposição a pagar, protótipo funcional, Mágico de Oz, concierge e MVP low-code/no-code são exemplos.

Figura 1497: Tipos de MVP

Leia mais na flexM4i sobre os tipos de MVP 

A utilização de MVP no Fit Framework

O Fit Framework organiza o desenvolvimento da startup em quatro estágios sequenciais Problem/Solution Fit, Solution/Product Fit, Product/Market Fit e Scale , sendo nos dois primeiros estágios que o MVP é utilizado.

 Figura 1498: Fit Framework com os quatro estágios de uma Startup e os artefatos típicos

No estágio Problem/Solution Fit, com o problema e a proposta de valor testados utiliza-se o MVP tipo 1 (baixa fidelidade).O objetivo é validar o interesse do cliente pela ideia de solução, com o mínimo de esforço de engenharia, por isso os artefatos típicos são landing pages, vídeos explicativos e testes de fumaça, e não um produto funcional.

Já no estágio Solution/Product Fit, quando a equipe já tem evidências de que a solução faz sentido para o cliente, passa-se a usar o MVP tipo 2 (alta fidelidade), mais próximo da versão final, com o objetivo de validar features associadas a um conjunto mínimo de necessidades já priorizadas, incluindo a disposição do cliente a pagar. Os estágios seguintes, Product/Market Fit e Scale, avançam para protótipos, MMP (Minimum Marketable Product), MMR (Minimum Marketable Release) e novas demonstrações, já com foco em otimização e crescimento.

Além da fidelidade, a diferença entre MVP tipo 1 e MVP tipo 2 está na origem e no grau de validação das features usadas em cada tipo. 

No MVP tipo 1, as features são propostas a partir da percepção da própria equipe sobre o problema e a dor do cliente, combinada com a proposta de valor que se pretende entregar, ou seja, são hipóteses de funcionalidades ainda não confirmadas por ninguém de fora da equipe. O objetivo é usar essas features apenas para testar se existe interesse e demanda pela ideia de solução, sem comprometer esforço de desenvolvimento em algo que talvez não faça sentido.

No MVP tipo 2, as features não são mais suposições da equipe: elas são associadas a um conjunto mínimo de necessidades já priorizadas e validadas junto aos clientes na etapa anterior. Ou seja, cada funcionalidade incluída no MVP tipo 2 corresponde a algo que o cliente já confirmou que precisa. O objetivo muda de “existe interesse?” para “o cliente realmente usaria — e pagaria por — isso?”.

Em resumo: no tipo 1 as features nascem de dentro da equipe e testam a demanda; no tipo 2 as features nascem de fora, do cliente já ouvido, e testam o uso real e a disposição a pagar.

Aplicando o Ciclo BML ao Campo 4

Lógica do ciclo

Assim como nos campos anteriores, a Solução, registrada no Campo 4, deve ser tratada como um conjunto de  hipóteses a ser validado e aprimorado. Para isso, é essencial aplicar o Ciclo BML (Build, Measure, Learn). Esta abordagem é crucial na fase inicial do Lean Canvas, pois permite reduzir as incertezas antes de se aprofundar nos detalhes da solução e dos demais elementos do modelo de negócio. O Ciclo BML é entendido aqui como uma sequência prática de ideia, hipótese, experimento, aprendizado e atualização do canvas.

Figura 1499: Ciclo BML (Build-Measure-Learn) aplicado ao campo 4 do Lean Canvas

Exemplo: Startup FUT – Fix Up Tomorrow 

Para ilustrar a aplicação prática dos conceitos de Problema e Segmento de Clientes no Lean Canvas, será apresentado o estudo de caso da startup FUT – Fix Up Tomorrow (Hoefelmann et al.,  2019). 

Trata-se de uma iniciativa voltada ao desenvolvimento de uma solução digital para apoiar o gerenciamento e o controle da manutenção de máquinas industriais em micro e pequenas empresas do estado de Santa Catarina. O exemplo demonstra como a identificação estruturada das dores do cliente, a formulação de hipóteses e a validação por meio de experimentos permitem reduzir incertezas e orientar a construção de um modelo de negócio mais consistente e alinhado às reais necessidades do mercado.

Ideia de Produto: Aplicativo para auxiliar no gerenciamento e controle da manutenção de máquinas industriais de micro e pequenas empresas (MPES) do estado de Santa Catarina, criando uma rede de contato entre diferentes prestadores de serviço de manutenção com empresas carentes de um setor responsável pela atividade, promovendo o acompanhamento dessa tarefa de forma contínua e intermediando a venda/compra de máquinas usadas.

Ideias sobre a Solução

A ideia inicial está relacionada ao contexto dos serviços de manutenção e à interação entre prestadores de serviço e empresas que precisam desse tipo de atendimento. A percepção inicial é que há dificuldades na conexão entre quem oferece e quem demanda esse serviço, especialmente quando se trata de divulgação, credibilidade, formalização e organização da contratação.

Ideias de Features de Solução para as MPE

  • Criar e compartilhar um banco de dados sobre os prestadores de serviço; 
  • A solução deverá permitir que o prestador de serviço seja avaliado com relação ao trabalho realizado;
  • A solução deverá permitir que seja feito o planejamento e o controle da manutenção das máquinas;
  • A solução deverá permitir a comunicação fácil entre a MPE e os prestadores de serviço.

 

Hipóteses sobre a Solução – Clientes (MPE)

(H1) Uma plataforma que contivesse um banco de dados de prestadores de serviço de manutenção será uma solução atraente para solucionar o problema da ausência de rede de contatos entre MPEs e prestadores de serviço de manutenção;

(H2) Uma plataforma que contenha avaliações dos técnicos de manutenção e de seus serviços será uma solução atraente para solucionar o problema da falta de confiança em novos técnicos;

(H3) Uma plataforma que contenha o histórico de manutenção dos equipamentos e dê alertas de manutenções futuras necessárias será uma solução atraente para solucionar o problema da falta de controle/planejamento das manutenções;

(H4) Empresas usariam uma plataforma que tenha um canal ágil de sugestão/reclamação para orientar e até punir os prestadores de serviços.

Experimentos - Micro e Pequenas Empresas

Foi mostrado a nove Early Adopters um MVP (Tipo 1) da solução em formato de vídeo explicativo, e no final da demonstração eles foram entrevistados.

Clique na figura para acessar o vídeo do MVP do sistema que conecta empresas e prestadores de serviço de manutenção.

Resultados - Micro e Pequenas Empresas

(H1) Uma plataforma que contivesse um banco de dados de prestadores de serviço de manutenção será uma solução atraente para solucionar o problema da ausência de rede de contatos entre MPEs e prestadores de serviço de manutenção;

P1 – Você está satisfeito com a forma que encontra novos técnicos de manutenção? Se não, você buscaria por eles através de um aplicativo como mostrado no vídeo?

Resposta: 6 dos 9 não estão satisfeitos e buscariam um aplicativo.

P2 – Você acha que seria melhor procurar no aplicativo do que em ferramentas de pesquisa (p.ex. Google)?

Resposta: 9 dos 9 prefeririam um aplicativo, principalmente pelos filtros.

→ Hipótese Aprovada

(H2) Uma plataforma que contenha avaliações dos técnicos de manutenção e de seus serviços será uma solução atraente para solucionar o problema da falta de confiança em novos técnicos;

P1 – Você já contratou novos técnicos de manutenção por indicação de outras pessoas? Para você, a avaliação dos técnicos por meio do aplicativo funcionaria da mesma forma que a indicação dos mesmos por terceiros?

Resposta: 8 dos 9 acreditam que a avaliação no aplicativo seria muito bom. O outro entrevistado acredita que sim, se fossem realmente as pessoas que fizessem a avaliação e não o sistema automaticamente.

P2 – Dos itens mostrados no vídeo, você acha que os mesmos são adequados para que você selecione o melhor técnico de manutenção para o seu caso? Se não, o que faltaria?

Resposta: 9 dos 9 disseram que sim, porém um deles afirmou que é importante ter critérios pessoais, como boa educação, limpeza.

→ Hipótese Aprovada

(H3) Uma plataforma que contenha o histórico de manutenção dos equipamentos e dê alertas de manutenções futuras necessárias será uma solução atraente para solucionar o problema da falta de controle/planejamento das manutenções;

P1 – Você faria uso dos avisos de manutenção preventiva para evitar paradas inesperadas na linha de produção?

Resposta: 9 dos 9 disseram que sim, inclusive ressaltaram o quanto isso seria benéfico para eles.

P2 – Você acha que o aplicativo poderia ser englobado pela sua empresa como uma ferramenta de uso contínuo para verificar os dados de manutenção como histórico de gastos com manutenção, tempo de máquina parada, frequência de manutenções corretivas, enfim, controle e planejamento de manutenção?   

Resposta: 8 dos 9 disseram que sim. 2 deles falaram que um programa de computador, ou site com dados na nuvem talvez fossem melhor para isso. 1 disse que não, pois ele trabalha com construção civil e ele usaria somente quando precisasse.

→ Hipótese Aprovada

(H4) Empresas usariam uma plataforma que tenha um canal ágil de sugestão/reclamação para orientar e até punir os prestadores de serviços;

P1 – Você se sentiria mais seguro para contratar um técnico de manutenção sabendo que se algo desse errado poderia reclamar na plataforma? Você faria essa reclamação?

Resposta: 9 dos 9 disseram que sim.

P2 – Você estaria disposto a mandar dicas e sugestões para a plataforma melhorar?

Resposta: 9 dos 9 disseram que sim.

P3 – Você acha 24h um tempo adequado para a plataforma te retornar sobre o problema?

Resposta: 6 dos 9 disseram que sim; 3 disseram que é muito tempo, deveria ser no máximo 15 minutos.

P4 – Que tipo de “punição” você julgaria adequada no caso de técnicos mal avaliados, e de benefícios no caso de técnicos bem avaliados?

Resposta: 9/9 disseram pela exclusão de técnicos mal avaliados e mais visibilidade para técnicos bem avaliados.

P5 – Você se sentiria bem sendo avaliado pelo técnico de manutenção? Mudaria o seu comportamento no caso disso acontecer?

Resposta: 8 dos 9 responderam que sim. 1 não vê necessidade.

Ideias de Features de Solução para os Prestadores de Serviço de Manutenção

  • A Solução deverá possibilitar uma boa visibilidade dos prestadores de manutenção, conectando-os com possíveis clientes;
  • A Solução deverá possuir um canal ágil de sugestão/reclamação para orientar e até mesmo possibilitar a avaliação das empresas;

Hipóteses sobre a Solução – Prestadores de Serviço de Manutenção

(H1) Uma plataforma em que o prestador de serviço de manutenção possa se cadastrar e divulgar seu serviço sem gastar muitos recursos, conectando-o à possíveis clientes, será uma solução atraente para promover a divulgação e marketing;

(H2) Prestadores de serviços usariam uma plataforma que tenha um canal ágil de sugestão/ reclamação para orientar e até avaliar empresas.

Experimentos - Micro e Pequenas Empresas

Foi mostrado a seis Early Adopters um MVP (Tipo 1) da nossa solução em formato de vídeo explicativo, e no final da demonstração os eles foram entrevistados.

Clique na figura para acessar o vídeo do MVP do sistema que dá visibilidade aos prestadores de serviço de manutenção.

Resultados - Prestadores de Serviço de Manutenção

(H1) Uma plataforma em que o prestador de serviço de manutenção possa se cadastrar e divulgar seu serviço sem gastar muitos recursos, conectando-o à possíveis clientes, será uma solução atraente para promover a divulgação e marketing;

P1 – Com relação às habilidades do prestador de serviço apresentado no vídeo, tais características são suficientes para descrever a qualidade do seu trabalho? Se não, que informações estão faltando?

Resposta: Os seis entrevistados responderam que sim.

P2 – Você costuma trabalhar com mais de um cliente por dia? Qual a distância média percorrida?

Resposta: Os seis entrevistados trabalham com diferentes clientes (50 km máx).

P3 – Você gostou da característica da plataforma de possibilitar a escolha da distância máxima do seu serviço? Dentro de um raio de 0-50km / 0-100km / 0-200km / 0-300km / Santa Catarina toda ?

Resposta: Os seis entrevistados gostaram, sendo que três atendem outras cidades.

P4 – Caso a sua avaliação seja acima da média, qual bonificação por parte do aplicativo você gostaria de ter?

Resposta: Cinco optaram por uma Classificação de destaque como melhor opção.

→ Hipótese Aprovada

(H2) Prestadores de serviços usariam uma plataforma que tenha um canal ágil de sugestão/ reclamação para orientar e até avaliar empresas; 

P1   Você se sentiria mais seguro para prestar um serviço de manutenção sabendo que se algo desse errado poderia reclamar na plataforma?

Resposta: Os seis entrevistados indicaram que é uma característica importante.

P2 – Você enviaria dicas para a plataforma melhorar?

Resposta: Os seis entrevistados disseram que sim.

P3 – Você se sentiria bem sendo avaliado pela empresa para a qual prestou serviço de manutenção?

Resposta: Os seis entrevistados disseram que sim (feedback para melhorar).

P4 – Qual “punição” seria adequada que a plataforma desse para empresas mal avaliadas? E qual “benefício” seria adequado que a plataforma desse para empresas bem avaliadas?

Resposta: Os seis entrevistados indicaram “não sei como punir um cliente”

P5 – Você acha 24h um tempo adequado para a plataforma te retornar sobre o problema?

Resposta: Os seis entrevistados disseram que sim.

Referências

BLANK, S; DORF, B. The startup owner’s manual: the step-by-step guide for building a great company. Pescadero: K&S Ranch, 2012.

GOTHELF, J.; SEIDEN, J. Lean UX: designing great products with agile teams. 2. ed. Sebastopol: O’Reilly Media, 2016.

HOEFELMANN, A. E.; GREGÓRIO, J. L.; AMORIM, N. C. DE; ZENKNER, P. A. D. Modelo de Negócio da Empresa FUP – Fix Up Tomorrow – Disciplina EMC 410202 – Lean Startup. PPGEM/UFSC. Florianópolis, 2019.

KAPLAN-MOSS, J. Demos, Prototypes, and MVPs. January 5th, 2020 <https://jacobian.org/2020/jan/16/demos-prototypes-mvps/> Acesso em 20/04/2023. 

KOHAVI, R.; TANG, D.; XU, Y. Trustworthy online controlled experiments: a practical guide to A/B testing. Cambridge: Cambridge UniversityPress, 2020.

MAURYA, A. Running Lean – A systematic process for iterating your web application from Plan A to a plan that Works. O’Reilly, 2010.

MAURYA, A. Running Lean: iterate from Plan A to a plan that works. 2. ed. Sebastopol: O’Reilly Media, 2012. 

OSTERWALDER, A.; PIGNEUR, Y. Business model generation: a handbook for visionaries, game changers, and challengers. Hoboken: John Wiley & Sons, 2010.

OSTERWALDER, A.; PIGNEUR, Y.; BERNARDA, G.; SMITH, A. Valueproposition design: how to create products and services customers want. Hoboken: John Wiley & Sons, 2014.

RIES, E. The lean startup: how today’s entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business, 2011.

#printfriendly a { color: blue !important; text-decoration: underline !important; } #printfriendly i, #printfriendly em { color: purple !important; } @media print { .break-page-before { page-break-before: always !important; } h1 { page-break-before: always !important; font-size: 32px !important; } div.no-page-break-before h1, div.no-break-page-before h1 { page-break-before: avoid !important; } }