🎯 Clinicafy — Auditoria cs-*

📋 cs-product-manager — Product Manager (RICE & JTBD)

Auditoria técnica e estratégica pela ótica cs-product-manager — Product Manager (RICE & JTBD). Achados classificados por severidade, plano de ação e matriz de decisão.

!

Veredito: Portfolio de features rico e bem pensado para o ICP médico, mas sem roadmap priorizado por RICE e com bloqueante técnico paralisando entrega.

26 páginas de funcionalidades (App.tsx:40-64) cobrem bem o JTBD de um médico generalista: agenda, pacientes, prontuário, financeiro, estoque, guias TISS/TUSS, módulo odonto. Porém o bloqueante atual (DATABASE_URL) impede deploy de 3 features completas. Sem product metrics, sem user research documentada e sem framework de priorização aplicado.

26
Páginas/features no app
3
Features prontas não deployadas
0
User interviews documentadas
TISS/TUSS
Feature diferenciadora (guias)
0
Product OKRs definidos

Dimensões Analisadas

Pontuação por área de análise.

Feature Completeness (JTBD)

75

Cobre bem o job 'gerir minha clínica': agenda, pacientes, prontuário, financeiro, estoque. TISS/TUSS é diferenciador real.

1 achados

Delivery / Backlog

25

3 features completas bloqueadas por infraestrutura. Sem roadmap visível. Sem critério de priorização RICE.

2 achados 2 bloqueante(s)

Discovery / Validação

20

Sem user interviews, sem usability tests documentados, sem cohort analysis.

1 achados

Metrificação de Produto

15

PRODUCT_EVENTS definidos mas sem destino. Sem DAU/WAU/MAU tracking.

1 achados

🔎 Achados (4)

1 crítico(s) · 0 alto(s) · 1 bloqueante(s). Clique para expandir.

3 features completas bloqueadas — Estoque, R2 Storage, SubscriptionsCríticaBloqueanteEsforço baixoDelivery / Time to Value

O que é: HANDOFF.md:42-66 documenta 3 features completamente implementadas (tsc limpo + vite build ok) mas não deployadas: Subscriptions (GET/POST /api/subscriptions), R2 Storage (upload de exames), Módulo de Estoque. Bloqueio único: DATABASE_URL + MIGRATION.sql não rodados.

Onde: HANDOFF.md:42-66

Impacto: Features que usuários podem precisar já existem mas estão invisíveis. Custo de oportunidade de retenção e upsell.

✅ Correção: Desbloquear com DATABASE_URL (hPanel) + rodar MIGRATION.sql + push = deploy automático. 1 dia de trabalho para desbloquear 3 features.
Sem framework RICE aplicado — priorização ad hocMédiaEsforço medioRICE Framework / Roadmap

O que é: Não há ROADMAP.md, BACKLOG.md ou qualquer documento de priorização. Próximos passos estão listados linealmente no HANDOFF.md (seção 5) sem critério de impacto/confiança/esforço.

Onde: HANDOFF.md:82-91 (próximos passos ad hoc)

Impacto: Risco de trabalhar em features de baixo impacto antes de resolver bloqueantes críticos.

✅ Correção: Criar BACKLOG.md com RICE: Reach (usuários impactados), Impact (1-3), Confidence (%), Effort (semanas). Priorizar top 10 por RICE score.
Módulo odontológico mencionado no HANDOFF mas não listado em App.tsxMédiaEsforço altoFeature Discovery / ICP Expansion

O que é: HANDOFF.md referencia 'módulo odonto' como feature pendente. Não há OdontoPage.tsx em src/pages/. Dentistas são um ICP adjacente de alta LTV.

Onde: src/pages/ (ausência de odonto) + HANDOFF.md

Impacto: Oportunidade de mercado adjacente (60k+ dentistas no Brasil) não capturada. Mas adicionar antes de resolver bloqueantes é erro de priorização.

✅ Correção: Incluir odonto no BACKLOG com RICE. Prioridade: após desbloqueio de infra e onboarding de usuários médicos ativos.
MarketingInsights.tsx (7KB) — feature de analytics para o médico sem dados reaisMédiaEsforço medioJTBD / Value Delivery

O que é: src/pages/MarketingInsights.tsx existe (7KB) mas sem dados reais de marketing instrumentados no produto. Médicos não precisam de 'marketing insights' — precisam de relatórios clínicos e financeiros. Pode ser feature de baixo valor no ICP atual.

Onde: src/pages/MarketingInsights.tsx

Impacto: Feature de baixo RICE consome espaço de menu e confunde usuário sobre o posicionamento do produto.

✅ Correção: User research: validar com 5 usuários se usam MarketingInsights. Se <20% usam, deprecar e redirecionar effort para features de retenção.

📋 Plano de Ação

Cronograma de implementação recomendado.

1

Deploy das 3 features bloqueadas (1 dia)

DATABASE_URL + MIGRATION.sql + push. Features: Subscriptions, Storage, Estoque.
delivery
1 dia · CRÍTICO
2

RICE Backlog (1 semana)

Criar BACKLOG.md com top 15 items priorizados por RICE. Include: odonto, upsell nudge, email onboarding.
roadmap
1 semana
3

5 user interviews com médicos (2 semanas)

Call de 30min com 5 usuários ativos para validar AHA moment e prioridades de feature
discovery
2 semanas
4

Validar MarketingInsights com usuários

Mixpanel/GA4: medir uso de MarketingInsights. <20% → deprecar.
validacao
1 mês

Matriz de Decisão

CritérioFonteStatusBloqueante
Feature Deliverycs-product-manager3 features prontas bloqueadasSIM
Feature Coverage (JTBD)cs-product-manager26 páginas bem pensadasnão
Priorização RICEcs-product-managerAusentenão
User Researchcs-product-managerZero validação documentadanão
Product Metricscs-product-managerPRODUCT_EVENTS sem destinonão