CareLoop

Turn fragmented care tasks into one managed follow-through service.

CareLoop is a service-assisted care coordination product for people who need important actions to happen after a health encounter: scheduling, reminders, document collection, handoffs, follow-up messages, and progress checks. It starts as a human-led service with WhatsApp, AI, and lightweight workflows, then learns which repeated tasks, customer segments, and outcomes justify productization.

Business Goals

  • Within 90 days, validate at least 3 distinct problem segments with 30 to 50 paid conversations and 5 to 10 paying pilot customers.
  • Reach 60 percent conversion from qualified discovery conversations to paid pilot offers among the top two ICP segments.
  • Achieve at least 40 percent of pilot customers continuing into a second month or second case within 60 days.
  • Keep gross margin at or above 50 percent on manually delivered cases by standardizing the top 3 recurring workflows.
  • Identify one repeatable acquisition channel that generates at least 10 qualified leads per month with a cost per lead below 15 percent of average first-month revenue.

User Goals

  • Reduce missed follow-ups, forgotten appointments, and uncompleted next steps after healthcare interactions.
  • Make it clear who is responsible for each next action and when it should happen.
  • Save patients, families, or clinics time spent on reminders, coordination, and repeated communication.
  • Provide visible progress status so users know what is done, pending, blocked, or escalated.
  • Escalate only when a human decision or intervention is truly needed.

Non-Goals

  • Do not provide medical diagnosis, treatment recommendations, or clinical decision-making.
  • Do not build a broad consumer health platform or patient portal before proving one repeatable workflow.
  • Do not automate high-risk decisions without explicit human supervision and consent.
  • Do not optimize for mass-market growth until a repeatable paid workflow is proven.

Family Caregiver Ana, 38 - Ana coordinates care for her father who sees multiple specialists. She is overloaded by reminders, tests, referrals, and message chains across family and clinics.

Family Caregiver Ana, 38

  • As a family caregiver, I want every next step after an appointment captured in one place, so that I do not have to remember it all myself.
  • As a caregiver, I want reminders and follow-ups sent automatically when appropriate, so that tasks do not slip through gaps.
  • As a caregiver, I want to know when something is blocked or overdue, so that I can intervene only when necessary.

Clinic Coordinator Bruno, 32 - Bruno works in a small specialty clinic and spends time chasing patients for documents, confirmations, and follow-up attendance. He needs fewer no-shows and less manual back-and-forth.

Clinic Coordinator Bruno, 32

  • As a clinic coordinator, I want to delegate post-visit follow-up tasks to a structured workflow, so that I can focus on exceptions.
  • As a coordinator, I want visibility into which patients have not completed required steps, so that I can prioritize outreach.
  • As a coordinator, I want to reuse templates for repeated cases, so that operations become faster and more consistent.

Self-Managing Patient Luiza, 55 - Luiza has a chronic condition and sees multiple providers. She wants to stay on top of care without feeling like she is managing a part-time job.

Self-Managing Patient Luiza, 55

  • As a patient, I want to see the next actions after each health interaction, so that I know exactly what to do next.
  • As a patient, I want help coordinating documents, appointments, and reminders, so that I can reduce stress and avoid mistakes.
  • As a patient, I want to know when a human needs to step in, so that I can trust the service without losing control.

Intake and Case Setup · High priority

  • Capture the post-health interaction workflow, the people involved, the expected next steps, and the desired outcome in a structured case record.
  • Create a case from WhatsApp, web form, or internal operator input in under 5 minutes.
  • Support fields for patient, caregiver, clinic, specialist, deadlines, documents, and desired outcome.
  • Allow the operator to tag case type such as referral, exam prep, follow-up, medication adherence, or billing follow-up.
  • Detect missing critical information and flag the case before work starts.
  • Store consent and role relationships for each participant.

