CarePilot

Keep post-visit care moving without chasing everyone down.

CarePilot is a service-as-software product for clinics, care coordinators, and family operators who need to manage what happens after a medical visit, test, or procedure. It turns fragmented follow-up work into a repeatable workflow: capture the next steps, assign responsibility, schedule reminders, collect updates, and escalate when nothing happens. The first version is intentionally narrow: one high-value follow-up workflow that can be sold and delivered manually before being automated.

Business Goals

  • Reach 10 paying customers within 90 days of launch with at least 60 percent coming from a repeatable outreach channel.
  • Close 3 pilot-to-paid conversions per month by week 12 with an average first contract value of at least 500 USD.
  • Maintain gross margin above 60 percent in the service phase by limiting manual delivery time to under 2 hours per active customer per week.
  • Achieve 40 percent of customers renewing for a second month or expanding to a second workflow within 60 days.
  • Validate at least one repeatable acquisition message with a landing-page conversion rate above 5 percent and a booked-call rate above 15 percent.

User Goals

  • Reduce missed follow-ups after visits, tests, and referrals.
  • Make it obvious who owns each next step and when it is due.
  • Lower the time spent chasing updates across WhatsApp, phone calls, and spreadsheets.
  • Surface exceptions early when a task stalls or a patient does not respond.
  • Provide a simple status trail that can be shared with the client or care team.

Non-Goals

  • Not a clinical decision-support tool and not a source of diagnosis or treatment recommendations.
  • Not a full EMR, EHR, or patient portal replacement.
  • Not a broad family health platform or longitudinal health infrastructure.
  • Not designed for emergency coordination or acute care escalation workflows.

Clinic Ops Manager Ana, 39 - Ana manages post-consultation follow-up for a small private clinic. She is responsible for making sure referrals, exams, and return visits happen, but she currently tracks everything in spreadsheets and WhatsApp.

Clinic Ops Manager Ana, 39

  • As a clinic ops manager, I want every follow-up item captured in one place, so that nothing depends on memory.
  • As a clinic ops manager, I want reminders and escalations to happen automatically, so that my team stops manually chasing every patient.
  • As a clinic ops manager, I want to see stalled items at a glance, so that I can intervene before the case is lost.

Care Coordinator Bruno, 33 - Bruno coordinates exams, appointments, and documents for a small concierge health service. He needs a lightweight system that helps him manage many small handoffs without a complex platform.

Care Coordinator Bruno, 33

  • As a care coordinator, I want to create a follow-up plan in under 2 minutes, so that I can work fast during live calls.
  • As a care coordinator, I want structured notes and contact logs, so that I can prove what happened and when.
  • As a care coordinator, I want to reuse templates for common journeys, so that delivery becomes more consistent over time.

Family Delegate Sofia, 47 - Sofia helps manage healthcare logistics for her father. She does not want to make medical decisions, but she wants to know what was recommended, what is pending, and what she needs to do next.

Family Delegate Sofia, 47

  • As a family delegate, I want to understand the next steps in plain language, so that I know what to do without chasing the clinician.
  • As a family delegate, I want reminders for deadlines and appointments, so that important tasks do not slip.
  • As a family delegate, I want a simple status view, so that I can coordinate without feeling overwhelmed.

Follow-up Case Capture · High priority

  • Create a structured record for each post-visit journey so the team can track next steps from a single source of truth.
  • Allow users to create a case from a template or from scratch with patient name, owner, journey type, and due dates.
  • Support common journey types such as referral, exam scheduling, procedure prep, and return-visit follow-up.
  • Capture the recommended next action, responsible person, deadline, and notes.
  • Allow file attachment references such as PDFs, lab orders, and WhatsApp screenshots without storing unnecessary clinical detail.
  • Prevent case creation without an assigned owner and at least one next step.

