Felipe Felamingo· Product Manager · Cases

Case EMD

Como cheguei a uma hipótese de produto e como estou validando.

O EMD é um sistema para o arquiteto que compete pela forma como opera, não pela assinatura estética. Este case mostra o raciocínio de produto por trás dele: por que o problema importa, o que atacar, como estruturar a solução e como validar a aposta.

Product senseBuilder mindsetSenso de negócio
1

Por quê

A maioria dos arquitetos compete no lugar errado.

A maior parte dos arquitetos não é nome de mercado. São profissionais solo, freelancers e escritórios pequenos ou em crescimento, que operam sem sistema: fazem tudo sozinhos, não tiveram formação de gestão e vivem sem tempo para captar cliente.

O mercado trata a estética como o único diferencial possível. Mas o belo é relativo, e consolidar uma assinatura leva uma vida inteira ou custa caro. A IA agrava o quadro: o cliente passou a desconfiar do que vê — até uma foto de projeto executado pode parecer render.

Estética
frágil e commodity
por quê
  • Gosto é relativo: o que encanta um cliente afasta outro.
  • A IA derruba o custo de produzir "bonito".
  • Nem todo cliente compra estética como valor central.
Sistema
defensável
por quê
  • Processo, dados e integrações não cabem num print.
  • Melhora com o uso: cada projeto alimenta o próximo.
  • Resolve dor que o cliente paga: prazo, jurídico, financeiro.

Para os poucos trendsetters, competir pela estética faz sentido. Para o resto, apoiar toda a diferenciação nela é frágil. Quem se destaca agora entrega um sistema: previsibilidade, comunicação e transparência. Um portfólio bonito atrai o primeiro cliente; o sistema garante os próximos. É uma aposta, ainda a validar.

O mercado em quatro números · toque para ver o que cada um revela

82%moradias feitas sem arquiteto ou engenheiro
A maioria das obras no Brasil acontece sem projeto profissional. O mercado potencial é enorme e mal atendido.
CAU/BR & Datafolha, 2022
64%dos profissionais atuam por conta própria
A maior parte é solo ou escritório pequeno — exatamente quem opera sem sistema e sem estrutura de gestão.
II Censo CAU/BR, 2020
35%ganham de 1 a 3 salários mínimos
A renda baixa reforça a fragilidade do modelo atual e a sensibilidade a preço de qualquer solução.
II Censo CAU/BR, 2020
59%se preocupam com o que é real ou falso na internet
A desconfiança com imagem cresce. Diferenciação apoiada só no visual fica ainda mais frágil.
Reuters Institute, Digital News Report 2024
O que já sei, o que suponho e o que ainda duvido?

Certezas

  • Caos operacional é estrutural, não individual
  • Comercial dói: precificação baixa e lead sem resposta são sistêmicos
  • Comunicação com o cliente é caótica; decisões verbais geram ruído
  • Cliente não entende escopo nem custo do serviço
  • Contratos de proteção são negligenciados
  • Arquitetos não têm formação de gestão; maioria sem métricas nem BIM
  • Assinatura estética não é vantagem competitiva sustentável
  • Brasil tem ~3x mais arquitetos por 100 mil hab. que os EUA
De onde vêm estes dados?
  1. CAU/BR; DATAFOLHA. 82% das moradias do país são feitas sem arquitetos ou engenheiros. 2022. Acesso em: jul. 2026.
  2. CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL. II Censo das Arquitetas e Arquitetos e Urbanistas do Brasil. 2020. Acesso em: jul. 2026.
  3. NATIONAL COUNCIL OF ARCHITECTURAL REGISTRATION BOARDS (NCARB). The Number of U.S. Architects Fell by 4% in 2024. 2024. Acesso em: jul. 2026.
  4. CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL. Anuário de Arquitetura e Urbanismo. Acesso em: jul. 2026.
  5. REUTERS INSTITUTE FOR THE STUDY OF JOURNALISM. Digital News Report 2024. Oxford: University of Oxford, 2024. Acesso em: jul. 2026.
  6. CONSELHO DE ARQUITETURA E URBANISMO DO BRASIL. Pesquisa aponta desafios para a digitalização na arquitetura e urbanismo. Acesso em: jul. 2026.
  7. CONSELHO DE ARQUITETURA E URBANISMO DE MINAS GERAIS (CAU/MG). Pesquisa evidencia necessidade de capacitação em empreendedorismo. Acesso em: jul. 2026.
  8. TORRES, Teresa. Opportunity Solution Trees. Product Talk. Acesso em: jul. 2026.
  9. CAGAN, Marty. The Four Big Risks. SVPG. Acesso em: jul. 2026.
  10. PAIVA, Rodrigo. O software que pensa, decide e executa. PM3, 2026. Material de curso. Acesso em: jul. 2026.