Task Orchestration and Follow-Through · High priority

  • Track, assign, and execute the invisible work that keeps a care journey moving after the initial healthcare interaction.
  • Generate task lists with due dates, owners, dependencies, and escalation rules.
  • Send reminders via WhatsApp and email based on task state and urgency.
  • Support manual status changes such as done, waiting, blocked, and needs human review.
  • Surface overdue and abandoned tasks in an operator dashboard.
  • Allow tasks to be repeated across cases with templates.

Communication Hub · High priority

  • Centralize patient, family, and clinic communication without replacing clinical judgment.
  • Log inbound and outbound messages in a unified timeline.
  • Use templated messages for confirmations, reminders, and document requests.
  • Support human approval before any message that could be clinically sensitive.
  • Route questions requiring clinical judgment to a designated human reviewer.
  • Keep an audit trail of who sent what and when.

AI Assist and Pattern Learning · Medium priority

  • Use AI to summarize conversations, extract tasks, classify issue types, and suggest next actions while keeping humans in control.
  • Summarize long WhatsApp threads into concise case notes.
  • Extract entities such as dates, names, specialty, and instructions from messages and documents.
  • Suggest the next best operational action based on prior resolved cases.
  • Flag uncertainty so the operator can confirm or correct AI output.
  • Capture structured reasons for failure, delay, or completion to build the learning loop.

Payments, Proof, and Reporting · Medium priority

  • Support paid pilots, track outcomes, and produce proof that the service creates value worth paying for.
  • Record service plan, price, invoice status, and payment confirmation.
  • Show whether the desired outcome was achieved, partially achieved, or not achieved.
  • Generate case summaries for sales follow-up and referral requests.
  • Track whether the customer returns for another case or recommends another client.
  • Export data for manual review and analysis by the founder.

From First Contact to Active Case

  • User arrives via referral, WhatsApp, or landing page and selects the health situation they need help with.
  • They answer 5 to 7 structured questions to define the current interaction, the next action, and who is involved.
  • The system shows a clear service promise, expected turnaround, and price before work begins.
  • A human operator confirms scope, consent, and ownership within 15 minutes during business hours.
  • The user receives the first action summary and task timeline within 30 minutes of activation.
  • A live status page and WhatsApp thread show what is done, pending, blocked, and next.

1. Capture the case

  • Convert an incoming message or referral into a structured care follow-through case.
  • Collect the interaction type, participants, deadlines, and desired result.
  • Validate required fields and ask for missing details before the case is opened.
  • If the case is outside scope or clinically unsafe, route to a human decline flow.

2. Define the outcome

  • Translate the user’s pain into a concrete outcome that can be bought and delivered.
  • Ask what would make this problem stop being a problem.
  • Present a simple service option and price tied to that outcome.
  • Record objections, urgency, and who controls the decision.

3. Plan the work

  • Break the outcome into operational tasks, dependencies, and ownership.
  • Assign tasks to patient, family, clinic, or operator.
  • Set reminders, deadlines, and escalation rules.
  • Mark tasks requiring clinical judgment for human review only.

4. Execute and monitor

  • Carry out reminders, updates, and follow-ups through WhatsApp and operator actions.
  • Send the right message at the right time using approved templates.
  • Track task completion and blocked states in real time.
  • Escalate if no response arrives after configurable thresholds.

5. Close and learn

  • Measure whether the intended result happened and convert the case into reusable learning.
  • Ask if the target outcome was achieved and how long it took.
  • Capture reasons for delay, abandonment, or satisfaction.
  • Offer continuation, second case support, or referral only after outcome review.

Power Features and Edge Cases

  • Case templates for recurring journeys such as referral completion, exam preparation, post-procedure follow-up, and specialist handoff.
  • Multi-party permissioning for patient, caregiver, and clinic roles with consent tracking.
  • Escalation rules for no-response, deadline risk, document missing, and clinical uncertainty.
  • Outcome library to compare which segments pay for which results.
  • Operator playbooks that show the next best action for common exceptions.
  • Manual override for urgent or ambiguous cases that need human judgment.