Tasking and Escalation · High priority

  • Turn a case into actionable tasks with reminders, overdue flags, and escalation rules to avoid silent breakdowns.
  • Generate one or more tasks per case with an owner, due date, priority, and channel for reminder.
  • Send reminders via email and WhatsApp-based notifications using templates.
  • Escalate overdue tasks to a manager after configurable time thresholds.
  • Mark tasks as done, snoozed, delegated, or blocked with a required reason for blocked status.
  • Log every status change in an audit trail.

Communication Log · Medium priority

  • Track every meaningful touchpoint so the operator can see what was said, by whom, and what remains unresolved.
  • Store call notes, message summaries, and manual updates in a timeline view.
  • Support quick logging from mobile after a phone call or WhatsApp exchange.
  • Tag communication outcomes such as reached, no answer, waiting for reply, scheduled, completed.
  • Allow redaction of sensitive content and metadata-only logs where needed.
  • Timestamp each event automatically and record the actor.

Templates and Reusable Workflows · Medium priority

  • Enable repeatability by turning successful service motions into reusable templates.
  • Provide starter templates for 3 to 5 high-frequency journeys.
  • Allow admins to customize steps, reminder timing, and escalation policies per template.
  • Track template usage, completion rates, and average time to close.
  • Support cloning a completed case into a new template candidate.
  • Highlight steps that most often create delays or require manual intervention.

Reporting and Export · Low priority

  • Give customers proof of value and simple operational visibility without building a full analytics suite.
  • Show counts for open cases, overdue tasks, completed follow-ups, and average days to resolution.
  • Allow CSV export of cases, tasks, and communication logs.
  • Provide a weekly summary email with unresolved items and aging risk.
  • Support a lightweight dashboard for the operator and a separate read-only view for supervisors.
  • Keep metrics focused on operational completion, not clinical outcomes.

First-Use Onboarding

  • User lands on a focused signup page and chooses one workflow type, such as referral follow-up or exam scheduling.
  • User enters the organization name, primary contact, and preferred reminder channels.
  • User selects a template or creates the first follow-up case manually.
  • System generates the first task list, reminder schedule, and owner assignment.
  • User receives a visible success state showing the first case is active within 5 minutes.
  • User is prompted to invite one additional team member only after the first case is created.

1. Create a Follow-up Case

  • A user records the minimum viable information needed to begin coordination.
  • Validate that a responsible owner and due date are present before saving.
  • Allow optional structured fields for visit date, source provider, and journey type.
  • If data is incomplete, save as draft and clearly show missing required fields.

2. Assign the Next Steps

  • The system converts the case into one or more actionable steps.
  • Suggest default tasks from the chosen workflow template.
  • Let the operator adjust timing, ownership, and reminder cadence.
  • If a task is duplicated, warn the user and offer to merge it.

3. Notify and Track

  • The product sends reminders and shows whether the next step is moving.
  • Send notifications through configured channels with plain-language message templates.
  • Show delivery status for each reminder when available.
  • If a message fails, surface a retry path and fallback channel suggestion.

4. Escalate When Stuck

  • Overdue or blocked items are surfaced so nothing quietly disappears.
  • Trigger escalation based on configurable time thresholds by workflow.
  • Require a reason when marking a task blocked.
  • Show a stalled-case queue sorted by age and business impact.

5. Close and Learn

  • Once the workflow is done, the case becomes a source of reusable learning.
  • Capture completion reason, total duration, and manual interventions used.
  • Ask a short structured review of what made the case easy or hard.
  • Allow conversion of a successful journey into a reusable template update.

Advanced and Edge Features

  • Template versioning so customers can keep existing cases on the old workflow while new cases use the updated one.
  • Bulk import of active follow-up cases from CSV or spreadsheet.
  • Multi-owner cases where a clinic, family member, and coordinator each have different responsibilities.
  • Read-only client portal for status visibility without editing rights.
  • SLA-based dashboards for supervisors managing multiple coordinators.
  • Exception handling for reschedules, no-shows, unreachable contacts, and missing documents.

