Executando verificação de segurança...
22

Como diminuir as chances do seu Saas ser só mais um!

"Com design já difícil, imagina sem."
Essa foi a frase que ouvi de um profissional experiente na área de design de produtos digitais, e ela resume perfeitamente por que a maioria dos nossos projetos pessoais (como SaaS) não dão certo.

Mas o que você quer dizer com design? UI? UX?

Na verdade, quando falo de design, estou me referindo ao processo de pesquisa que acontece muito antes de abrirmos o Figma para prototipar as telas e, mais antes ainda, de abrirmos nossa IDE para codar. Mas como funciona esse tal processo de pesquisa?

Imagine que você está andando na rua, na faculdade ou no trabalho e identifica um problema que ainda não foi resolvido. Daí você pensa: "Vou criar um sistema com tal funcionalidade para resolver esse problema, vou cobrar uma mensalidade X e ficar milionário."
Chegando em casa, você começa a prototipar umas telas (ou nem isso) e já parte para o código. Sinto muito, mas as chances de isso dar certo são baixas.

"Ah, mas fulano fez isso e deu certo."
"Ah, mas ciclano está faturando 5k/semana e fez assim."

Ok, vamos pontuar algumas coisas:

  1. Muito provavelmente esse não foi o primeiro SaaS que eles fizeram.
  2. Eles já erraram várias e várias vezes, aprendendo com os erros e aumentando as chances de sucesso nas próximas tentativas.
  3. Provavelmente, depois de acertarem, eles se aproximaram do mundo do design, perceberam sua importância e vão aplicá-lo nos próximos produtos.

Não estou aqui para travar uma guerra contra os indie hackers que trabalham dessa forma. Meu objetivo é mostrar que, talvez, utilizando as técnicas certas, você pode diminuir a quantidade de tentativas necessárias para alcançar o sucesso com o seu SaaS. Isso significa criar produtos bem embasados e validados, sem depender apenas da sorte para ter uma ideia inovadora. Aliás, o processo de pesquisa ajuda muito na inovação, e o melhor: adiciona apenas 2 ou 3 semanas ao tempo total do projeto.

Outro ponto importante é que o MVP do seu SaaS pode não ser algo simples de codar em uma semana para validar. Isso aumenta a possibilidade de você "perder tempo" com um projeto que não vai dar certo (sem contar, é claro, o aprendizado que você ganha no caminho).

Mas então, como funciona esse processo?

Existem várias maneiras de realizar esse tipo de pesquisa. Aqui, vou apresentar uma delas:

CBL - Challenge-Based Learning:

Esse método é especialmente útil quando você quer começar uma ideia do absoluto zero. Por exemplo, você está no sofá da sua sala, com tempo livre, e decide iniciar um projeto. Em pouco tempo, utilizando o CBL, você consegue sair do zero (sem nem saber o nicho que vai seguir) para algo que já seja possível explicar para alguém – e essa pessoa entender o que você está tentando resolver.

(Tudo dito aqui sobre CBL está disponível no site oficial deles.)
Basicamente, o CBL é dividido em três etapas: Engage, Investigate e Act.

Engage:

Essa é a etapa onde a ideia vai surgir, onde você se aproxima do problema e define um challenge. Esse desafio será o que guiará o projeto daqui para frente.

O Engage é subdividido em três partes: Big Idea, Essential Question e Challenge.

  • Big Idea:
    Uma ideia geral, geralmente apenas uma palavra, como "água", "jogos", "esporte" ou "saúde". A Big Idea define o escopo mais amplo do seu projeto. Você pode defini-la de maneira arbitrária, com um brainstorming ou até uma roleta. Não se preocupe se o tema parecer difícil no início; sempre há como inovar.
    Por exemplo, suponha que minha Big Idea escolhida seja "Culinária".

  • Essential Question:
    Aqui, você formula uma pergunta que, mais adiante, se transformará no seu challenge. A partir de uma pesquisa sobre a Big Idea, você identifica um problema relacionado a ela e cria uma pergunta essencial.
    Exemplo: Ao pesquisar, descubro que, a cada ano, mais brasileiros recorrem à culinária para gerar renda extra com comidas artesanais. Assim, posso formular a seguinte Essential Question:
    "Como ajudar brasileiros a gerar renda extra por meio da culinária caseira?"

  • Challenge:
    O challenge é a transformação da Essential Question. Ele deve soar como um desafio que te motive a continuar.
    Exemplo: "Reduzir o número de brasileiros em dificuldades financeiras, oferecendo auxílio na geração de renda extra por meio da culinária artesanal."

E pronto! Em poucos minutos, você já tem um nicho para seguir (criei esse Engage enquanto escrevia, então é algo que pode ser feito rapidamente). Melhor ainda: é um nicho validado com dados confiáveis, encontrados na internet.

A partir daqui irei só dar uma pequena introduzida sobre as próximas etapas

Investigate:

Agora é a parte de ir atrás de respostas. É hora de pesquisar tudo o que puder: ler artigos, fuçar sites, entrevistar pessoas, ver o que já existe por aí. O desafio que você definiu vai guiar essa investigação, e o foco é descobrir o que precisa ser feito e quais caminhos podem levar à solução. Durante a fase de investigação, surgem conceitos de solução, que são prototipados, testados e refinados usando o ferramentas do design. Nessa parte, também, é desenvolvemos as aplicações (Codar 🔥).

Act

O Act é a fase de jogar o produto pro público, valida-lo em um contexto real, o avaliar com base nos resultados/métricas e ir evoluindo o produto conforme o feedback.


E é isso!
Esse foi só um gostinho de como o processo de pesquisa pode ajudar (e muito) no desenvolvimento de um produto. Espero que tenha sido útil de alguma forma!

Obrigado!

Carregando publicação patrocinada...
2

Boa! Errar faz parte do processo.
Eu mesmo errei 12 vezes antes de conseguir uma unidade de real com saas.

E mesmo assim, depois de alguns "darem certo" ainda trabalho pra caramba e aprendo muito a cada dia.

Desenhar e pensar antes faz parte do meu processo criativo e me ajuda MUITO.

Na minha visao pensar na UX é 100x mais dificil e crucial pro seu app do que a parte de codar.

1

perfeito analise de como organizar iniciar projetos.
é muito importante salvar tempo nessa parte.
no fim das contas entregar um site com uma feature ou um projeto pronto para as pessoas comprarem acaba sendo uma parte só de todo um processo.
precisa de muita organização pra nao cair na ideia de ok hoje produzi codigo entao fui produtiv@. pq se aquele codigo nao ajuda o cliente, talvez ele nem precise ser produzido e pensar em não produzir um codigo tambem é produtividade.
pq muitas vezes eu fico fazendo codigo e codigo e experimentando sites e tudo mais, mas sem pensar em quem vai usar e como, mas acho que meu lado artistico que me atrapalha as vezes - outras ajuda bastante nao vou negar - eu acabo querendo fazer mil sites doidos o tempo todo.