Clear, Calm, and Exception-Driven UI

  • A timeline-first layout that emphasizes next action, owner, and due date.
  • Strong status colors for done, pending, blocked, and escalated, with text labels for accessibility.
  • Mobile-first WhatsApp-centered design for founders and users who operate on the phone.
  • Fast loading even on low bandwidth, with minimal screens and short forms.
  • Readable type, large tap targets, and high contrast to support older users and stressed caregivers.

Ana keeps missing follow-up steps after her father’s specialist visits. She receives instructions by message, paper, and memory, but no one owns the coordination between appointments. The result is anxiety, delays, and repeated calls to the clinic.

With CareLoop, Ana opens a case in WhatsApp, answers a few questions, and gets a clear next-step plan within minutes. The service reminds the right person, tracks missing documents, and escalates only when something is blocked. Ana buys less chaos, the clinic gets fewer avoidable follow-ups, and the team learns which workflows are repeatable enough to standardize.

User-Centric Metrics

  • At least 80 percent of active cases have a clear next owner within 10 minutes of intake.
  • At least 70 percent of cases achieve the intended follow-through outcome or a documented reason for failure.
  • Reduce missed next-step actions by 30 percent versus the user’s baseline process within 60 days.
  • Average user-reported stress score improves by 2 points on a 5-point scale after first completed case.
  • At least 50 percent of users say they would delegate the same workflow again.

Business Metrics

  • Convert at least 25 percent of discovery conversations into paid pilots within 90 days.
  • Reach at least 40 percent repeat purchase or second-case usage within 60 days.
  • Generate at least 20 percent of new leads through referrals by month 4.
  • Maintain at least 50 percent gross margin after standardizing top workflows.
  • Identify one segment with a customer acquisition payback period under 30 days.

Technical Metrics

  • Achieve 99.5 percent uptime for core intake, messaging, and status tracking services.
  • Keep median page load under 2 seconds on mobile devices.
  • Ensure all sensitive data access is logged and auditable.
  • Maintain zero known P1 incidents involving unauthorized disclosure of health-related data.

Tracking Plan

  • Track case_created when a new journey is opened.
  • Track case_qualified when the problem, owner, and desired outcome are confirmed.
  • Track offer_presented when a price and service scope are shown.
  • Track payment_received when a paid pilot starts.
  • Track task_completed for every operational step in the case.
  • Track escalation_triggered when a human review is required.
  • Track outcome_confirmed when the customer marks the result achieved or not achieved.

Technical Needs

  • Next.js or React frontend for a fast mobile-first experience.
  • Node.js backend with a simple workflow engine and queue-based job processing.
  • PostgreSQL for structured case, task, consent, and outcome data.
  • Redis or a managed queue such as BullMQ for reminders and scheduled follow-ups.
  • OpenAI or similar LLM API for summarization, extraction, and classification with human review gates.
  • Twilio WhatsApp API for messaging and delivery receipts.
  • A lightweight admin dashboard for operators and founder analytics.

Integration Points

  • Twilio WhatsApp and SMS for user communication.
  • Google Calendar or Outlook Calendar for appointment visibility where permitted.
  • Stripe for pilot payments and invoicing.
  • Gmail or Outlook email for document and follow-up communication.
  • Google Drive or Dropbox for secure document storage links.

Data Storage & Privacy

  • Store only the minimum necessary health-related data required to deliver the service.
  • Collect explicit consent from the patient or legal representative before processing sensitive information.
  • Separate operational notes from clinical content and mark any clinical references as human-reviewed only.
  • Provide deletion and export workflows aligned with GDPR and CCPA expectations where applicable.
  • Encrypt data in transit and at rest, and maintain role-based access control with audit logs.

Scalability & Performance

  • Design reminders and workflow steps to run asynchronously so the app remains responsive.
  • Keep the first version optimized for tens to low hundreds of active cases, not mass consumer traffic.
  • Cache case timelines and task lists to reduce repeated reads from the database.
  • Use rate limiting and retries for messaging providers to avoid missed reminders during spikes.