Suposições

  • Arquitetos pagariam por um sistema de administração
  • A assinatura não pesaria diante das economias geradas
  • Preço até ~R$300/mês é aceitável
  • Indicação ainda é o maior canal de captação
  • Buscam templates prontos para o administrativo
  • Clientes querem assistente inteligente, não chatbot
  • Se identificam como criativos, não como gestores

Dúvidas

  • Começar por comercial, gestão ou projeto?
  • Qual o preço-teto que o mercado aceita?
  • O mercado sustenta um SaaS? Onboarding self-service?
  • Aceitam IA atendendo o cliente?
  • Serviria para quem quer reformar sem arquiteto?
  • Focar em solos e pequenos ou expandir?
  • Estética é o valor central para o cliente?
2

O quê

De muitas dores possíveis, a decisão que importa é onde focar primeiro.

O diagnóstico levantou um inventário amplo de dores, da prospecção ao jurídico. Desse conjunto saíram dez dores priorizadas para a primeira rodada de validação, por um critério de recorrência, sustentação por dados, aderência às oportunidades e viabilidade de testar agora.

Essa priorização é uma hipótese de trabalho, não uma verdade fechada. O mockup no ar é o primeiro filtro para confirmar, reordenar ou reabrir a lista.

Do inventário à prioridade

10
dores priorizadas para a 1ª rodada, extraídas de um inventário maior levantado no discovery.
Uma aposta de foco — o que atacar primeiro, não tudo o que dói no mercado.

As dez dores priorizadas

01Dependência do fundador

Quase tudo passa pelo arquiteto dono: vende, projeta, negocia, fala com o cliente e cuida do administrativo. Conhecimento numa pessoa só.

02Prospecção sem processo

A captação depende de indicação. Leads ficam sem resposta e ninguém acompanha em que ponto cada negociação está.

03Comunicação caótica

A conversa se espalha por WhatsApp, e-mail e ligações. Combinações são feitas de boca e raramente ficam registradas.

04Cliente sem visibilidade

Depois de contratar, o cliente não sabe em que etapa o projeto está, o que já foi aprovado e o que vem a seguir.

05Proteção jurídica frágil

Trabalhos avançam com acordos verbais ou contratos genéricos. Prazos, responsabilidades e escopo raramente são formalizados.

06Financeiro invisível

O controle do dinheiro vive em planilhas soltas ou na cabeça do arquiteto. Falta clareza sobre o que há a receber e a margem.

07Conhecimento na cabeça das pessoas

Informações de projetos, clientes e fornecedores ficam dispersas. Quando alguém sai, o histórico vai junto.

08Operação sem métricas

Sem indicadores de desempenho comercial, rentabilidade ou produtividade, as decisões são tomadas na intuição.

09Precificação inconsistente

Sem método claro, o preço muda de um orçamento para outro e o serviço é cobrado abaixo do que vale.

10Ferramentas fragmentadas

O dia a dia se espalha por apps desconectados. Nada conversa entre si e a informação se perde nas emendas.

Por que estas dores foram priorizadas?

Critério de priorização

  • Recorrência: aparece de forma repetida na pesquisa e na experiência de mercado.
  • Sustentação por dados secundários: tem respaldo em fontes (CAU/BR, censos, estudos setoriais).
  • Aderência às macro-oportunidades: alimenta integração, transparência ou proteção.
  • Viabilidade de validar agora: dá para testar no mockup e no beta com os recursos atuais.

É uma hipótese de trabalho. O mockup no ar pode confirmar, reordenar ou reabrir a lista.

O que ficou fora da primeira priorização?
3

Como resolver

Três macro-oportunidades, uma plataforma, dois portais.

Tudo o que o produto precisa endereçar pode ser resumido em três grandes macro-opportunities: integração, transparência e proteção.