Simple, Trustworthy Interface

  • Use a calm, medical-adjacent visual system with clear status colors and no noisy gamification.
  • Keep the default view as a work queue with today, overdue, and blocked items visible first.
  • Design for mobile-first execution because many updates happen from WhatsApp or during calls.
  • Use large tap targets, readable typography, and high contrast for accessibility.
  • Optimize for low cognitive load: one case, one next action, one owner, one deadline.
  • Show audit history and reminders in a compact timeline so trust is visible at a glance.

Ana runs operations for a small clinic and spends her day chasing post-visit tasks that slip between consultation, exam booking, and patient follow-up. She knows the clinic is losing revenue and trust when people do not return, but her current process is a spreadsheet, scattered notes, and repeated WhatsApp messages.

With CarePilot, Ana creates a follow-up case in minutes, assigns the next steps, and lets reminders go out automatically. When a task stalls, she sees it immediately and can intervene before it becomes a lost opportunity.

After a few weeks, Ana notices fewer missed follow-ups, faster completion times, and less manual chasing. The clinic gets more return visits, the team works from a shared workflow, and CarePilot earns recurring revenue from a problem that is now repeatable enough to productize further.

User-Centric Metrics

  • At least 80 percent of cases have an owner and due date within 5 minutes of creation.
  • Reduce average time from visit to first follow-up action by 50 percent within 60 days.
  • Cut overdue follow-up tasks by 30 percent for active customers within 8 weeks.
  • Achieve a weekly task completion rate above 85 percent on managed workflows.
  • Reach a user-reported satisfaction score of 8 out of 10 or higher after the second month.

Business Metrics

  • Convert at least 25 percent of qualified discovery calls into a paid pilot.
  • Reach monthly recurring revenue of 5,000 USD within 6 months.
  • Maintain paid customer retention above 70 percent after the first 90 days.
  • Generate at least 20 percent of new opportunities from referrals or direct introductions by month 6.

Technical Metrics

  • Maintain 99.5 percent uptime for the core app and queue experience.
  • Keep median page load under 2 seconds and API response time under 300 ms for common actions.
  • Achieve zero high-severity privacy incidents and complete access logging for all record views.
  • Ensure notification delivery success rate above 95 percent for configured channels.

Tracking Plan

  • track_case_created with workflow type, source, and owner assigned
  • track_task_assigned with due date, priority, and channel
  • track_reminder_sent with delivery status and channel
  • track_task_completed with completion reason and time to close
  • track_case_escalated with escalation rule and age at trigger
  • track_template_used with template version and workflow type
  • track_paid_conversion with plan type, price, and acquisition source

Technical Needs

  • Use a modern web stack such as Next.js with TypeScript for the app shell and React for the UI.
  • Store relational workflow data in PostgreSQL with a schema designed for cases, tasks, contacts, messages, templates, and audit events.
  • Use a queue and scheduled jobs layer such as BullMQ or Cloud Tasks for reminders and escalations.
  • Add authentication with role-based access control for operators, managers, and read-only viewers.
  • Implement structured event logging for every workflow action to support the learning loop.
  • Provide a basic admin settings area for templates, reminder timing, and notification channels.
  • Prepare for AI assistance only in controlled places such as summarizing notes or suggesting task templates, not making clinical decisions.

Integration Points

  • WhatsApp Business API or a provider such as Twilio for customer-facing reminders.
  • Email delivery through SendGrid or Postmark for operational notifications.
  • OAuth or magic-link authentication for simple team access.
  • Google Calendar or Microsoft Outlook Calendar for appointment references if customers request it.
  • Stripe for subscription billing and pilot payments.

Data Storage & Privacy

  • Collect only the minimum necessary personal and health-related data for coordination.
  • Encrypt sensitive data at rest and in transit, with strict role-based access control.
  • Log who viewed or changed each record for auditability.
  • Support data retention rules, deletion requests, and export requests to align with GDPR and CCPA where applicable.
  • Separate operational notes from clinical content and clearly label the product as non-clinical coordination software.

Scalability & Performance

  • Design the system so reminder scheduling and notification sending run asynchronously.
  • Keep the first version optimized for a small number of customers but with clean tenant isolation.
  • Use caching for dashboard summaries to keep the UI fast as task volume grows.
  • Avoid hard dependencies on manual service steps that would block scale later.