Potential Challenges

  • Risk: ambiguous boundary between operational support and clinical advice. Mitigation: define strict human review rules and approved message templates.
  • Risk: users may want full coordination but resist paying. Mitigation: test small paid offers tied to one painful outcome, not broad subscriptions.
  • Risk: each case may be too custom to scale. Mitigation: identify repeated case archetypes and standardize only the top patterns.
  • Risk: WhatsApp workflows can become messy across many participants. Mitigation: enforce structured status updates and a single source of truth dashboard.
  • Risk: privacy and trust concerns can block adoption. Mitigation: use explicit consent, transparent data handling, and short retention policies.

Team & resourcing - Solo founder with 1 full-stack engineer contractor, part-time ops support, and optionally a fractional designer

Phase 1: Problem and Offer Validation · Weeks 1-3

  • Landing page with one narrow service offer and one WhatsApp entry point
  • Discovery script and qualification checklist
  • Manual case intake form
  • First 5 to 10 paid pilot conversations
  • Basic tracking for source, objections, payment, and outcome

Phase 2: Concierge MVP · Weeks 4-8

  • Operator dashboard for cases, tasks, and statuses
  • WhatsApp message templates and reminder scheduling
  • Consent capture and role assignment
  • Simple payment flow through Stripe
  • Outcome review form and referral request flow

Phase 3: Repeatable Workflow System · Weeks 9-14

  • Reusable case templates for the top 2 to 3 recurring workflows
  • AI-assisted summarization and task extraction with human approval
  • Case timeline, escalation rules, and audit log
  • Founder analytics for conversion, delivery effort, and retention
  • First version of playbooks for delivery and sales

Phase 4: Productization Readiness · Weeks 15-20

  • Self-serve intake for the most repeatable segment
  • Improved automation for reminders and follow-up
  • Basic segmentation and cohort reporting
  • Decision criteria for what to automate versus keep manual
  • Plan for the first software module based on proven repeated workflow

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

Build a mobile-first service-assisted healthcare follow-through app called CareLoop.

Goal: help a solo founder run a concierge care coordination service that manages the work between healthcare interactions: reminders, follow-ups, appointment prep, document collection, handoffs, status tracking, and escalation. This is not a medical advice app. The system must separate operational coordination from clinical decision-making and require human review for anything clinically sensitive.

Core users:
1. Family caregiver
2. Patient
3. Clinic coordinator / operator

Primary workflows:
1. Intake a new case from WhatsApp or web form
2. Capture patient, caregiver, clinic, interaction type, deadlines, desired outcome, consent, and roles
3. Generate a task plan with owners, due dates, dependencies, and escalation rules
4. Send reminders and status updates through WhatsApp and email
5. Track case timeline, task status, messages, payment, and outcome
6. Close the case with outcome confirmation, notes, and referral prompt

Build screens:
1. Public landing page with one clear offer and CTA to start on WhatsApp
2. Intake form with validation and consent capture
3. Operator dashboard with case list, filters, and SLA warnings
4. Case detail page with timeline, tasks, messages, documents, status, and escalation controls
5. Simple analytics page for conversion, delivery effort, outcomes, and repeat usage

Data model:
User, Case, Participant, Consent, Task, Message, Document, Payment, Outcome, Escalation, Template, AuditLog

Requirements:
Use Next.js, TypeScript, Tailwind, PostgreSQL, and Prisma. Use Twilio WhatsApp API for messaging, Stripe for payments, and OpenAI API for summarization and task extraction with a human approval step. Add a queue for scheduled reminders and retries. Include authentication for operators, role-based access, audit logs, and soft delete for sensitive records. Make the UI clean, calm, mobile-first, and accessible.

Important behaviors:
If required intake data is missing, block case creation and ask for the missing field.
If a task is overdue or blocked, escalate to a human operator.
If a message or action could be clinical advice, route it to manual review.
Store minimal necessary health-related data, encrypt sensitive fields, and keep a full audit trail.

