Decisão antes do código
Uma decisão antes de qualquer código.
Para um produto novo que se enquadre: avançar, reformular ou recusar — por escrito, fundamentada, no prazo de 48 horas em dias úteis. Antes de qualquer código.
Quem a toma é o nosso CEO, Mark Prais. Não é vendida e não é um relatório: é a nossa decisão de assumir ou não o seu produto, tomada antes de qualquer uma das partes investir dinheiro.
A carta
Uma carta assinada pelo nosso CEO.
48 horas em dias úteisapós a conversa inicial
A decisão, as principais razões e o passo seguinte, numa página. A investigação fica connosco.
IdeiaMarcações e pagamentos para clínicas de fisioterapia independentes
A nossa decisão
A nossa decisão: Reformular
As principais razões
- MercadoAs clínicas já pagam um software de marcações. Cobranças e faltas ainda são tratadas à mão.
- ProdutoA primeira versão quer fazer tudo de uma vez. As clínicas pagariam primeiro pelas cobranças e pelos lembretes.
- DinheiroUma substituição completa do software de marcações vende-se devagar. Um módulo que funcione ao lado dele paga-se mais depressa.
O que mudaria a resposta
Uma primeira versão com cobranças e lembretes, ao lado do software de marcações que a clínica já usa, num só país.
Passo seguinte
Envie-nos o âmbito reformulado. Respondemos no prazo de 48 horas em dias úteis; se avançarmos, um gestor apresenta uma proposta por escrito.
O que verificamos antes de decidir se avançamos com o desenvolvimento.
Quando o produto se enquadra, a avaliação inclui uma análise interna do mercado global.
Os oito pontos que analisamos
| # | O que verificamos | Perguntas que fazemos |
|---|---|---|
| 01 | Quem é o utilizador | Quem tem o problema? Como o resolve hoje? |
| 02 | Quem paga | Quem paga é o próprio utilizador? O que paga hoje? |
| 03 | Que problema é resolvido | O que acontece ao utilizador se nada mudar? |
| 04 | Que alternativas existem | O que usam as pessoas em alternativa? Conta também uma folha de cálculo ou simplesmente não fazer nada. |
| 05 | Como o produto pode angariar utilizadores | Que canal chega até eles e quanto custa chegar a cada utilizador? |
| 06 | Se a monetização pode funcionar | Preço, modelo de pagamento e o ponto em que as contas batem certo |
| 07 | Qual deve ser a primeira versão | Qual é a versão mais pequena que testa o pressuposto mais arriscado? |
| 08 | Se devemos assumir o produto | Estamos preparados para o construir e operar consigo depois do lançamento? |
O que nos envia. Uma apresentação ou um resumo de uma página, o link do protótipo, se existir, e quaisquer dados sobre os utilizadores ou o mercado. Nada confidencial.
Porque diríamos que não
Se avançarmos, investimos o nosso próprio desenvolvimento no produto em troca de uma participação de 30%, e o grupo opera-o depois do lançamento. Um sim que não conseguíssemos sustentar custar-nos-ia caro durante anos. Assumimos até dez novas Product Partnerships por ano.
Para quem é
Fundadores e empresas com um produto digital novo e autónomo — uma ideia, um protótipo ou uma primeira versão — quando uma primeira conversa mostra que se pode enquadrar. Uma empresa em funcionamento segue pelo Annual Product Operations; um produto em funcionamento, pelo Existing Product Review.
O que recebe, e quando
01
Conversa inicial
Trinta minutos sobre a sua situação. Um gestor responde ao seu pedido no prazo de um dia útil, normalmente com um convite do Google Meet.
02
Avaliação, até 48 horas em dias úteis
Verificamos internamente o mercado, o produto e a lógica comercial: quem é o utilizador, quem paga, que alternativas existem e se a monetização pode funcionar.
03
A decisão antes do código, por escrito
Avançar, reformular ou recusar, com as principais razões. A investigação fica interna.
O que acontece depois de cada resultado
Avançar
Um gestor vem a uma reunião preparada para o seu produto, com uma proposta escrita: âmbito, funções, orçamento, PI, marcos e estrutura comercial.
Reformular
Dizemos-lhe o que teria de mudar — o âmbito, o modelo ou a primeira versão — e porquê.
Recusar
Fica a saber antes de gastar em desenvolvimento, com as principais razões. Um «não» antes do desenvolvimento é a boa decisão mais barata que pode tomar.
O que não é
Não é um serviço que vendemos
É a nossa decisão de assumir ou não o seu produto, tomada antes de qualquer uma das partes investir dinheiro.
Não é um relatório
A investigação fica interna; recebe a decisão e as principais razões.
Não é desenvolvimento automático
O trabalho só começa com condições escritas, acordadas na reunião preparada para o seu produto.
Não é a opinião de um comité
Toma-a uma pessoa concreta: o nosso CEO, Mark Prais.
Perguntas a fazer a qualquer parceiro de produto — e as nossas respostas
Diga-nos em que está a trabalhar.
Produto novo, processo de negócio, produto em funcionamento, financiamento ou apresentação: bastam algumas linhas para encontrar o passo seguinte.
Anton responde no prazo de um dia útil. O formulário abre com este percurso já selecionado.