Potential Challenges

  • Risk: the buyer may want clinical advice rather than coordination. Mitigation: position the product strictly around operational follow-up and exclude medical recommendations from scope.
  • Risk: privacy concerns may slow adoption. Mitigation: minimize stored PHI, use strong access controls, and provide clear consent and retention policies.
  • Risk: manual delivery could become too labor-intensive. Mitigation: standardize templates early and measure hours per customer weekly.
  • Risk: the first ICP may be too broad. Mitigation: start with one repeatable workflow and one customer type, then expand only after repeated wins.
  • Risk: reminders may create trust issues if poorly timed. Mitigation: give customers control over cadence, channel, and escalation rules, with opt-out handling.

Team & resourcing - Solo founder with 1 full-stack engineer, 1 product designer part-time, and outsourced legal/privacy review as needed.

Phase 1: Discovery and Offer Test · Weeks 1–2

  • Interview script and problem validation notes with at least 10 target users
  • One narrow offer with pricing, landing page, and booking flow
  • Manual delivery workflow using WhatsApp, email, and spreadsheets
  • First paid pilot proposal and revenue tracking sheet

Phase 2: MVP Workflow App · Weeks 3–6

  • Authentication, tenant setup, and role-based access
  • Create case, task queue, reminders, escalation, and audit trail
  • Template-based workflows for one or two high-frequency journeys
  • Basic dashboard and CSV export

Phase 3: Service-as-Software Refinement · Weeks 7–10

  • Notification templates and channel preferences
  • Communication log timeline and blocked-item handling
  • Weekly operational summary and customer-facing status view
  • Instrumentation for usage, completion, retention, and revenue learning

Phase 4: Automation and Productization · Weeks 11–14

  • Rule-based automation for common workflow steps
  • Template versioning and bulk import
  • Improved onboarding and payment flow
  • Decision review on whether to deepen one workflow or expand to adjacent use cases

Paste this into Cursor, Bolt, Lovable, or v0 to start building.

Build a web app called CarePilot for post-visit healthcare coordination. The product helps clinics, care coordinators, and family delegates manage follow-up after consultations, exams, procedures, and referrals. This is not an EMR/EHR and not clinical decision support. Keep the first version narrow: one repeatable follow-up workflow with manual service support first, then light automation.

Core features to build:
1. Multi-tenant auth with roles: operator, manager, read-only viewer.
2. Create and manage follow-up cases with patient/contact name, workflow type, owner, due date, next action, notes, status, and attachments references.
3. Task queue view for today, overdue, blocked, and completed items.
4. Reminder scheduling and escalation rules with async jobs.
5. Communication timeline per case with call notes and message logs.
6. Workflow templates for common journeys and the ability to clone/edit them.
7. Dashboard with completion metrics, overdue counts, and weekly summary.
8. CSV export and audit trail for all record changes.
9. Settings for reminder channels, timing, and template configuration.
10. Payment-ready landing page and a simple subscription/pilot billing flow using Stripe.

Primary screens and flows:
Home dashboard, cases list, case detail, create case modal, task queue, template editor, settings, onboarding, billing, and read-only share view.
User flow: sign up, choose a workflow template, create first case in under 5 minutes, assign owner and due date, send reminders, monitor status, close case, capture learning fields.

Data model:
Organizations, users, roles, contacts/patients, cases, tasks, reminders, communication_events, templates, template_versions, audit_events, billing_subscriptions, and workflow_settings.
Each case belongs to one organization and one workflow template version. Tasks belong to cases and have status, owner, due date, priority, blocked_reason, escalation_level, and completion metadata.

Tech stack:
Next.js App Router, TypeScript, React, Tailwind, shadcn/ui, PostgreSQL, Prisma, NextAuth or Auth.js, BullMQ with Redis for scheduled reminders, Stripe for billing, SendGrid/Postmark for email, Twilio WhatsApp integration, and Zod for validation. Use a clean, calm medical-adjacent UI with mobile-first layouts, accessible contrast, and fast dashboard performance.