Integraçãoreunir num só ambiente o que hoje vive espalhado em ferramentas soltas
Transparênciatornar o andamento do projeto visível e registrado para as duas partes
Proteçãoformalizar acordos, aprovações e alterações com rastreabilidade

Essas oportunidades organizam a descoberta. A árvore abaixo mostra o caminho completo — dos resultados desejados às features de cada portal.

Os pilares estratégicos

Os três grupos são os pilares estratégicos do EMD. Surgiram da síntese do Discovery, ao agrupar as necessidades da pesquisa em macro-opportunities que orientam a arquitetura — o mesmo posicionamento da landing page.

A arquitetura de IA do produto

  • a plataforma organiza regras, contexto, histórico e dados;
  • a IA atua só onde geração de linguagem agrega valor;
  • a lógica de negócio segue determinística;
  • regras e revisão humana reduzem o risco;
  • a IA acelera o trabalho, mas não decide pelo usuário.

É uma arquitetura AI-enabled: a IA é ferramenta sob controle da regra e do humano, não o motor de decisão.

4

Como estruturar

A arquitetura decide o custo antes da priorização.

Antes de estimar custo, cada feature passa por duas escolhas. O motor (lógica interna) define a previsibilidade do erro. A superfície (interação) define a expectativa do usuário. A combinação define o custo do erro — e é isso, não a tela, que faz o preço.

O EMD é determinístico na base e sobe para GenAI apenas nas features de linguagem, sempre na superfície AI-enabled, com regra e revisão humana. Evita o quadrante GenAI × AI-native, onde o erro chega sozinho ao cliente e coloca o produto em xeque.

Por isso a arquitetura vem antes da tabela de custos: dependências e estrutura influenciam diretamente o custo e a ordem de execução.

Por que isto primeiro

Motor define a previsibilidade do erro. Superfície define a expectativa. Autonomia define o custo do erro. Só com as três escolhas fixadas o custo de cada feature faz sentido — por isso a arquitetura antecede a priorização.

deslize para ver a matriz inteira

5

Como priorizar

Só depois da arquitetura, o custo decide a ordem.

Com motor e superfície definidos, cada feature recebe três notas de 1 a 5: complexidade, custo de desenvolver e custo de manter. A média vira um veredito que a transforma numa decisão — o que entra no Beta, o que espera validação e o que fica para depois do lançamento.

A tabela é dividida por portal por dependência: o portal do profissional é a fundação, e o do cliente depende dele. O veredito também fixa a ordem de entrada nas versões.

Da nota à decisão

A priorização adapta práticas de valor × esforço e de estimativa relativa (t-shirt sizing). Com equipe de uma pessoa, a média orienta a ordem; com dados de validação, ela fica mais rica.

Ver a tabela completa de priorização · custo, complexidade e veredito

deslize para ver a tabela inteira

O mesmo critério, na linguagem de MoSCoW e RICE

Meu veredito nasceu de um critério próprio (valor contra esforço). Num quadrante, ele vira a leitura visual do RICE: cada bolinha é uma feature, posicionada pelo esforço (a média real da tabela) e pelo valor estimado. A cor é o veredito, que já é o rótulo de MoSCoW.

deslize para ver o gráfico inteiro

QUICK WINSalto valor · baixo esforçoAPOSTAS GRANDESalto valor · alto esforçoINCREMENTAISbaixo valor · baixo esforçoEVITAR POR ORAbaixo valor · alto esforçoEsforço (média das notas: complexidade, dev, manutenção) →Valor / prioridade (estimado) →1122334455P112345678910111213141516171819P2P1*P2*
Base essencial · MustIncluir no Beta v01 · MustIncluir no Beta v02 · ShouldAguardar validação · CouldAfter Launch · Won't (por agora)Plataforma completa (P1*, P2*)
P1 Portal do profissional (base)1 Agente Comercial2 Gerador de Propostas3 Cobrança4 Administração financeira5 Painel financeiro (arq.)6 Painel comercial (arq.)7 Painel de projetos8 Home Arquiteto9 Integração Notion/Trello10 Gestão de Projetos11 Diário + Atas + Repositório12 Contratos e Termos13 Equipe e Fornecedores14 Integração E-mail15 WhatsApp + Chat16 Assistente Virtual17 Solicitar Alteração + Aprovar18 Home (cliente)19 Painel financeiro (cliente)P2 Portal do cliente (base)P1* Plataforma profissional completaP2* Plataforma do cliente completa

