Senior técnico sem entender como o produto faz dinheiro é engenheiro decorativo. Constrói features que ninguém pediu, otimiza coisas que não importam pra revenue, ignora trade-offs com cost-of-goods-sold, e fica surpreso quando rounding cuts atingem o time. Liderança técnica de verdade exige fluência mínima em product, business, e unit economics, não pra virar PM, mas pra ter opinião informada sobre tradeoffs e roadmap.
Em entrevista de Staff/Principal, candidato é cobrado em "como você decidiria entre X e Y dado contexto de negócio". Resposta puramente técnica falha. Quem distingue: "X tem TCO 30% maior mas reduz churn previsto em 1.5pts → ROI positivo em 14 meses, mas só se cohort M+3 mantiver retention atual; recomendo X com gate de re-eval".
Este módulo é o vocabulário de business aplicado a software: pricing, MRR/ARR, cohort/retention, LTV, CAC, payback, churn, gross margin, unit economics, growth loops, marketplace dynamics (relevant pra Logística), B2B vs B2C, freemium/PLG, sales-led, contracts, e quando engenharia precisa pivotar pra reduzir cost ou aumentar margin.
Engineering importa em due diligence: code quality, test coverage, security, IP, key-man dependence.
2.19 Unit economics deep — CAC/LTV/payback period com fórmulas, cohort analysis, COGS per request
Engenheiro Staff que entende unit economics ganha argumentos com CFO/founder. "Cobrar mais por feature X?" sem entender LTV é palpite. "Reduzir custo Z?" sem COGS per request é otimização cega. Esta seção entrega: fórmulas exatas (não aproximações), cohort analysis em SQL, decomposição de COGS por componente cloud, decision tree de "quando invest engineering vs go-to-market".
NÃO inclui: customer success post-sale, product engineering, infrastructure.
Blended CAC vs Paid CAC: blended diz "$200/customer global"; paid CAC isola só $ de mídia paga + ad-attributable conversions. Paid CAC é mais útil pra decisões de canal.
Vermelho: > 18 meses (você queima cash até customer pagar de volta).
LTV:CAC ratio — o número de "saúde":
LTV / CAC ratio
3:1: saudável, sustentável.
5:1+: excelente; pode investir mais agressivamente em growth.
< 1:1: você paga pra adquirir, perde dinheiro em cada customer; suicídio sem mudanças.
Condição: LTV usa gross margin, sem ele você está enganando.
Cohort analysis em SQL:
-- Monthly cohort retention curve
WITH cohorts AS (
SELECT customer_id, date_trunc('month', signup_at) AS cohort_month
FROM customers
),
activity AS (
SELECT customer_id, date_trunc('month', event_at) AS active_month
FROM customer_events
WHERE event_type = 'invoice_paid'
),
joined AS (
SELECT c.cohort_month,
extract(epoch FROM age(a.active_month, c.cohort_month)) / (86400 * 30) AS months_since_signup,
COUNT(DISTINCT a.customer_id) AS active
FROM cohorts c
LEFT JOIN activity a USING (customer_id)
GROUP BY 1, 2
),
cohort_size AS (
SELECT cohort_month, COUNT(*) AS initial_size
FROM cohorts GROUP BY 1
)
SELECT j.cohort_month,
j.months_since_signup,
j.active,
ROUND(100.0 * j.active / cs.initial_size, 1) AS retention_pct
FROM joined j JOIN cohort_size cs USING (cohort_month)
WHERE j.months_since_signup IS NOT NULL
ORDER BY j.cohort_month, j.months_since_signup;
sql
Plot output: x-axis = months_since_signup, y-axis = retention_pct, 1 line por cohort_month.
Healthy SaaS: cohort line plateau após mês 6-12 em > 60%; declines até zero em 24+ meses = transactional model.
Otimizar custo com infra < 10% de revenue: ROI engineering hours melhor em features.
Ignorar discount rate em LTV de série C+: investidores institucionais usam DCF; sua LTV otimista vira foreshadowing de cap mais baixo.
Cruza com 04-16 §2.13 (engineering levers em economics — onde código direta impacta), 04-16 §2.14 (burn/runway), 04-16 §2.16 (cost optimization patterns), 03-05 §2.19 (FinOps cloud cost engineering), 04-09 §2.14 (cost ao scale).
2.20 Product-Market Fit measurement + retention metrics + activation funnels
Unit economics (§2.19) só fecham se PMF existe — caso contrário, LTV é fantasia, churn devora cohorts e CAC paga aquisição que vaza. Engenheiro Staff que entende como PMF é medido (não sentido) participa de decisões de roadmap, gating de features e go-to-market com evidência. Esta seção entrega: definições operacionais, SQL pronto pra cohort retention, framework de aha-moment discovery, benchmarks 2026 (Lenny Rachitsky / OpenView / Bessemer).
PMF — definições operacionais (não vibes):
Marc Andreessen 1.0 (2007): "the only thing that matters". Famoso, vago — não mede nada. Útil como prioridade, inútil como diagnóstico.
Sean Ellis test: pergunta única após user qualificado (3+ uses): "How would you feel if you could no longer use [product]? Very disappointed / Somewhat / Not disappointed". PMF threshold = > 40% Very disappointed.
Rahul Vohra (Superhuman PMF Engine): segmenta respondentes; foca cohort "Very disappointed" pra extrair ICP, principal benefit ("speed"), e barriers do "Somewhat" ("missing calendar"). Roadmap deriva direto disso.
PMF quantitativo: cohort retention curve flatten (não decai a zero); organic growth (referral coefficient > 0.5); inbound dominance ("category leader" em conversa de buyer).
Pre-PMF traps: paid acquisition funcionando + organic churn alto; user growth alimentado por ads; repeat usage fraco (D30 < 15% B2B). Crescer NÃO é PMF.
Sean Ellis test — implementação:
-- Trigger: in-app modal após 3+ qualified actions (created order, etc.)
WITH qualified AS (
SELECT sr.user_id, sr.sean_ellis_response, sr.surveyed_at,
COUNT(ue.id) AS uses_before_survey
FROM survey_responses sr
JOIN usage_events ue ON ue.user_id = sr.user_id
AND ue.created_at < sr.surveyed_at
AND ue.event_type = 'order_created'
GROUP BY sr.user_id, sr.sean_ellis_response, sr.surveyed_at
HAVING COUNT(ue.id) >= 3
)
SELECT
COUNT(*) FILTER (WHERE sean_ellis_response = 'very_disappointed')::float
/ NULLIF(COUNT(*), 0) * 100 AS pmf_pct,
COUNT(*) AS responses
FROM qualified
WHERE surveyed_at >= NOW() - INTERVAL '30 days';
sql
Sample mínima: 100 respostas pra signal estatístico (Vohra recomenda 40+ "very disappointed" absolutos).
Frequência: cada quarter pra detectar shift (feature shipping, segment change).
Retention metrics — Day-N curves:
D1 / D7 / D30 / D90 retention: % users que fizeram qualified action 1/7/30/90 dias após first action.
Cohort retention curve: agrupa users por signup week; mede % ativo em cada week post-signup.
Comparar B2B com B2C é erro: 30% D30 = excellent em B2C, bad em B2B.
Cohort retention SQL (Postgres):
WITH cohorts AS (
SELECT user_id, DATE_TRUNC('week', created_at) AS cohort_week
FROM users WHERE created_at >= '2026-01-01'
),
activity AS (
SELECT user_id, DATE_TRUNC('week', occurred_at) AS active_week
FROM events
WHERE event_type = 'order_created'
),
joined AS (
SELECT
c.cohort_week,
a.active_week,
(a.active_week - c.cohort_week) / 7 AS weeks_since_signup,
COUNT(DISTINCT c.user_id) AS active_users
FROM cohorts c
JOIN activity a ON c.user_id = a.user_id AND a.active_week >= c.cohort_week
GROUP BY c.cohort_week, a.active_week
),
sizes AS (
SELECT cohort_week, COUNT(DISTINCT user_id) AS cohort_size
FROM cohorts
GROUP BY cohort_week
)
SELECT
j.cohort_week,
j.weeks_since_signup,
j.active_users,
s.cohort_size,
ROUND(j.active_users::numeric / s.cohort_size * 100, 1) AS retention_pct
FROM joined j
JOIN sizes s ON j.cohort_week = s.cohort_week
ORDER BY j.cohort_week, j.weeks_since_signup;
Logística aha: lojista que cria 5+ pedidos no first week + integra Stripe → 85% D90 retention; lojista que só faz signup → 8% D90. Aha = "5 orders + Stripe in week 1".
Activation event no produto:
Onboarding flow drive user até aha o mais rápido possível. Cada step adicional = drop-off.
A/B reduzindo friction: original 12 steps → novo 5 steps; activation rate 35% → 58% (números reais Superhuman/Notion-style).
Activation gating (premium SaaS): destrava features avançadas só após aha — força user a investir antes de avaliar custo.
MAU/DAU + DAU/MAU ratio:
DAU (Daily Active) / WAU / MAU, com "active" = qualified action (created order), NÃO login.
Custom Postgres + Grafana: $0; eng team owns; recomendado pra Logística no early stage.
Anti-patterns observados:
Vanity metrics (registered users, total signups) sem cohort retention — mascara churn e finge crescimento.
"Active" = login (sem qualified action) — bot traffic e curiosity opens contam.
PMF "feels good" sem Sean Ellis quantitativo — founder bias domina.
Retention curve sem cohort breakdown — averaging mascara melhora ou piora real.
Aha moment definido post-hoc por opinião — correlação ≠ causação; gating change exige A/B test.
Onboarding optimizado pra "completion" (90% complete) e não retention (80% D30) — métrica errada.
DAU/MAU sem qualified-action filter — login bots inflam stickiness.
NRR sem definição clara de cohort start/end — números não comparáveis entre períodos.
Comparar bench B2B vs B2C — workloads diferentes; 30% D30 = excellent B2C, bad B2B.
Activation funnel sem step-level drop-off — improve weakest step primeiro, não o último.
Cruza com 04-16 §2.19 (unit economics — retention drives LTV; PMF é precondição), 03-07 (observability + product analytics infrastructure), 04-12 (tech leadership — comunicar PMF status ao board), 02-19 (i18n — retention varia por locale), 04-10 (LLM — Sean Ellis sentiment analysis em escala).
2.21 SaaS pricing strategy 2026 — usage-based vs flat-rate vs hybrid, expansion mechanics, tier design, packaging anti-patterns
Pricing é o lever de maior leverage do business. Estudo Simon-Kucher (replicado anualmente desde 2003): +1% em price realization gera +8 a +12% em operating profit, vs +1% em volume (+3-4%) ou +1% em variable cost (+5-6%). Mesmo assim, a maioria dos founders de engineering background tratam pricing como afterthought — escolhem $X/mês "porque competidor cobra Y" e nunca revisitam. Resultado: deixam 30-50% de revenue na mesa, ou pior, escolhem value metric errado e travam expansion para sempre. Pricing 2026 é multi-axial — model (per-seat, flat, usage, hybrid), value metric (qual unidade cobrar), tiers (good-better-best), packaging (qual feature em qual tier), discount discipline (annual vs monthly, multi-year), e dynamics (grandfathering, price increases, NRR drivers). Cada eixo tem decisão certa que depende de COGS structure, customer behavior, e willingness-to-pay distribution. Errar qualquer um é caro — errar value metric é catastrófico (impossível de consertar sem migration painful).
Revenue unpredictable, customer fear de "bill shock", forecasting harder, sales cycle complexa
Infra (compute, storage, bandwidth), API products, payment processing, anything onde value scales linearmente com volume
Hybrid (platform fee + usage)
Base subscription + usage overages (Datadog ~$15-23/host/mês infra + $0.10/1M custom metrics + $1.27/M log events ingested + $1.70/M indexed; Vercel team $20/seat + $20/100GB bandwidth + Function invocations; Twilio $1/phone number + $0.0079/SMS)
Revenue floor + upside, best of both, NRR engine natural
Complexidade de billing/comm, customer needs to understand 2 dimensões, harder to compare com competitors
Maioria dos SaaS B2B 2026 — default moderno
Trend 2024-2026: shift massivo de per-seat puro pra hybrid com usage component. Notion adicionou AI add-on $10/seat/mês em 2024. GitHub Copilot $19/seat business + Enterprise $39. Slack adicionou Slack AI $10/seat/mês add-on. Razão: per-seat sozinho não captura valor de AI features (1 user com Copilot consome $5-50/mês em LLM tokens — flat $19 quebra gross margin se usuário é power user, sobrelucra se é casual).
Value metric selection (decisão mais crítica)
Value metric = a unidade que o customer paga por. Ex.: seat (Notion), GB ingested (Datadog logs), credit consumed (Snowflake), API call (Stripe), MAU tracked (Mixpanel), record stored (Salesforce Data Cloud), GB/month transferred (Cloudflare).
Critérios pra value metric boa:
Correlaciona com customer value — quando customer extrai mais valor, paga mais. Snowflake credit consumido proxy direto pra queries rodadas → pra business outcomes. Per-seat em ferramenta async-first onde 80% dos seats nunca abrem app: value metric ruim.
Easy to understand — customer prevê o bill antes de gastar. "$/credit" só funciona se customer sabe traduzir workload em credits. Snowflake mitigou com cost calculator + warehouse sizing docs.
Easy to meter — engineering precisa rastrear unit reliably. Veja 03-07 — meter é producto de observability; bug em meter = revenue lost ou customer dispute. Stripe levou 8 anos pra ter usage metering pronto pra terceiros (Stripe Billing usage-based, GA 2024).
Predictable from customer side — wild swings = "bill shock" = churn. AWS é cautionary tale; Snowflake mitigou com reserved capacity + warehouse auto-suspend.
Aligned com COGS — se cada unit consome COGS variável (LLM token, compute hour), pricing precisa cobrir COGS + margin. Cobrar flat-rate em product onde COGS é variable e unbounded é suicide gross margin.
Anti-padrão clássico: escolher value metric por conveniência de measurement em vez de alinhamento com value. Ex.: cobrar por "API calls" quando 1 call de leitura é 100x mais barata que 1 call de write — customer racha endpoints e foge do pricing.
Expansion mechanics (NRR/NDR como north star)
Net Revenue Retention (NRR) = (Starting ARR + Expansion - Contraction - Churn) / Starting ARR. Mede crescimento da base existente, sem new logos. Top SaaS 2026 benchmarks (públicos):
Median public SaaS NRR: 110-115% (caiu de 120% pré-2023)
Cross-sell (10-20%) — produtos adjacentes (HubSpot Marketing → Sales → Service Hub; Datadog Infra → APM → Logs → Security).
Engineering directive: cada feature decisão deve perguntar "isso aumenta usage do value metric ou só satisfaz feature request?". Onboarding melhor → mais workspaces criados → mais seats adicionados → expansion. Activity feed → mais engagement → mais sticky → less churn. Veja 04-15 — product strategy precisa estar amarrado a NRR levers.
Tier design — good-better-best, anchoring, decoy
Standard pattern: 3 tiers visíveis + 1 enterprise (custom). Por quê 3? Choice paralisis em 4+; "Goldilocks effect" em 3 (médio vence). Notion: Free / Plus $10 / Business $15 / Enterprise (custom). Linear: Free / Standard $8 / Plus $14 / Enterprise. Vercel: Hobby / Pro $20 / Enterprise.
Anchoring: mostrar Enterprise (mais caro) primeiro ou destacar Business como "Most Popular" força customer a comparar contra preço alto, fazendo Plus parecer barato. Marketing sites 2026 quase universalmente fazem isso.
Decoy effect: tier intencionalmente pior cost/benefit pra empurrar customer pro tier alvo. Clássico The Economist (Ariely 2008): web $59, print $125, web+print $125 → 84% escolhem web+print porque print-only é "decoy". Em SaaS: Plus tier feature-poor demais pra force upgrade pra Business.
Willingness-to-pay segmentação: tiers existem porque WTP não é uniforme. Solo dev paga $10, startup team paga $50/seat, Fortune 500 paga $200/seat pelo MESMO core product + compliance + SSO + audit. Tiers capturam consumer surplus em cada segmento.
Packaging discipline — qual feature em qual tier
Princípio: gate features que correlacionam com customer size/sophistication, não features que custam mais pra rodar. Erros comuns:
Gating features que custam pouco mas all customers querem (e.g., 2FA em tier pago) — bad press, segurança não é upsell.
Não gating features que enterprise needs (SSO/SAML, audit logs, RBAC, SCIM provisioning, custom data residency) — deixa dinheiro na mesa. "SSO tax" é industry standard 2026 — SAML SSO é Enterprise-tier-only em 95% dos SaaS B2B. Sites como ssotax.org pressionam, mas mercado paga.
Gating limites em vez de features quando product é collaborative — limitar workspace size em Free força viral upgrade (Notion, Figma, Linear playbook).
Standard 2026 packaging:
Free / Hobby: 1 user ou small team, single project, 30-day history, community support. Loss-leader, viral motion.
Pro / Plus ($10-30/seat/mês): teams pequenos, advanced features, email support, 90-day history.
Twitter/X API monetization 2023 — community devs mass-exodus, third-party ecosystem destruído.
Playbook seguro:
Grandfather existing customers no preço atual — pelo menos 12-24 meses, idealmente para sempre em legacy plans. Custo: revenue oportunidade. Benefício: zero churn de aumento + goodwill.
New pricing só pra new customers + new tiers. Existing customers podem opt-in pra novo plan se features novas valem.
Comm 60-90 dias antes, email + in-app + blog post + CSM outreach pra top accounts. Founder/CEO assina email — não "Marketing Team".
Grandfather window com upgrade incentive: "Lock in current price for 24mo se assinar annual antes de [data]" — converte mensais em anuais, reduces churn risk em 50%+.
Grandfathering forever pra top customers — Stripe famously grandfather early customers em 2.4% (vs 2.9% standard). Goodwill imenso, custo marginal trivial em base do tamanho deles.
Discount discipline
Annual prepay: 15-20% discount standard. Trade-off: cash up front + churn protection vs revenue per customer. Pra business com CAC alto, annual é existential — paga CAC payback de uma vez.
Multi-year (2y, 3y): 25-35% discount, mas rare em SMB; padrão em enterprise. Lock-in vs price flexibility trade-off.
Volume discount em usage-based: tiered ou committed-use (Snowflake CUP — Capacity Units Purchase, AWS RIs/Savings Plans). Customer compromete X/year, recebe 20-40% off em troca.
NPV discipline: every discount aprovado deve passar por "qual o NPV do contrato vs walk-away?". Sales não tem discretion ilimitado — pricing committee aprova >20% discount. Salesforce literalmente tem "Deal Hub" pra isso.
Anti-padrão: descontos discretionários sem floor → race to bottom interno, sales rep optimizing pra fechar e não pra LTV.
"We'll figure pricing later" — pricing post-launch é 10x mais difícil; decisões iniciais (free tier limites, value metric) viram contratos sociais com customers.
Per-seat em product onde value scales com usage — penalizes power users e viral growth; 1 power user >> 10 seats lurking.
Flat-rate em product com COGS variável unbounded (LLM resale, compute, bandwidth) — gross margin colapsa quando whales aparecem.
Free tier sem cap em COGS-heavy resource — free users consumindo $500/mo em LLM tokens; cap mensal obrigatório.
Mudar preço pra existing customers sem grandfathering — mass churn + Hacker News firestorm + permanent reputation damage.
Value metric escolhida por measurement convenience, não value alignment — customer arbitra contra a metric (rachando endpoints, batching writes).
Tiers sem anchor / sem most-popular highlight — choice paralysis; conversão drop 30-50%.
"Contact sales" em todos os tiers — friction massiva pra SMB; PLG (Product-Led Growth) requer self-serve até $10-50k ARR.
Discount discretionário sem floor — sales fecha negócios LTV-negativos pra bater quota; pricing committee + NPV gate obrigatório.
Não meter o value metric com observability rigor — billing bug = revenue lost (under-bill) ou customer dispute escalado pra CEO (over-bill); meter é producto de eng tier-1, não cron job side project.
Cruza com 04-16 §2.1 (revenue models intro — pricing é onde model encontra reality), 04-16 §2.5 (CAC — pricing afeta payback period diretamente), 04-16 §2.8 (pricing strategy basics — fundação), 04-16 §2.13 (engineering levers — meter, billing infra, dunning), 04-16 §2.16 (cost optimization — gross margin = pricing - COGS), 04-16 §2.19 (unit economics — LTV/CAC depende fundamentalmente de pricing), 04-15 (product strategy — packaging amarrado a NRR roadmap), 03-07 (observability — value metric metering production-grade), 04-10 (LLM cost passthrough — token economics em hybrid pricing).
3. Threshold de Maestria
Você precisa, sem consultar:
Diferenciar MRR e ARR; explicar Net New MRR breakdown.