Deliver an MVP that is production-shaped but simple: easy to run, easy to extend, and focused on manual service delivery first. Include seed data, sample templates for common follow-up workflows, and a README with setup instructions.

Business Idea

Quero explorar, validar e construir progressivamente uma oportunidade de negócio na área de saúde, começando como um serviço assistido por tecnologia e IA, com potencial de se transformar posteriormente em software e, se houver evidência suficiente, em uma infraestrutura mais ampla. Meu objetivo nesta fase não é construir uma plataforma nem validar uma solução pré-concebida. É descobrir um problema economicamente relevante, identificar quem realmente o possui, entender o resultado que essas pessoas desejam alcançar e construir, desde o início, um motor de aprendizado comercial e de produto que possa se tornar progressivamente mais previsível. Sou um founder solo e quero operar de maneira bootstrapped. Portanto, cada ciclo deve buscar simultaneamente: aprender → vender → entregar → medir → melhorar → vender novamente. Não quero separar artificialmente “Discovery”, “Sales”, “Product” e “Growth” em fases isoladas. 1. Começar pelo problema, não pela solução A hipótese inicial é que existe um trabalho importante de continuidade que acontece entre uma interação de saúde e outra — depois de uma consulta, exame, procedimento, encaminhamento ou recomendação — e que parte desse trabalho pode ficar sem um dono claro, recaindo sobre pacientes, familiares ou profissionais. Não assuma que essa hipótese é verdadeira. Quero investigá-la através de jornadas reais.
 Descobrir: * O que acontece depois que uma interação de saúde termina? * O que precisa acontecer para que o cuidado continue? * Quem faz esse trabalho hoje? * Quem lembra? * Quem agenda? * Quem acompanha? * Quem comunica? * Quem cobra? * Quem percebe quando algo não acontece? * Quem assume a responsabilidade quando a jornada quebra?
 Quero descobrir se existe um trabalho relevante, recorrente e mal resolvido nesse espaço. 2. Descobrir o ICP a partir do comportamento Não assumir antecipadamente que o ICP é: * famílias; * pacientes complexos; * idosos; * pessoas com doenças crônicas; * pacientes multidisciplinares; * classe média/alta; * especialistas; * clínicas.
 Esses são segmentos possíveis, não conclusões. Para cada jornada investigada, identificar: Quem sente → quem faz → quem decide → quem paga → quem se beneficia. Procurar especialmente situações em que exista uma combinação de: * frequência; * consequência relevante; * esforço; * frustração; * risco; * custo financeiro; * dependência de outras pessoas; * dificuldade de coordenação; * ausência de uma solução satisfatória.
 O objetivo é encontrar o segmento em que a dor e a disposição para agir sejam maiores. 3. Descobrir o “Oz” Antes de definir o produto, descobrir qual é o resultado que o cliente realmente deseja alcançar — seu “Oz”. Não assumir que esse resultado seja: “coordenação”, “longevidade”, “prevenção”, “tranquilidade”, “autonomia” ou “organização”.
 Investigar: * O que a pessoa está tentando conseguir? * O que ela gostaria que simplesmente deixasse de ser um problema? * O que ela já tentou? * Por que não funcionou? * Que trabalho ela gostaria de deixar de carregar? * O que mudaria concretamente em sua vida? * Quanto esse resultado vale?
 O produto deve ser construído em torno do resultado comprado, não da tecnologia utilizada para produzi-lo. 4. Mapear o trabalho invisível Quero observar o trabalho que atualmente não aparece como “produto”, mas precisa acontecer para que o resultado seja alcançado. Mapear: * tarefas; * informações; * decisões; * documentos; * comunicações; * agendamentos; * lembretes; * dependências; * exceções; * handoffs; * atrasos; * retrabalho; * responsabilidades; * pontos de abandono.
 Não assumir que esse trabalho necessariamente pertence ao meu futuro produto.
 O objetivo é descobrir qual trabalho vale a pena assumir. 5. Descobrir o que pode ser delegado Investigar a relação entre delegação, controle, visibilidade, confiança e responsabilidade. Perguntar: * O que a pessoa gostaria de delegar? * O que ela não delegaria? * O que precisa continuar sob seu controle? * O que precisa ser comunicado a ela? * O que pode ser resolvido sem sua intervenção? * Quando ela exige uma pessoa? * Quando aceitaria automação?
 Considerar também possíveis conflitos entre: paciente ↔ familiar ↔ cuidador ↔ especialista ↔ clínica. Não assumir que esses atores possuem os mesmos incentivos. 6. Tratar a venda como parte do Discovery Não separar Discovery de Sales. Cada conversa comercial deve simultaneamente produzir: receita + aprendizado sobre o problema + aprendizado sobre o mercado. Quero testar progressivamente: atenção → conversa → interesse → compromisso → pagamento → resultado → continuidade → indicação. Não considerar como validação suficiente: * elogios; * curtidas; * respostas positivas; * cadastro; * “eu usaria”; * “isso é muito necessário”.
 Dar maior peso a comportamentos que envolvam tempo, esforço, acesso, indicação ou dinheiro. 7. Começar construindo a máquina comercial Quero começar a construir, desde o Discovery, os componentes de uma futura máquina previsível de aquisição e vendas. Em cada ciclo, investigar: ICP → mensagem → canal → conversa → oferta → venda → onboarding → entrega → prova → indicação. Para cada etapa, registrar: * qual hipótese está sendo testada; * qual experimento foi executado; * quantas pessoas foram expostas; * quantas responderam; * quais objeções apareceram; * quantas avançaram; * quantas pagaram; * por que compraram; * por que não compraram; * qual resultado obtiveram; * quais clientes indicaram outras pessoas.
 O objetivo inicial não é escalar aquisição. É descobrir quais componentes de uma máquina comercial são repetíveis. 8. Não fazer Growth antes de existir algo para amplificar Não recomendar escala prematuramente. Primeiro buscar evidência de uma combinação repetível de: ICP + problema + Oz + oferta + canal + conversão + entrega + continuidade. Somente depois aumentar investimento em aquisição, automação ou mídia. Growth, nesta fase, significa principalmente: aumentar a velocidade de aprendizado e encontrar padrões de repetição. 9. Começar como Service-as-Software Se houver evidência de demanda, começar com um serviço assistido. Utilizar: * operação humana; * WhatsApp; * ferramentas existentes; * automações simples; * IA; * documentos; * workflows manuais.
 Não construir software para substituir um workflow que ainda não compreendemos. Primeiro descobrir: o que funciona manualmente → o que se repete → o que pode ser padronizado → o que pode ser automatizado → o que merece virar software. 10. Proven → Better → New Aplicar deliberadamente: PROVEN Começar com comportamentos, canais, ferramentas e processos que as pessoas já utilizam. BETTER Tornar uma parte específica desse trabalho significativamente melhor e entregar um resultado pelo qual alguém esteja disposto a pagar. NEW Introduzir IA, automação ou novos mecanismos apenas quando houver evidência de que eles criam valor adicional. Não usar tecnologia como justificativa para criar demanda. A sequência deve ser: Proven → Better → aprendizado → New. 11. Construir o Learning Loop Cada jornada entregue deve aumentar nosso conhecimento sobre: * problemas; * workflows; * exceções; * decisões; * dependências; * linguagem dos clientes; * objeções; * resultados; * custo de entrega; * tempo humano; * padrões de comportamento. Transformar progressivamente esse aprendizado em: playbooks → workflows → automações → modelos de decisão operacional → produto. Não assumir que “dados proprietários” são automaticamente um moat. Testar se o conhecimento acumulado realmente: 1. melhora o resultado; 2. reduz o custo de entrega; 3. aumenta a velocidade; 4. melhora a conversão; 5. aumenta retenção; 6. é difícil de replicar. 12. Separar operação administrativa de decisão clínica O serviço pode organizar, acompanhar e facilitar processos, mas não deve substituir julgamento clínico. Diferenciar claramente: coordenação operacional de decisão clínica. Sempre que uma atividade atravessar essa fronteira, identificar: * responsabilidade; * necessidade de supervisão humana; * consentimento; * governança; * risco regulatório; * privacidade e proteção dos dados. 13. Reduzir a maior incerteza primeiro Para cada ciclo, listar as hipóteses críticas: * problema; * ICP; * early adopter; * frequência; * urgência; * Oz; * delegabilidade; * disposição de pagamento; * canal; * oferta; * recorrência; * economia; * operação; * automação; * retenção; * indicação; * defensibilidade. Ordená-las por risco × impacto. Depois propor o menor experimento capaz de gerar evidência. 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. 14. Trabalhar em ciclos curtos de sempre shipping Cada ciclo deve produzir alguma coisa no mundo real. Pode ser: * uma nova mensagem; * uma landing page; * uma oferta; * uma entrevista; * uma venda; * um piloto; * uma entrega; * um workflow; * uma automação; * uma nova versão do serviço. O princípio é: shippar hipóteses, não apenas software. Depois de cada ciclo: observar → medir → aprender → atualizar hipóteses → decidir o próximo experimento. 15. Critério de passagem de fase Não considerar que existe Product-Market Fit simplesmente porque algumas pessoas compraram. Procurar evidências progressivas: Problem Fit Pessoas reconhecem o problema e já tentam resolvê-lo. Solution Fit Uma oferta específica produz valor real. Commercial Fit Pessoas semelhantes compram por razões semelhantes. Delivery Fit O resultado pode ser entregue de maneira economicamente sustentável. Repeatability Existe um processo razoavelmente repetível de encontrar, vender e atender clientes. Productization Os workflows repetidos começam a justificar software e automação. Growth Existe algo suficientemente repetível para ser amplificado. Não pular etapas apenas porque a tecnologia permite. 16. Output esperado de cada ciclo Ao analisar qualquer experimento, apresentar: 1. Hipótese