Como ler: o eixo horizontal é o esforço, a média das três notas da tabela acima (dado real). O eixo vertical é o valor e a prioridade, hoje uma estimativa vinda das oportunidades do movimento 3 (o Reach × Impact do RICE). As bolinhas cheias P1 e P2 são as bases que entram primeiro, de baixo esforço. As vazadas P1* e P2* são as mesmas plataformas na versão completa, com todas as features integradas: muito mais esforço (4 a 5) e valor entre 3 e 4. É por isso que a estratégia começa pela base e não pela plataforma inteira.

O plano de versões: o que entra, e quando

Priorizei do essencial pro futuro. O Beta v0.1 é a casca simplificada hospedando três workflows determinísticos, propostas, contratos e termos, validados por Wizard of Oz assistido. O precificador automático entra no Beta v0.2; o resto espera a validação justificar ou fica pro pós-lançamento.

BaseMust haveA casca simplificada que hospeda os três agentes: entrar, achar e navegar entre eles. Sem painéis, home ou dashboards.
Base do portal (casca simplificada)
Beta v0.1Must haveO que vai pro ar primeiro, validado por Wizard of Oz assistido. Versões simplificadas e sem IA nos contratos (determinístico).
Gerador de Propostas (simplificado)Contratos e Termos (determinístico)
Beta v0.2Should haveEntra na sequência, logo depois do lançamento. É aqui que o precificador automático passa a preencher as propostas.
Precificador automáticoCobrançaHome e painéis do arquitetoDiário + Atas + RepositórioAprovar Etapa / Solicitar Alteração
Aguardar validaçãoCould haveSó avança se a evidência justificar.
Portal do clienteAdministração financeiraPainel comercialPainel de projetosEquipe e Fornecedores
After LaunchWon't (por agora)Fica fora do go-to-market inicial.
Agente ComercialGestão de ProjetosIntegração Notion/TrelloIntegração E-mailWhatsApp + ChatAssistente VirtualPainel financeiro (cliente)
MoSCoW e RICE em texto

Do veredito ao MoSCoW

  • Must have: Base essencial e Beta v01, o mínimo pra o produto existir e ir pro ar.
  • Should have: Beta v02, importante, entra logo na sequência.
  • Could have: Aguardar validação, só avança se a evidência justificar.
  • Won't have (por agora): After Launch, fica fora do go-to-market.

O veredito ainda acrescenta o que o MoSCoW puro não tem: a ordem de entrada no tempo.

Do critério ao RICE

  • Effort: a minha média das três notas (complexidade, custo de dev e custo de manter), o eixo horizontal do gráfico.
  • Reach e Impact: vêm da árvore de oportunidades e dos resultados (movimento 3), o eixo vertical.
  • Confidence: vem do plano de validação (movimento 6), mockup, Wizard of Oz e fake doors. Os itens em "Aguardar validação" são os de menor confiança hoje.

O critério atual é um RICE enxuto: valor contra esforço de propósito, porque eu estava sozinho e sem dado. O RICE completo, (Reach × Impact × Confidence) ÷ Effort, é o próximo passo quando a validação trouxer o valor medido, não estimado.

6

Como validar

As respostas não estão dadas. Existe um plano para consegui-las.

A validação avança por versões do produto, cada uma com um método, funcionalidades e métricas próprias. O objetivo não é provar todas as hipóteses, e sim gerar evidência suficiente para decidir: parar, ajustar ou escalar.

A landing page é parte dessa estratégia, por dois caminhos complementares. A validação não depende só dela.

1. Landing page → Mockup
  • captura de interesse em escala
  • observação de comportamento real
  • cadastro e conversão
2. Abordagem direta
  • entrevistas e demonstrações
  • pesquisa com usuários
  • apresentação direta do teste
  • aprofundamento qualitativo

Onde o projeto está

Agora: a landing e o mockup estão no ar, e o Wizard of Oz assistido está rodando como a primeira fase de validação, com o portal do profissional. O Workshop com fake doors vem depois, conforme os aprendizados desta rodada.

Roadmap de aprendizado

No arMockup + landing
O que existe

Landing page no ar e mockup da plataforma no Replit. O botão do cliente coleta dados — ainda não é produto, é instrumento de teste.