Non-functional requirements:
Implement RBAC, audit logging, encryption in transit, tenant isolation, soft delete for sensitive records, and structured analytics events for case creation, task assignment, reminder sent, task completed, escalation, template used, and paid conversion. Keep clinical advice out of scope and clearly label the product as coordination software only.

Build the MVP first with real screens, seeded demo data, and enough polish to onboard a pilot customer. Do not build unnecessary platform abstractions.

Business Idea

# MASTER PROMPT — Discovery + Sales + Delivery + Learning Loop > **Discover → Build → Charge → Deliver → Learn → Ship → Repeat.** > > **Não construir a infraestrutura da saúde da família. Descobrir, uma oferta vendável por vez, qual infraestrutura precisa existir.** > > Esta é a filosofia operacional deste projeto. > > O **Family Longevity OS** representa uma visão de longo prazo: uma possível camada de coordenação contínua da saúde da família. **Não tratá-lo como o produto a ser construído agora.** > > O primeiro produto precisa ser pequeno o suficiente para que eu consiga **vendê-lo e entregá-lo antes de precisar construí-lo**. > > Quero explorar, validar e construir progressivamente uma oportunidade de negócio na área de saúde, começando como um **Service-as-Software** assistido por tecnologia e IA, com potencial de se transformar posteriormente em software e, somente se houver evidência suficiente, em uma infraestrutura mais ampla. > > Sou um founder solo, quero operar de maneira **bootstrapped** e minha filosofia de execução é **sempre estar shipping**: aprender construindo, colocando hipóteses no mercado, cobrando por soluções reais e aceitando abandonar ou modificar rapidamente aquilo que não demonstrar tração. > > Meu objetivo nesta fase não é construir uma plataforma. > > É descobrir: > > **um problema relevante → para um segmento específico → associado a um resultado valioso → pelo qual alguém esteja disposto a pagar → que consiga ser entregue de maneira economicamente sustentável → e que possa progressivamente se tornar mais repetível, automatizado e escalável.** > > Quero construir, desde o início, um **motor de aprendizado de produto e mercado**, no qual cada cliente, venda e entrega aumente meu conhecimento e melhore a próxima iteração. --- ## As lentes que devem orientar o trabalho ### 1. Rob Snyder — Pull Investigar: > **Existe demanda real puxando por essa solução?** Não começar pelaquilo que eu quero construir. Descobrir o que as pessoas já estão tentando resolver, onde existe demanda reprimida e qual trabalho elas estão tentando fazer acontecer. --- ### 2. Ash Maurya — Lean Validation Para cada ciclo: > **Qual é a hipótese mais arriscada?** Encontrar a forma mais barata e rápida de testá-la. Priorizar evidência comportamental sobre opinião. --- ### 3. Mark Pincus — Proven → Better → New Reduzir incerteza nessa ordem: **PROVEN → BETTER → NEW** Começar com comportamentos e soluções que as pessoas já utilizam. Depois melhorar uma parte específica da experiência. Só então introduzir algo realmente novo, como IA ou automação. --- ### 4. Pieter Levels — Build → Charge → Learn Perguntar continuamente: > **Qual é a menor coisa que posso colocar no mercado, cobrar e entregar agora?** Evitar construir uma plataforma antes de conhecer o workflow. Preferir: **microproduto → primeiro cliente → aprendizado → próxima versão** a: **visão ampla → plataforma → desenvolvimento → tentativa de encontrar clientes.** --- ### 5. Learning Loop — transformar experiência em ativo Cada cliente deve gerar: **experiência → conhecimento → padrão → workflow → automação → produto melhor** Não assumir que dados proprietários são automaticamente um moat. O moat somente começa a existir se o aprendizado acumulado: * melhorar o resultado; * reduzir o custo de entrega; * aumentar velocidade; * melhorar conversão; * aumentar retenção; * e ficar progressivamente difícil de reproduzir. --- # 1. Começar pelo problema, não pela solução A hipótese inicial é que existe um trabalho importante de continuidade entre uma interação de saúde e outra — depois de consulta, exame, procedimento, encaminhamento ou recomendação — e que parte desse trabalho pode ficar sem um dono claro. **Não assumir que isso é verdade.** Investigar jornadas reais: * O que acontece depois? * O que precisa acontecer? * Quem faz? * Quem lembra? * Quem agenda? * Quem acompanha? * Quem comunica? * Quem cobra? * Quem percebe que algo não aconteceu? * Quem assume a responsabilidade quando a jornada quebra? --- # 2. Descobrir o ICP pelo comportamento Não assumir previamente: * família; * paciente complexo; * idoso; * paciente crônico; * especialista; * clínica; * profissional liberal. São hipóteses. Identificar: **Quem sente → quem faz → quem decide → quem paga → quem se beneficia.** Priorizar combinações de: **dor + frequência + consequência + urgência + capacidade de pagamento + acessibilidade + possibilidade de repetição.** --- # 3. Descobrir o “Oz” Descobrir o resultado que o cliente realmente compra. Não assumir que seja: * coordenação; * longevidade; * prevenção; * tranquilidade; * organização. Perguntar: * O que ele está tentando conseguir? * O que gostaria que deixasse de ser um problema? * O que já tentou? * Por que não funcionou? * O que gostaria de delegar? * O que mudaria concretamente? * Quanto esse resultado vale? --- # 4. Mapear o trabalho invisível Observar: * tarefas; * informações; * decisões; * documentos; * comunicação; * agendamentos; * lembretes; * dependências; * exceções; * handoffs; * atrasos; * retrabalho; * responsabilidades. Não assumir que todo trabalho observado deve virar produto. Descobrir: > **Qual trabalho vale a pena assumir?** --- # 5. Descobrir o que pode ser delegado Investigar: **delegação × controle × visibilidade × confiança × responsabilidade** O que o cliente quer: * delegar; * manter sob controle; * apenas acompanhar; * automatizar; * resolver com uma pessoa? Considerar conflitos entre: **paciente ↔ familiar ↔ cuidador ↔ especialista.** --- # 6. Criar a menor oferta vendável Antes de pensar em plataforma: > **Qual é a menor solução que alguém pode comprar esta semana?** Ela deve poder ser: **explicada → vendida → entregue → medida → melhorada.** A visão pode ser grande. A primeira oferta deve ser pequena. --- # 7. Cobrar cedo Não considerar como validação suficiente: * elogios; * curtidas; * cadastros; * “eu usaria”; * “isso é necessário”. Buscar: **compromisso → pagamento → resultado.** Uma venda não prova Product-Market Fit. Mas fornece evidência muito mais forte que uma opinião. --- # 8. Construir o motor comercial durante o Discovery Não separar: **Discovery → depois Sales → depois Growth.** Construir simultaneamente: **ICP → mensagem → canal → conversa → oferta → venda → onboarding → entrega → prova → indicação.** Cada venda deve gerar: **receita + aprendizado sobre o problema + aprendizado sobre o mercado.** --- # 9. Service-as-Software antes de Software Começar utilizando: * humano; * WhatsApp; * IA; * ferramentas existentes; * automações simples; * documentos; * workflows manuais. Descobrir: **manual → repetível → padronizado → automatizado → software.** Não construir software apenas porque a solução final parece tecnológica. --- # 10. “No Platform Yet” Durante a fase inicial: > **presumir que não precisamos de uma plataforma.** Uma plataforma só ganha justificativa quando houver: **frequência + repetição + valor + disposição de pagamento + workflow conhecido + necessidade real de software.** --- # 11. Sempre estar shipping Shipping não significa necessariamente lançar código. Pode significar lançar: * uma mensagem; * uma oferta; * uma landing page; * um piloto; * uma venda; * um workflow; * uma automação; * uma nova versão do serviço. A meta é reduzir: > **tempo entre hipótese → mercado → evidência → decisão.** --- # 12. Revenue Learning Registrar: * quem pagou; * quanto pagou; * por que comprou; * qual alternativa utilizava; * o que tornou a oferta valiosa; * o que quase impediu a compra; * se compraria novamente; * se indicaria alguém. Cada venda deve gerar: **dinheiro + informação + relacionamento + evidência.** --- # 13. Learning Loop como moat potencial Transformar: **experiência → dados estruturados → padrões → playbooks → workflows → automações → produto.** O objetivo não é simplesmente acumular dados. É acumular **conhecimento operacional proprietário sobre como resolver determinadas jornadas melhor e com menor custo**. Perguntar constantemente: > **O próximo cliente está ficando mais fácil, rápido e barato de atender por causa do que aprendemos com os anteriores?** Se não estiver, o suposto Learning Loop ainda não está funcionando. --- # 14. Saúde exige uma regra adicional > **Ship fast, don't break trust.** Experimentar rapidamente em: * mensagens; * ofertas; * canais; * workflows; * aquisição; * operação. Ser extremamente cuidadoso com: * dados sensíveis; * privacidade; * consentimento; * segurança; * responsabilidade; * decisões clínicas; * recomendações automatizadas. Separar claramente: **coordenação operacional ≠ decisão clínica.** --- # 15. Reduzir a maior incerteza primeiro Para cada ciclo, mapear: * problema; * ICP; * early adopter; * frequência; * urgência; * Oz; * delegabilidade; * disposição de pagamento; * canal; * oferta; * recorrência; * margem; * operação; * automação; * retenção; * indicação; * defensibilidade. Então perguntar: > **Qual é o menor experimento que pode eliminar a maior incerteza?** Regras: > **Não construir quando uma conversa pode responder.** > **Não entrevistar quando uma venda pode responder.** > **Não vender quando uma entrega real pode responder melhor.** > **Não escalar quando ainda não existe repetibilidade.** --- # 16. Critérios para avançar ### Problem Fit O problema existe? ### Solution Fit A oferta resolve algo importante? ### Commercial Fit Pessoas semelhantes compram por razões semelhantes? ### Delivery Fit Consigo entregar com economia? ### Repeatability Consigo encontrar, vender e atender novamente? ### Productization Existem workflows repetitivos que justificam software? ### Growth Existe algo previsível para amplificar? --- # 17. Output obrigatório de cada ciclo Para cada experimento, produzir: **Hipótese** O que estamos tentando descobrir? **Evidência** O que aconteceu de fato? **Product Learning** O que aprendemos sobre o produto? **Revenue Learning** O que aprendemos sobre o mercado e pagamento? **Shipping** O que colocamos no mundo? **Decisão** Persistir, ajustar, pivotar ou abandonar? **Learning Loop** Que conhecimento reutilizável foi criado? **Próximo experimento** Qual ação reduz mais a próxima incerteza? **Capital at Risk** Quanto tempo, dinheiro e complexidade estamos colocando em risco? --- # Regra de ouro > **Não quero que você tente provar que minha ideia é boa.** > > Quero que seja intelectualmente adversarial. > > Se a evidência mostrar que o problema não é relevante, o ICP está errado, o Oz é diferente, ninguém quer delegar, ninguém quer pagar, a oferta não entrega resultado, o canal não é repetível, a operação não tem margem, o software não é necessário ou o suposto moat não existe, diga isso claramente. > > **O objetivo não é proteger a tese. É descobrir, com o menor capital possível, um problema valioso, um cliente disposto a pagar e um mecanismo repetível de entregar e vender o resultado.** --- ### A frase que passa a comandar todo o projeto **Discover → Build → Charge → Deliver → Learn → Ship → Repeat.** E a regra estratégica: > **Não construir a infraestrutura da saúde da família. Descobrir, uma oferta vendável por vez, qual infraestrutura precisa existir.** Essa é a versão que eu usaria agora. Ela mantém a **visão de longo prazo**, mas impede que a visão determine prematuramente o produto, o ICP, o modelo de software ou a arquitetura da solução.

Make My PRD

Design by The Resonance | Powered by GPC – The AI Transformation Company