O que estamos tentando descobrir? 2. Evidência
O que realmente aconteceu? 3. Aprendizado
O que mudou em nossa compreensão? 4. Decisão
Persistir, ajustar, pivotar ou abandonar? 5. Impacto comercial
Isso aumenta nossa capacidade de encontrar, vender ou reter clientes? 6. Impacto no produto
Isso revela algo que devemos manter manual, padronizar ou automatizar? 7. Learning Loop
Que conhecimento novo foi acumulado? 8. Próximo experimento
Qual é a menor ação que mais reduz a próxima incerteza? Regra fundamental Não quero que você tente provar que minha ideia é boa. Quero que você seja intelectualmente adversarial com ela. Se a evidência indicar que: * o problema não é relevante; * o ICP está errado; * o Oz é diferente; * ninguém quer delegar; * ninguém quer pagar; * o serviço não gera margem; * o canal não é repetível; * ou o suposto moat não existe; diga isso claramente. O objetivo não é preservar a tese original. É 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. Onde esse prompt coloca a minha idéia agora?
 Eu classificaria esse estágio como: Problem Discovery + Commercial Discovery, caminhando para Problem/Solution Fit. E não chamaria ainda de “GTM” no sentido de escala. Meu primeiro GTM experimental já pode começar, porém: 5–10 clientes reais, uma oferta real, dinheiro real e entrega real. A diferença é crucial: Não estou construindo uma máquina de Growth. Estou construindo e calibrando o protótipo da máquina de Growth enquanto descobre o produto. Para um founder solo/bootstrapped, considero essa abordagem muito mais coerente do que passar meses fazendo Discovery e só depois descobrir que não sabe vender o que construiu.

Make My PRD

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

    PRD: Quero explorar, validar e construir progressivamente uma...