O que medimos e por quê
  • CTR do anúncio → landing: há atenção ao tema
  • Conversão da landing (visita → cadastro): há intenção
  • Ranking de cliques por dor: quais dores puxam mais
  • Intenção de uso declarada
O que ainda precisamos aprender?
  • As dez dores priorizadas são mesmo as mais relevantes?
  • Ficou de fora alguma dor importante?
  • Alguma priorizada pesa menos do que o esperado?
  • A priorização se sustentou pra entrar no Wizard of Oz?
Fase 1 · agoraWizard of Oz assistidoVocê está aqui
Funcionalidades
  • Gerador de Propostas simplificada
  • Contratos e Termos simplificada
  • Base do portal do profissional, a casca que hospeda os três simplificada
  • Bastidor manual onde a automação ainda não existe simulada
O que medimos e por quê
  • Conclusão da tarefa: a feature resolve de ponta a ponta?
  • Tempo economizado vs. processo atual
  • Redução de erros e retrabalho
  • Percepção de valor e satisfação do profissional
  • Uso recorrente e retenção inicial
O que ainda precisamos aprender?
  • A feature entrega valor real, ou só interesse?
  • O profissional confia na IA que gera para ele aprovar?
  • Ele volta a usar sem ser lembrado?
Fase 2Workshop · fake doors
Entram nesta versão
  • Diário + Atas, Cobrança, Home, Aprovar Etapa completa
  • Fake doors de painel financeiro, assistente virtual e integrações simulada
  • Grupo maior no workshop (Cidad3)
O que medimos e por quê
  • Relevância das dores num grupo maior
  • Disposição a pagar (WTP) e intenção de compra
  • Cliques nas fake doors: apetite por features futuras sem construí-las
  • Ampliação de mailing e de participantes
O que ainda precisamos aprender?
  • Quanto o mercado pagaria?
  • Quais features futuras despertam mais interesse?
  • A priorização se sustenta num grupo maior?
DepoisDecisão e próximos passos
A decisão a tomar

Com a evidência acumulada, cada hipótese cai num de quatro caminhos: continuar, ajustar, postergar ou abandonar.

Próximos passos possíveis
  • Escalar o que se provou
  • Pivô de funcionalidades: novas hipóteses, mesmo público
  • Pivô de mercado: mirar o cliente final que reforma

A jornada como discovery contínuo

O Double Diamond (Design Council) separa o espaço do problema do espaço da solução — cada um com um movimento de divergir e convergir. Na leitura contínua (continuous discovery, de Teresa Torres, e as releituras atuais para produtos com IA), as etapas deixam de ser lineares: cada diamante tem loops internos de iteração, e cada experimento na entrega reabre a descoberta.

discovery contínuo · cada experimento reabre a descoberta ESPAÇO DO PROBLEMA Descobrir · Definir ESPAÇO DA SOLUÇÃO Desenvolver · Entregar iterar iterar divergir ◄ ► convergir divergir ◄ ► convergir você está aqui
Descobrir
  • pesquisa e dados secundários
  • experiência de mercado
  • síntese em dores
Definir
  • matriz CSD
  • priorização das dores
  • macro-oportunidades e OST
Desenvolver
agora
  • arquitetura e priorização
  • landing + mockup no ar
  • Fase 1 · Wizard of Oz
Entregar
  • Fase 2 · Workshop com fake doors
  • decisão: escalar, ajustar ou pivotar
  • aprendizado que realimenta a descoberta

Mockup, Wizard of Oz e Workshop com fake doors não fecham o ciclo: cada um alimenta uma nova rodada de discovery, ajustando dores, oportunidades e priorização.

Em andamento

O produto já tem cara.

A mesma identidade da landing page, agora na plataforma em validação.

escritoriomodelo.replit.app
EMDFuncionalidadesPreçosEntrar

O sistema operacional do escritório de arquitetura.

Comercial, projetos, financeiro e jurídico num só lugar — com IA onde ela agrega, sem abrir mão do controle.

Começar agoraver demonstração
EMD
Agora explore o Web App →

Continue a experiência na plataforma construída ao longo de todo o processo.

Ver a anatomia e o app rodando, no Build →

Este case mostra a decisão. O Build mostra a execução. Documento vivo, atualizado conforme chegam resultados.