Build-Measure-Learn

A not-so-good way of building a startup is choosing an ideia, spending a lot of time turning it into a product and forgetting about (prospective) customers.

A better way of doing it:

• Build: quickly turning ideas into products;
• Measure: collecting (creating) data about how customers respond to what you’ve built;
• Learn: analyzing data to decide whether to pivot or keep going;

Sounds familiar? Maybe that’s because I’ve just described the scientific approach to creating and managing startups Eric Ries presents in the book Lean Startup.

In this article, I specifically want to talk about two topics related to the ‘Measure’ phase of Ries’ methodology: lagging and leading indicators.

As you’ll see below, not all measurements were made equal.

Lagging indicators

What is a lagging indicator?

Lagging indicators can be defined as i) direct measurements of past success, which ii) changes cannot be observed instantly, usually taking weeks, months or even longer, and iii) represent the effect in a cause-and-effect relationship.

Lagging Indicator Examples

• ROI for adversiting campaigns
• Customer Acquisition Cost (CAC)
• Sales Qualified Leads (SQLs)
• Marketing Qualified Leads (MQLs)
• Revenue (e.g., Anual Recurring Revenue)
• Customer support tickets solved over a specific timeframe
• Churn rate

Why are lagging indicators important?

Because lagging indicators are an easy way to check if a startup is achieving its main goals. Without them we’d be in the dark about the progress being made. Also, we’d be lacking a valuable starting point for highlighting points of leverage relevant to achieving said goals.

Your outcomes are a lagging measure of your habits.
Your net worth is a lagging measure of your financial habits.
Your weight is a lagging measure of your eating habits.
Your knowledge is a lagging measure of your learning habits.
Your clutter is a lagging measure of your cleaning habits.

- James Clear, Atomic Habits

Leading indicators

What is a leading indicator?

Leading indicators can be defined as indirect measurements of future success, which ii) changes can be observed instantly and iii) represent one of many causes, with different significance levels, in a cause-and-effect relationship.

How to identify leading indicators

Statistical approach

• List measurable activities that temporally precede a result represented by a lagging indicator;
• Calculate the correlation coefficient between the chosen lagging indicator and each measurable activity;
• Sort them in descending order to view the best leading indicator candidates;

Remember: correlation does not imply causation, so continuously validating your leading indicators is just as important as identifying them!

Value stream mapping

• List company-wide strategic indicators and metrics;
• Link each one of them to one or more teams along the company’s value stream (sales, software engineering, HR, etc);
• Ask three main questions to different stakeholders from each team to identify possible leading indicators:

— Why is the metric/indicator current target (not) being met?

— What is within our circle of influence and impacts the metric/indicator?

— What is beyond our circle of influence and impacts the metric/indicator?

Remember: different teams will have different comprehension and execution levels on data-informed work, so it’s totally acceptable not knowing how to better answer these questions!

The most important thing here is, at least, starting a constant push towards continuously giving better answer for them over time!

Owner-Customer Role Play

• Recruit different stakeholders from different teams along the company’s value stream to a role play;
• Have everyone pretend to be the owner of the company and write down, individually, the most important (lagging) indicator or metric they would need to properly manage it;
• Reveal the answers to every participant;
• Have everyone pretend to be a customer, supposing a similar product or service from a competitor is easily avaliable and similarly priced, and write down, individually, why and how to decide which product or service to choose;
• Organize and synthetize what was written into a possible lagging and leading indicators proposal;

Remember: biases will be inevitable due to past experiences behind each person’s view, so using data to continuosly validate and assign proper weight to each leading indicator is very important!

Besides, any proposal made needs trust and support from the participants to truly have success!

Leading Indicator Examples

• Unique website visitors
• Growth experiments run
• Daily active users
• Average revenue per user
• Number of unsolved customer support tickets per agent
• Number of customer support tickets reopened
• Key feature usage rate

Why are leading indicators important?

Because leading indicators are a reliable (even if not so easy) way to check if the work done is actually generating impact to a startup’s goals.

Without them we’d be in the dark about how meaninful people’s efforts (i.e., performance management) are. Also, we’d be lacking a valuable starting point for learning how to improve said efforts are over time.

Connecting lagging and leading indicators to deliver business impact

Working with lagging and leading indicators is equally necessary to practicing a solid management strategy and avoiding some common startup pitfalls, for example:

• Working with lagging indicators without linking them to leading indicators, usually means not being systematic on finding actionable approaches to growth (A.K.A. modelling growth).

The opposite is also an issue:

• Working with leading indicators without linking them to lagging indicators, usually means being busy, but not necessarily successful (A.K.A. working hard, but not so smart until people burn out).

Closing remarks

As startups grow, the Build-Measure-Learn cycle is not only about the relationship between customer and product. It is also about the relationship between people: why people build, what people learn, and, most importantly, how people measure things becomes the first step for creating sustainable relationships and businesses.

🎬 Why am I doing this?

Long story short: making it easier to recall the best product management-related content I’ve consumed over the years. I kinda have this superpower: there’s no topic which I don’t have good content about to recommend!

🔝 Who is a Good Product Manager?

• Bandan Jot Singh (Payments @ Booking.com, ex-Head of Product @ Gojek)
• Marty Cagan (Author, Partner @ Silicon Valley Product Group and former product executive at eBay, Netscape, Continuus, and HP
• Ravi Mehta (Co-Founder @ Scale. Previously EIR @ Reforge, CPO @ Tinder, Product @ Facebook, TripAdvisor, Xbox)
• Shreyas Doshi (Advisor to fast-growing startups. ex-Stripe, Twitter, Google, Yahoo)
• Rohan Rajiv (Product @ LinkedIn)
• Teresa Torres (Author, Speaker, Product Discovery Coach)
• Tim Herbig (Product Management Coach & Consultant, Speaker)

❓ What is a Good Product Manager?

• How To Navigate Product Management Specializations (Reforge)
• ⭐ How to Become a Peak Product Manager (Ravi Mehta)
• The Growing Specialization of Product Management (Reforge)
• What It Takes to Become a Great Product Manager (Harvard Business Review)
• Why Chefs and Soldiers Make the Best Product Managers (First Round Review)

🧰 How Does a Good Product Manager Do Product Management Stuff?

0️⃣ Zero to One

• A Minimum Viable Product Is Not a Product, It’s a Process (Y Combinator)
• How to Take Notes During Customer Research Interviews (Product Talk)
• ⭐ How to Talk do Users (Y Combinator)
• Journey-Mapping Approaches: 2 Critical Decisions To Make Before You Begin (Nielsen Norman Group)
• Seven Elements of Visual Management: Getting the Right Information at the Right Time (Modus Institute)
• The Time Value of Shipping (Brandon Chu)
• Tug of War: Balancing What’s Best for the User vs. Business (Reforge)

📊 Product Outcomes

• ⭐ A Practical Guide to Using OKRs in Product Management (Tim Herbig)
• Don’t Let Your North Star Metric Deceive You (Reforge)
• Four Frameworks to Help You Define Product Metrics (Product Coalition)
• How do you establish product metrics to evaluate success? (Gibson Biddle)
• In Search of the Leading Indicator (Thomas Christensen)
• Metrics-driven product development is hard. (DoubleLoop)
• OKRs ≠ Strategy (DoubleLoop)
• Set Better Goals with NCTs, Not OKRs (Reforge)
• Why most analytics efforts fail (Reforge)
• You Cannot Be Data-Driven Without Experimentation (Reforge)

📈 Product Growth

• Making Monetization Your Superpower (Reforge)
• ⭐ Monetization vs Growth? It’s a False Choice (Reforge)
• The Adjascent User Theory (Andrew Chen)
• The Momentum Canyon: From Traction to Growth (Reforge)
• ⭐ The Power User Trap (Reforge)

1️⃣󠁎󠁎 One to N

• Case Study #4: Products are bets (ShapeUp Method at Basecamp) (Productify)
• How PR/FAQs help launch successful products like AWS, Kindle & Prime Video (Colin Bryar)
• ⭐ How to Work with Designers (Julie Zhuo)
• ⭐ How to Work with Engineers (Julie Zhuo)
• Product Discovery: A Practical Guide for Product Teams (Tim Herbig)
• Product Work Beyond Product-Market Fit (Reforge)
• Rethinking Your Operating Cadence (Reforge)
• The Ladder of Evidence: Get More Value From Your Customer Interviews and Product Experiments (Product Talk)
• The Strategies to Grow an Infrequent Product (ICED theory) (Reforge)
• Tools of the Trade: A Look at the Discovery Tech Stack at 99designs (Product Talk)
• Why Do So Many Startups Get Product Marketing Wrong? (Reforge)
• Why This Opportunity Solution Tree is Changing the Way Product Teams Work (Product Talk)
• Your guide to product-led marketing (Kyle Poyar)

⚙️ Product Efficiency

• Amazon’s Friction-Killing Tactics To Make Products More Seamless (First Round Review)
• Killing product zombies: a five-step approach (Mind The Product)
• Make Product Decisions Without Doubt — My Lessons from Twitter and Slack (First Round Review)
• Managing Up — Lessons From Scaling Teams at Credit Karma and Lyft (Reforge)
• ⭐ Upsides to Unshipping: The Art of Removing Features and Products (Reforge)

📝 Product Career

• Always Evolving Obeya: BubbleBahn (Modus Institute)
• Grow Your Career Like You Grow A Product (Reforge)
• ⭐ Impact = Environment x Skills: How to make career decisions (Reforge)
• The Reverse Interview: How To Choose Your Next Company (Reforge)
• Why Drawing Maps Sharpens Your Thinking (Product Talk)

🤔 How Does a Good Product Leader Do Product Leadership Stuff?

📧 Product Recruitment

• ⭐ Find, Vet and Close the Best Product Managers (First Round Review)
• Trello’s Product Lead on the Unique Ramp to a 10-Person Product Org

💾 Data-driven Product Decisions

• Everyone Thinks They’re Managing by Outcomes. Here’s How to Actually Do it. (Product Talk)
• How to Set KPIs and Goals (Y Combinator)
• KPI Trees: How to Bridge the Gap Between Customer Behavior, Product Metrics, and Company Goals (Petra Wille)

🗺️ Product Strategy

• TBM 4/52: An Actionable Post With Examples (Tree/Loop Prompts) (John Cutler)
• ⭐ The DHM Model (Gibson Biddle)
• ⭐ The Product Strategy Stack (Reforge)
• What do you think about project-based roadmaps versus outcome-based (metric-based) roadmaps? (Gibson Biddle)

🔧 Product Processes

• Building Growth: Product, Process, and Team (Reforge)
• Product is the Future of Growth — Here’s Why (Reforge)
• Running Product Reviews People Actually Look Forward To (Daniel Slate)
• Scaling Product Delivery: The “Dirty” Secret of High Performing Product Teams (Reforge)
• The 4 Principles of LinkedIn’s Product Review Meetings (Deep Nishar)
• ⭐ When and How to Take Big Swings (Reforge)
• Why Enterprise Products are Missing the Boat on Growth (Reforge)

Por que estou escrevendo esse conteúdo?

Esse é o primeiro artigo do Tech Simples: o blog das pessoas de tecnologia da Conta Simples! Nossos princípios para a produção de conteúdo são:

1. Incentivar as pessoas da empresa a aprenderem mais sobre suas respectivas áreas de atuação profissional;
2. Gerar conteúdo de valor para a comunidade brasileira de profissionais de tecnologia;
3. Chamar a atenção de talentos potencialmente interessados em fazer parte do nosso time! Bora? Comente nesse artigo ou me chame no LinkedIn!

Por que a jornada do cliente é importante na gestão de um produto?

Tenho um limoeiro na frente de casa. Todo ano ele dá frutos, geralmente numa quantidade maior que a necessária para a nossa família. Esse era o caso nesse ano, mas resolvi fazer diferente: mandei uma foto da árvore num grupo de vizinhos do condomínio e disse que doaria os limões aos interessados.

Adivinha? Ninguém respondeu.

Temi que os limões apodreceriam, então resolvi eu mesma apanhá-los. Coloquei todos num cesto e o posicionei, estrategicamente, próximo à porta e do lado de fora.

Mandei uma nova foto no grupo, mas já tinha assumido que ninguém precisava de limões. No dia seguinte, metade dos limões se foram! Dois dias depois, o cesto estava vazio e a filha de um dos vizinhos estava batendo à porta: sobrou algum limão?

Logo percebi! Essa era a oportunidade perfeita, a oportunidade perfeita para contar uma anedota sobre gestão de produtos digitais!

Falando sério, é pouco provável que a demanda por limões (produto) tenha surgido do nada. Pelo contrário, o mais provável é que ela sempre tenha existido. Apanhar os limões, colocá-los num cesto bonito e tirar uma foto com filtro do Instagram (go-to-market) foram apenas iniciativas para eliminar os atritos da jornada do cliente.

Limões frescos num cesto em frente à casa do vizinho: entrega de valor rápida e fácil. A jornada do cliente é importante porque ninguém (cliente) vive numa bolha consumindo frutas (produto) sempre que o vizinho (startup) manda uma foto num grupo (marketing/vendas).

Aprender a otimizar a jornada do cliente é única sustentável maneira de crescer. A primeira lição? Muita coisa dará errado, partir desse pressuposto e tentar antecipar momentos onde a experiência do cliente será diferente da ideal é uma abordagem necessária (modelo mental da inversão).

Funcionalidades x Experiências

Se eu perguntasse a meus compradores o que eles queriam, teriam dito que era um cavalo mais rápido.

— Henry Ford

A sagaz citação de Henry Ford representa bem a seguinte consideração: cliente é dono do problema, mas não é dono da solução.

Dito isso, permitam-me criar uma frase equivalente para equipes responsáveis pela construção de produtos digitais: a equipe não é dona do produto (ou funcionalidade), mas é dona dos resultados e experiências consequentes de seu uso.

Construir um produto ou funcionalidade de sucesso é um meio para determinados fins: atender uma necessidade, gerar satisfação e criar a experiência adequada.

O produto (ou funcionalidade) por si só, quando alcança certo sucesso, será prontamente copiado por concorrentes. Assim, o que nos resta como vantagem competitiva?

• Preço? Só é sustentável enquanto seu custo operacional é inferior aos concorrentes;
• Promoção e publicidade? Vender demais e entregar de menos é um risco real.

A experiência em cada ponto de contato da jornada do cliente é a pré-condição para uma vantagem competitiva duradoura:

• Como o cliente encontra o produto?
• Como o cliente realiza os passos que antecedem o uso do produto?
• Como o cliente se prepara para usar o produto?
• Como o cliente usa o produto?
• Como o cliente paga pelo produto?
• Como o cliente consegue ajuda para usar o produto?
• Como o cliente deixa de usar o produto?

Funil Pirata (AARRR): jornada do cliente como motor de crescimento

O funil pirata (AARRR) é um framework de growth hacking que se encaixa muito bem com a visão de jornada do cliente. Cada letra da sigla representa um estágio dessa jornada:

• A: aquisição (como o cliente encontra o produto)
• A: ativação (como o cliente usa o produto pela primeira vez)
• R: retenção (como o cliente continua usando o produto)
• R: receita (como o cliente paga pelo produto)
• R: referência (como o cliente recomenda o produto para potenciais clientes)

A partir desse framework podemos nos aprofundar numa abordagem quantitativa e traçar métricas e indicadores para cada estágio:

Aquisição (exemplos)

• Métrica/indicador principal: número de usuários que instalaram o aplicativo
• Métrica/indicador de calibragem 1: número de usuários que acessaram a landing page
• Métrica/indicador de calibragem 2: taxa de conversão dos usuários que acessaram a página da loja através da landing page

Ativação (exemplos)

• Métrica/indicador principal: número de produtos visualizados após o primeiro login
• Métrica/indicador de calibragem 1: tempo de navegação após o primeiro login
• Métrica/indicador de calibragem 2: número de itens adicionados ao carrinho de compras

Retenção (exemplos)

• Métrica/indicador principal: número de compras realizadas
• Métrica/indicador de calibragem 1: número de usuários ativos por período
• Métrica/indicador de calibragem 2: taxa de churn

Referência (exemplos)

• Métrica/indicador principal: número de usuários que instalaram o aplicativo através do programa de indicações
• Métrica/indicador de calibragem 1: número de cliques no botão “compartilhar convite”
• Métrica/indicador de calibragem 2: número de cadastros finalizados com uso do código de indicação

Nota: o desafio nessa frente é escolher as principais métricas/indicadores como aquelas que trazem o maior impacto para empresa e cliente em cada estágio.

As métricas/indicadores de calibragem servem para evitar conflitos de incentivos entre estágios e proteger a métrica/indicador principal de cenários do tipo “chegar no número sem trazer o impacto esperado”.

Jornada do cliente para crescer (como e quando)

Alguns parágrafos acima eu disse que otimizar a jornada do cliente é a única maneira sustentável de crescer. Contudo, nem todo crescimento é igual:

• Numa startup em estágio inicial, a aquisição de clientes (topo do funil pirata) é mais importante: sem clientes não há feedback. Sem feedback, não há iteração. Sem iteração não há avanço em direção ao product-market fit.
• Conforme uma startup alcança estágios maiores de maturidade, a retenção de clientes se torna mais importante:

É mais eficiente (leia-se, custo de oportunidade menor) gerar valor para clientes já conquistados (e monetizá-los) do que adquirir novos clientes (para perdê-los em pouco tempo).

No final do dia você quer os dois, mas num cenário de aquisição ruim e retenção boa ganhamos tempo e ficamos jogo. Num cenário de aquisição boa e retenção ruim estamos expostos ao pior pesadelo de uma startup: a silenciosa decadência do crescimento.

Agradeço Rafa, Bia e Paulo pela leitura do rascunho deste artigo e feedbacks valiosos.

Quer saber mais sobre a Conta Simples?

Acesse o nosso perfil no LinkedIn, comente neste artigo ou mande mensagem para alguém do nosso time! Quem sabe não estaremos trabalhando juntos em breve?

Jornada do cliente para gestão de produtos digitais was originally published in Tech Simples on Medium, where people are continuing the conversation by highlighting and responding to this story.

I guess the title is pretty self-explanatory, huh? By the way, feel free to get in touch with me at LinkedIn.

Must-read:Why Join A Company That’s Scaling Up (AngelList)

Technology

3x in 3 years: Scaling an Engineering Organization (PagerDuty)

How We Reorganized Instagram’s Engineering Team While Quadrupling Its Size (Harvard Business Review)

Miro’s Product Alignment Approach (Farbod Saraf)

Hyper-Growth Done Right — Lessons From the Man Who Scaled Engineering at Dropbox and Facebook (First Round Review)

The Keys to Scaling Yourself as a Technology Leader (First Round Review)

Management

Managing Hypergrowth (Harvard Business Review)

What Is Hypergrowth? (And How Do You Achieve It?) (Drift)

Designing a Company’s Operating System for Hypergrowth (Belinda Johnson)

Rituals for hypergrowth: An inside look at how YouTube scaled (Shishir Mehrotra)

Hypergrowth and The Law of Startup Physics (First Round Review)

Productivity in the age of hypergrowth (Irrational Exuberance)

Lessons from Coinbase’s Wild Ascent: Four Rules for Scaling (First Round Review)

The Do’s and Don’ts of Rapid Scaling for Startups (First Round Review)

Navigating the Stages of Hyper-growth (Hacker Noon)

Four Lessons from Leading Hyper-growth (Loren Padelford)

Wisdom from Hyper-growth Companies (Startup Lessons Learned)

Elad Gil on catapulting into hyper growth (Intercom)

People

Hypergrowth Startups: Talent Retention and Growth Tips for Customer Success Teams (Lilian Klemz)

How to Find & Retain People Who Can Scale Your Startup Through Hyper-Growth (Better Everyday)

The Alchemy of Scaling Teams in Fast-Growing Startups (Blinkist)

O que é o ‘Construindo empresas de tecnologia no Brasil’?

Essa é uma lista de leituras recomendadas (por mim, exclusivamente em português brasileiro) para interessados em empresas de tecnologia no Brasil.

Por que estou fazendo o ‘Construindo empresas de tecnologia no Brasil’?

1. Gosto (muito) de aprender, ler e escrever.
2. Já fiz algo parecido antes. Se tiver interesse, pode ser útil: How To Build a Neobank e How to Build a Top Tech Company

Como posso ajudar o ‘Construindo empresas de tecnologia no Brasil’?

Você pode comentar no próprio Medium ou enviar uma solicitação de conexão no LinkedIn, conversamos por lá: Paulo Silveira.

Estratégia, Pessoas e Cultura

O que aprendi ao me tornar um líder do Design do iFood (iFood)

Como construir o seu Plano de Desenvolvimento Individual (PDI) (iFood)

Liderança em Design: um movimento de dentro para fora (Loft)

Como você utiliza seu tempo livre? (Loft)

Putz, Virei Gerente (Grupo ZAP)

Estudando de forma eficiente (Grupo ZAP)

A fantástica fábrica de talentos (Grupo ZAP)

Plano de Desenvolvimento Individual (PDI) o que é e como iniciar o seu. (XP Inc.)

Mudando de carreira para me tornar um desenvolvedor (Creditas)

Como fazer feedback em time (Creditas)

A Diferença entre Planejar e Projetar (Creditas)

SkillMap Assessment — Conhecendo um pouco mais sobre nossos times (Creditas)

Como é o Onboarding de uma das maiores Fintechs no Brasil (Creditas)

Expandindo a visão de problemas do seu time (Creditas)

Vergonha do “não saber” (Arquivei)

Ciência de Dados

Os 4 Ps de Data: o recheio é contexto e relevância (iFood)

O que você precisa saber sobre testes A/B para não pisar na jaca (iFood)

Como começar na área de Ciência de Dados? — Em dois passos. (iFood)

DataOps — Escalando a engenharia de dados no LuizaLabs (LuizaLabs)

Automatizando a ingestão de dados no data lake (LuizaLabs)

O que aprendi como cientista de dados no Magalu (LuizaLabs)

Interleaving: Uma nova maneira de se fazer testes A/B (Loft)

Encontrando zonas de valor em SP com machine learning (Loft)

MASP — Nosso framework de marketing digital (Loft)

Usando embeddings e sinais de navegação para identificar apartamentos similares (Loft)

xgbse: Análise de Sobrevivência robusta e eficiente em Python (Loft)

Indo além de previsões pontuais de preços de imóveis (Loft)

Data & Decision Science Loft: nosso Chapter, em dados (Loft)

Data & Decision Science Loft: nosso ecossistema de algoritmos (Loft)

O poder da Análise de Sobrevivência no mercado imobiliário (Loft)

A Jornada de recrutamento para o time de Ciência de dados da Loft (e algumas dicas) (Loft)

Começando a carreira em ciência de dados na Loft (Loft)

Sistemas de recomendação (Grupo ZAP)

Como funciona a área de dados em Design, Produto e Engenharia do Grupo ZAP? (Grupo ZAP)

Revisão de análises exploratórias por pares no Grupo ZAP (Grupo ZAP)

Usufruindo de técnicas Agile para entregar valor com dados (Grupo ZAP)

We don’t need everyone to be a Data Scientist (Creditas)

Quando o Teste A/B não é o suficiente: melhorando suas escolhas com Multi-Armed Bandit (Creditas)

Como dar mais agilidade nas entregas do time de Data Science (Creditas)

Design de Interfaces e Experiência do Usuário

Entrevistas com usuários: dicas para coletar insights (iFood)

Nosso processo de organização de arquivos no Figma (iFood)

Construindo um time de Design cada dia melhor (Loft)

Figma Variants — Como uma mudança de paradigma impactou nosso trabalho (Loft)

Engenharia de Software

TDD no Android (iFood)

Mergeando uma feature com 200 PRs (iFood)

Testes automatizados em React (LuizaLabs)

Métricas Ágeis: O que o Lead Time e o Throughput revelam para nós? (LuizaLabs)

Daily orientada a fluxo e não nas Pessoas (LuizaLabs)

Introdução a Upstream Kanban com base em experiências no LuizaLabs (LuizaLabs)

Pull/Merge Requests: seguindo boas práticas (LuizaLabs)

Para onde está indo a energia do seu time? (LuizaLabs)

Circuit Breaker: lidando com falhas em micro serviços (LuizaLabs)

Descomplicando a Clean Architecture (LuizaLabs)

Pirâmide de Testes — Definindo uma boa suíte de testes para seu Software (LuizaLabs)

Os benefícios de trabalhar com poucos itens por vez (LuizaLabs)

Postmortem: Como lidamos com falhas no LuizaLabs (LuizaLabs)

Criando uma aplicação modular muito além do Clean Architecture (LuizaLabs)

As diferenças de ser um Usuário da linguagem e um Especialista da linguagem (LuizaLabs)

Revisão de código: Boas práticas para garantir a qualidade (Grupo ZAP)

Começar e manter uma suíte de testes (Grupo ZAP)

O que aprendi com as mudanças de uma arquitetura monolítica para micro serviços (Grupo ZAP)

Como descobrir seu fluxo de entregas com o CFD. (Grupo ZAP)

Pare de começar e comece a terminar. (Grupo ZAP)

Pensando melhor sobre conexões HTTP (Grupo ZAP)

Prometheus — Monitorando a saúde da sua aplicação (Grupo ZAP)

Facade para organização de Microservices (Grupo ZAP)

Migração sem sofrimento (Grupo ZAP)

Como ser uma pessoa desenvolvedora melhor? (Grupo ZAP)

GraphQL a bala que não é de prata, mas ajuda bastante :) (Grupo ZAP)

Grafos, teoria e aplicações (XP Inc.)

Criando uma API RESTful com NodeJS e Express — Inicializando o projeto e o método GET (XP Inc.)

Design Patterns (XP Inc.)

Regex: Um guia prático para expressões regulares (XP Inc.)

React: Usando Tabela virtual para lidar com grandes quantidades de dados (XP Inc.)

Comparando os termos utilizados no NoSQL com SQL (XP Inc.)

Design de Sistemas Distribuídos — Introdução a Design de Sistemas e Sistemas Distribuídos (XP Inc.)

Design de Sistemas Distribuídos — Escalonamento Vertical e Horizontal (XP Inc.)

Design de Sistemas Distribuídos — Balanceamento de Carga (Load Balancing) (XP Inc.)

Event Storming — Guia básico (XP Inc.)

Como aplicar práticas de Clean Code? (XP Inc.)

Web Components: Criando componentes de forma agnóstica (XP Inc.)

Trabalhando com o Gitflow (XP Inc.)

TI de alta performance — Introdução e Métricas DevOps- Parte 1 (XP Inc.)

Métodos do ciclo de vida de componentes ReactJS — Um mergulho profundo! (Creditas)

O poder de um mindset ágil (Creditas)

Service Workers: Dicas de desenvolvimento (Creditas)

Test-Driven Development é Desnecessário! (Creditas)

A pirâmide de testes (Creditas)

Feature Toggle (Creditas)

Oi, entrei há pouco tempo na empresa, como crio e faço deploy de novas aplicações? (Creditas)

Parear ou não Parear? Eis a questão — Parte I (Creditas)

Parear ou não Parear? Eis a questão — Parte II (Creditas)

Parear ou não Parear? Eis a questão — Parte III (Creditas)

Tratamento de erros em produção (Magnetis)

Fazendo uma aplicação em Vue.js com TDD — Um guia extensivo para quem quer aprender — parte 1 (Magnetis)

Fazendo uma aplicação em Vue.js com TDD — Um guia extensivo para quem quer aprender — parte 2 (Magnetis)

Fazendo uma aplicação em Vue.js com TDD — Um guia extensivo para quem quer aprender — parte 3 (Magnetis)

Revisão de Código (Arquivei)

Testes unitários: um olhar para a qualidade de nossos testes (Arquivei)

Compatibilidade de Browser (Arquivei)

Gestão de Produto

Como organizamos e documentamos o trabalho de Produto e Design no iFood (iFood)

Produto e síndrome do heroísmo (iFood)

Até onde vai a nossa empatia? (Movile)

Escrevendo boas descrições para suas issues (LuizaLabs)

Na prática, o que uma Product Manager faz? (Loft)

#1 Cultura de Produto: Product Discovery na prática! (XP Inc.)

#2 Cultura de produto: Project Manager vs Product Manager (XP Inc.)

#4 Cultura de Produto: Product Manager vs Product Owner (XP Inc.)

Habilite a Autonomia dos Desenvolvedores com Refining (Creditas)

Desmistificando o Processo de Product Discovery (Creditas)

Changelog

Nada.

Quantifying Customer Experience

A tech company’s relationship with its customers has become an important lever of growth (examples such as Nubank and Zappos come to mind). Yet, the effects of providing an above average customer experience are still seen as hard to track. Thus, customer experience (and/or customer success, customer support and other highly customer-oriented teams) end up commonly treated as a soft discipline.

But digital businesses are uniquely positioned (at least when compared to their away-from-keyboard counterparts) to better understand how customer experience affects their bottom line by measuring results and analyzing customer-related data.

Measuring key customer-related results

The Net Promoter Score (NPS) is a long-term customer relationship indicator that surveys customers with one specific question: “On a scale of 0 to 10, how likely are you to recommend us to a friend or colleague?” We may consider who scored 9 or 10 as product or service promoters, while those who score 7 or 8 are considered passives, and six or below are classified and detractors.

It is often referred to as a brand or company-customer relationship indicator as a whole, since it aims to capture a sum of each person experience with said product or service.

The Customer Satisfaction Score (CSAT) is a short-term customer relationship indicator which surveys how satisfied a customer is with a recent interaction (often a purchase or a customer support issue).

An indicator related to CSAT is the Product Satisfaction Score (PSAT), an adaption of the former focused on measuring short-term satisfaction and gathering contextual feedback on a specific product or feature.

The Customer Effort Score (CES) measures how much effort customers spent on a specific interaction or process (often customer support and/or product onboarding, which are important drivers of product usage).

Analyzing customer feedback

Customer feedback analysis may be defined by executing three main tasks:

1. Processing unstructured data (i.e., tagging customer support tickets);
2. Analyzing processed data (i.e., customer support tags frequency);
3. Translating customer data insights into product and/or service improvements;

Even though those tasks are equally important, translating insights into improvements means avoiding the pitfalls of being ‘data rich, but insight poor’. Non-insightful data provides already known information, whereas insightful data leads to disproving current assumptions, confirming a certain hypothesis, or quantifying the importance level of specific issues.

Customer Operations metrics and indicators

The Tickets by Assignee metric measures how workload is evenly (or unevenly) distributed across customer support agents considering a certain period of time.

Tickets by Assignee = absolute number of filed tickets by assignee

The Number of Tickets Filed metric measures how workload fluctuates across a certain period of time.

Number of Tickets Filed = sum of filed tickets within a timeframe

The Tickets by Channel metric measures how workload is distributed across communication channels considering a certain period of time.

Tickets by Channel = absolute number of filed tickets by channel

The Tickets by Tag metric measures how frequently each tag is attributed to tickets filed by customers to a customer support team.

Tickets by Tag = absolute number of tickets by attributed tag(s)

The Average First Response Time (AFRT) is an indicator which measures how long a customer needs to wait before receiving an initial response to their support request. Acceptable times before a first response vary across industries and communication channels, for example, while social media questions are expected to receive an answer within 24 hours, a chat interaction is expected to be answered within a few minutes or even seconds.

Average First Response Time (AFRT) = sum of elapsed time until a first response to each customer support ticket is given divided by the absolute number of filed tickets within a timeframe

The Average Reply Time (ART) is an indicator measures how long it takes to follow up to customers on all interactions, including first responses. However, this indicator is subject to being affected by outliers (an unexpected outage on a key partner API — application programming interface, for example). An alternative to minimizing outliers’ effect on the ART is using Response Time Bands (RTB) chart to view the percentage of tickets within a specific timeframe.

Average Reply Time (ART) = sum of elapsed time until each and all customer messages are answered divided by the absolute number of customer messages received within a timeframe

The First Contact Resolution Rate (FCRR) is an indicator which measures what percentage of support tickets are solved in a single interaction, an important proxy on process efficacy and customer retention.

First Contact Resolution Rate (FCRR) = sum of all customer support tickets solved in a single interaction divided by the absolute number of filed tickets, and multiplied by 100 within a timeframe

The Average Number of Replies per Request (ANRR) measures how many touch-points are required to solve a customer request, an indicated of how autonomous a support team is and how efficiently their issue routing process operates.

Average Number of Replies per Request (ANRR) = sum of each and all occured customer touchpoints (i.e., received messages) divided by the absolute number of filed tickets

The Average Resolution Rate (ARR) measures which percentage of support requests are solved considering the amount of tickets received. This indicator may help in diagnosing bottlenecks regarding number of tickets received, number of agents on the team, and the complexity of said issues.

Resolution Rate (RR) = sum of all solved tickets divided by the absolute number of filed tickets, and multiplied by 100 within a timeframe

Disaggregating customer indicators for additional insights

When dealing with indicators associated with unstructured data (i.e., tagged customer support tickets or NPS comments) it is possible to use a simple technique to understand how much certain issues affect the overall score.

For example, consider a database of tagged customer support tickets, you may calculate both the overall AFRT and the impact of delayed shipping tickets by excluding all shipping-related issues from the later calculation before comparing them.

Closing remarks

While customer experience always will present a considerable degree of subjectivity, measuring and analyzing data are elementary practices when aiming to establish a data-informed culture within a company. This remains true whether referring to tech or non-tech companies. I hope this content helps you in taking first-steps into customer analytics practices.

Marc Andreesen é um investidor de risco (venture capitalist) americano e sócio-fundador do Andreesen Horowitz (a16z). Esse texto é um apanhado de “melhores momentos” daquilo que ele escreveu em “Guide to Career Planning”. Tomei bastante liberdade na adaptação.

I. Planejar = limitar

Primeira regra do planejamento de carreira: não planeje a sua carreira.

O mundo é complicado e as coisas mudam rápido. É por isso que “planejar sua carreira” num sentido tradicional não faz diferença. Você não pode adivinhar o que vai acontecer no futuro. Não pode adivinhar em qual setor vai trabalhar. Não pode adivinhar quais posições vai ocupar. Não pode adivinhar onde você vai morar. Não pode adivinhar qual será sua contribuição para o mundo.

II. Desenvolver habilidades + Perseguir oportunidades

Segunda regra do planejamento de carreira: foque em desenvolver habilidades e perseguir oportunidades.

Desenvolver habilidades

Uma das principais forma de desenvolver habilidades na vida é a educação formal. As pessoas costumam dizer “estude o que você gosta”. Eu diria “estude algo concreto e útil para o mundo real”: engenharia, ciências, matemática ou economia. Tenho alguns motivos para dizer isso:

• Educação técnica costuma envolver assuntos difíceis e úteis, algo que te prepara “pelo caminho da dor” a não ter medo de entender coisas difíceis.
• Pensar como um engenheiro, matemático, cientista ou economista desenvolve uma forma de pensar rigorosa e que recorre à razão, lógica e dados;
• Educação técnica tende a despertar uma “impressão positiva” de seus futuros pares;

Adquirir conhecimento técnico é partir pra guerra com um rifle em mãos.

Não adquirir conhecimento técnico é partir pra guerra carregando uma faca cega.

Conselhos sobre educação formal

• Busque estudar nas melhores escolas que puder, pois nelas estão os melhores colegas e oportunidades;
• Busque adquirir experiência prática: estágios, projetos extracurriculares, etc;

Após sair da escola posso dizer que existem dois caminhos para continuar desenvolvendo suas habilidades:

1. ser O MELHOR em uma coisa específica;
2. ser MUITO BOM em três ou quatro coisas diferentes;

Indico a segunda opção e recomendo desenvolver uma ou mais das seguintes habilidades:

Comunicação (escrita, oral, etc. Pelo menos um tipo de comunicação.);

Gestão de pessoas;

Vendas;

Finanças;

Assuntos internacionais;

Perseguir oportunidades

Podemos entender oportunidade em dois sentidos distintos: oportunidades por sorte (“no lugar certo, na hora certa”) e oportunidades por competência (“enxerguei uma situação favorável e aproveitei a chance”).

Exemplos de oportunidade por sorte:

• Alguém do lugar onde você trabalha precisa de alguém para ajudar num projeto importante;
• Alguém que estudou com você está trabalhando numa startup em ascensão e te convida para trabalhar lá;
• Seu grupo de amigos da faculdade resolve te chamar para começar um negócio;

Aproveitar esses tipos de oportunidade define pessoas que desenvolvem a carreira MUITO rápido e pessoas que desenvolvem a carreira num ritmo “médio”.

Oportunidades por competência = estratégia de investimentos

Aproveitar oportunidades por competência significa “ir atrás e fazer acontecer”. Contudo, isso não é sinônimo de perseguir oportunidades aleatoriamente. Pelo contrário, é pensar numa estratégia e abordar a carreira como um portfólio de empregadores, cargos e oportunidades: cada um desses fatores carrega consigo risco e retorno.

Contextos de risco em oportunidades por competência:

• Alguém que acabou de concluir a faculdade e possui baixo custo de vida tem uma margem relativamente maior para priorizar o desenvolvimento de habilidades e a aquisição de experiência em detrimento de um salário um pouco mais alto;
• Alguém que precisa sustentar a família não tem tanta margem para tolerar salários inferiores e priorizar habilidades e experiência, obviamente. Ainda assim, caso essa pessoa tenha maior probabilidade de recolocação no mercado de trabalho, a margem para tolerar um nível de risco maior aumenta;

III. Onde trabalhar e por quê

Trabalhe num setor onde os fundadores das principais empresas que o constituem ainda estão vivos e ativamente envolvidos nos negócios. Isso é um ótimo indicativo de crescimento, mudança e oportunidades. Setores velhos e solidificados tendem promover menos carreiras de crescimento rápido.

Trabalhe em empresas que lideram seus respectivos setores. Evite ser peixe grande em lagoa pequena. Isso limita suas habilidades e oportunidades.

More em grandes centros. Os setores e empresas de destaque nem sempre estão geograficamente próximos de onde você vive.

Trabalhe em empresas que mudaram profundamente seus respectivos setores. Isso não é sinônimo de empresas “importantes” ou “marcas prestigiosas”.

Se você quer trabalhar com tecnologia, o melhor lugar para começar é numa empresa que cresce rápido. Você fará bastante coisa, provavelmente será promovido logo e se acostumará com ambientes em constante mudança, pessoas inteligentes e expectativas altas.

Trabalhar em empresas tradicionais: você será treinado para trabalhar em empresas tradicionais.

Trabalhar em startups: pode dar muito certo, pode dar muito errado. Nem sempre é o ideal para desenvolver habilidades e adquirir experiência.

Trabalhar em empresas pequenas ou médias que não estão crescendo: evite.

Todo emprego, todo cargo, toda empresa é uma oportunidade para aprender sobre como aquele negócio e aquele setor funcionam.

Transformadores de percepção

Dizem por aí que para ser um bom profissional é preciso saber resolver problemas. Bom… Só trabalhei em startups durante a minha carreira e, com certeza, sei que isso é verdade para quem trabalha no time de atendimento ao cliente.

Em linhas gerais, o propósito de um time de atendimento é resolver problemas dos clientes, responder perguntas e — o mais importante — moldar a percepção desses clientes sobre a marca.

Não existem heróis sem vilões

Claro, um time de atendimento não está sozinho nessa missão. A depender da organização de cada empresa, esse time faz parte da estrutura de Experiência do Cliente ou Sucesso do Cliente. Contudo, o escopo de atuação de um time de atendimento costuma ser definido pela ajuda e/ou orientação prestadas nas interações entre cliente e produto ou serviço.

A interação entre cliente e produto ou serviço sempre terá vilões, isso é fato. Interfaces pouco intuitivas, bugs de software, casos de uso não previstos durante o planejamento de uma funcionalidade, pedidos de novas funcionalidades ou perguntas e dúvidas sobre o setor o qual a empresa pertence… Não é questão de se, é questão de quando.

Grandes poderes, grandes responsabilidades

Nem sempre um time de atendimento terá poder para “derrotar seus vilões”. Algumas vezes terá condições totais para isso, mas não se dará conta. Muitas vezes encontrará oportunidades de transformar a percepção do cliente: resolver o problema de forma tão elegante que o cliente quase terá vontade de arrumar outro problema só para ser agraciado com um nível de serviço tão excepcional! Um time de atendimento é o principal responsável por lidar com essas situações, mas antes: como sei em qual dessas situações me encontro?

Diagnóstico é um superpoder: tem que entender o cliente!

Sem entender o cliente não será possível resolver problemas, responder dúvidas ou passar orientações. Sem entender o cliente não é possível moldar percepções. Pelo contrário, qualquer ação tomada antes de verdadeiramente entender o cliente não passa de tentativa e (na maioria das vezes) erro.

Costumo me referir ao entendimento do cliente e seu contexto como diagnóstico. Esse modelo mental (representação simples de como algo funciona) é composto por duas perguntas-chave:

1. Qual era o comportamento esperado?
2. Qual foi o comportamento realizado?

Qual era o comportamento esperado?

Comportamento esperado: perguntas norteadoras

Você entendeu o que o cliente queria fazer?

Qual era o resultado esperado por essa pessoa?

Você está falando com ela antes da tomada de ação relacionada a esse objetivo?

Você está falando com ela após essa tomada de ação?

Cenário fictício: tentei fazer um pedido de comida através de um aplicativo e encontrei tela de erro no momento do pagamento com cartão de crédito.

Nesse momento pouco importa a causa do erro. Sendo sincero, é muito improvável que você descubra a causa do erro a partir de pouquíssima informação. Além disso, uma eventual solução pode nem sequer depender do time de atendimento. O mais importante é entender qual resultado aquela pessoa queria alcançar:

Entendendo o comportamento esperado num cenário fictício

O cliente queria fazer um pedido imediato?

O cliente queria fazer um pedido agendado?

O cliente queria fazer uma assinatura de serviço?

Armas de descoberta do comportamento esperado:

Armas de descoberta

Conhecimento (próprio ou documentado) de produto;

Conhecimento (próprio ou documentado) de negócio e setor;

Ferramentas e sistemas internos, CRMs e afins;

Perguntando ao cliente;

Qual foi o comportamento realizado?

É agora que vamos partir para a causa do erro? Não. Agora o mais importante é entender o que aconteceu de fato.

Perguntas norteadoras: comportamento realizado

Em qual etapa do processo ele está? Ou seja, em qual tela ele se encontra?

Foi apresentada uma tela de erro?

O erro acontece em qualquer contexto ou apenas em contextos específicos?

Quando aconteceu esse problema?

Fazer todas essas perguntas ao cliente configuraria um interrogatório, não é uma experiência legal. De novo, use as armas de descoberta para entender o comportamento realizado:

Armas de descoberta

Conhecimento (próprio ou documentado) de produto;

Conhecimento (próprio ou documentado) de negócio e setor;

Ferramentas e sistemas internos, CRMs e afins;

Perguntando ao cliente;

Comportamento esperado + comportamento realizado = mágica

É impossível resolver um problema, responder dúvidas ou passar orientações sem entender onde cada cliente quer chegar e onde esse mesmo cliente de fato chegou.

Entender qual é o comportamento esperado e qual foi o comportamento realizado significa isso: entender onde o cliente quer chegar e onde ele chegou. Por que isso importa? Porque é assim que temos sucesso chegando à causa e resolução de problemas, respondemos dúvidas e passamos orientações.

Sem entender onde o cliente quer chegar e onde ele chegou, nenhum time de atendimento é empoderado. Sem entender onde o cliente quer chegar e onde ele chegou nenhuma percepção sobre a marca é transformada.

Iniciativa Resolvedores

Nem sempre um time de atendimento terá as habilidades necessárias para “derrotar certos vilões”. Ainda assim, esse time é o principal responsável por recrutar e informar a atuação de gestores de atendimento, além de times de produto, desenvolvimento de software e outros.

Um caso à parte é o diagnóstico e relato de bugs, que exige ainda mais aprofundamento no entendimento do comportamento realizado:

Perguntas norteadoras: diagnóstico e relato de bugs (comportamento realizado)

Qual o impacto desse comportamento para o cliente?

Estou diante de uma questão de interface (tela de erro, mas o processamento foi concluído)?

Estou diante de uma questão de de processamento interno(tela de sucesso, mas o processamento não foi concluído)?

Estou diante de uma questão de interface e processamento interno?(tela de erro e processamento não concluído)?

Como faço para reproduzir o comportamento realizado?

Qual o dispositivo e/ou versões da aplicação sendo utilizados?

Quais vídeos demonstram o comportamento realizado? Em qual momento do vídeo o comportamento acontece?

Quais screenshots demonstram o comportamento realizado? Qual a área do screenshot demonstra esse comportamento?

5 leis dos times de atendimento empoderados

Um time de atendimento empoderado conhece seu produto ou serviço.

Um time de atendimento empoderado conhece seu negócio e setor.

Um time de atendimento empoderado usa as melhores ferramentas da melhor forma possível.

Um time de atendimento empoderado é capaz de fazer as perguntas certas.

Um time de atendimento empoderado recruta e informa a atuação de gestores e de outros times.

No fim do dia as pessoas são o propósito.

Texto dedicado a Alérison, Ana, Bia, Gab, Karine, Karol, Malu, Marcos, Mariana, Mel, Nassim, Pamela e Raquel.

What is ‘How To Build a Top Tech Company’?

This is a high-quality technical content aggregator made for everyone interested in building successful technology companies.

Why am I doing ‘How To Build a Top Tech Company’?

I’m quoting Steve Jobs on this one:

Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things.

I won’t create something new or solve hard problems if I’m only thinking about ‘How to Build a Neobank’.

And the reason they were able to do that was that they’ve had more experiences or they have thought more about their experiences than other people. Unfortunately, that’s too rare a commodity. A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have.

I’m doing this because I want to improve my chances of creating something new and solving hard problems by having enough ‘tech-company-dots’ to connect.

How may I help ‘How To Build a Top Tech Company’?

I’m presenting a ‘to-be-curated’ reading list at the end of this article. Feel free to read them and recommend new entries to be aggregated. Just comment, reply or something. I’m also available on LinkedIn, if you want to send me a connection request: Paulo Silveira.

Fast travel to section

Strategy, People and Culture
Customer Experience
Data & Analytics
Design & UX
Engineering
Product
Marketing & Growth

Fast travel links may not function properly on iOS.

Strategy, People and Culture

Starting an Initiative (Slack)

The Zen of an Ideal Team (Gojek)

The Dynamics of Scaling an Organization (Gojek)

How Grubhub remote employees stay productive (Grubhub)

Spotify Technology Career Steps (Spotify)

Things We Learned Creating Technology Career Steps (Spotify)

First things first, Trust each other (Spotify)

Creating a culture of accessibility (Dropbox)

Hiring your first 10 engineers (Coinbase)

You Are Your Own Best Hype Person (Square)

Leadership, Management, and Tribes (Square)

Are the Best Decisions Instinctual, or Data-Driven? (LinkedIn)

Every Day Is Monday in Operations (LinkedIn)

Site Up (LinkedIn)

What Gets Measured Gets Fixed (LinkedIn)

Do Your Best and Never Give Up (LinkedIn)

MTTD and MTTR Are Key (LinkedIn)

Attack the Problem not the Person (LinkedIn)

You’re Only as Good as Your Lieutenants (LinkedIn)

Don’t Assume Anything (LinkedIn)

Communication, Communication, Communication (LinkedIn)

The Code Doesn’t Lie (LinkedIn)

Failure Is Not an Option (LinkedIn)

Customer Experience

Using Causal Inference to Improve the Uber User Experience (Uber)

Improving the User Experience with Uber’s Customer Obsession Ticket Routing Workflow and Orchestration Engine (Uber)

Applying Customer Feedback: How NLP & Deep Learning Improve Uber’s Maps (Uber)

Improving Driver Communication through One-Click Chat (Uber)

Scaling Uber’s Customer Support Ticket Assistant (Uber)

Thank You for Your Feedback: Improving the Uber Engineering Workflow with uRate (Uber)

Improving Uber Customer Care with NLP & Machine Learning (Uber)

Architecting Uber Support with Customer Obsession Engineering (Uber)

Using neural networks to predict customers’ needs (Square)

Data & Analytics

Decision Scientists at Gojek — The Who, What, Why (Gojek)

Building A Data Science Product in 10 Days (Instacart)

An introduction to Decision Engineering (Grubhub)

How We Improved Data Discovery for Data Scientists at Spotify (Spotify)

Pinterest Trends: Insights into unstructured data (Pinterest)

How Data Science Helps Power Worldwide Delivery of Netflix Content (Netflix)

Data Science and the Art of Producing Entertainment at Netflix (Netflix)

How Our Paths Brought Us to Data and Netflix (Netflix)

Analytics at Netflix: Who We Are and What We Do (Netflix)

Mythbusting the Analytics Journey (Netflix)

Democratizing data analysis with Google BigQuery (Netflix)

Discovery and Consumption of Analytics Data at Twitter (Twitter)

How we think about data at Coinbase (Coinbase)

So You Have Some Clusters, Now What? (Square)

4 Principles for Making Experimentation Count (Airbnb)

Automated Machine Learning (Airbnb)

How Airbnb Democratizes Data Science With Data University (Airbnb)

Selection Bias in Online Experimentation (Airbnb)

Helping Guests Make Informed Decisions with Market Insights (Airbnb)

Fighting Financial Fraud with Targeted Friction (Airbnb)

Learning Market Dynamics for Optimal Pricing (Airbnb)

How Airbnb is Boosting Data Literacy With ‘Data U Intensive’ Training (Airbnb)

Discovering and Classifying In-app Message Intent at Airbnb (Airbnb)

Empowering Data Science with Engineering Education (Airbnb)

Advice for New Data Scientists (Airbnb)

Using Machine Learning to Predict Value of Homes On Airbnb (Airbnb)

Data Quality at Airbnb (Airbnb)

Visualizing Data Timeliness at Airbnb (Airbnb)

Top Five Lessons from Running A/B Tests on the World’s Largest Professional Network (LinkedIn)

Who Are You? A Statistical Approach to Protecting LinkedIn Logins (LinkedIn)

Making Hard Choices: The Quest for Ethics in Machine Learning (LinkedIn)

Behind “Big Data” and “AI”: Elements of Modern Data Science (LinkedIn)

An Introduction to AI at LinkedIn (LinkedIn)

LinkedIn Sales Insights: Quality data foundations for smarter sales planning (LinkedIn)

Design & UX

Prototyping at Slack (Slack)

How to Fail at Accessibility (Slack)

On working with designers (Dropbox)

Redesigning the Pinterest Homepage (Pinterest)

Documentation Details Matter (Square)

Improving Conversion Rates with Analytics, Design Principles, and UX (Square)

Engineering

Good bug reports lead to great bug fixes (Gojek)

How We Do What We Do at GOJEK (Gojek)

Spotify engineering culture (part 1) (Spotify)

Spotify engineering culture (part 2) (Spotify)

Building a technical career path at Spotify (Spotify)

How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (Spotify)

Lessons learned in incident management (Dropbox)

Your System is not a Sports Team (Dropbox)

Embracing papercuts (Dropbox)

Don’t lead by example (Dropbox)

A Pinterest Engineering guide to technical interviews (Pinterest)

Three-day no-meeting schedule for engineers (Pinterest)

Building a faster mobile web experience with AMP (Pinterest)

Python at Netflix (Netflix)

How we built Twitter Lite (Twitter)

The Infrastructure Behind Twitter: Scale (Twitter)

Surviving the Brazilian Reality TV Surge that Pushed Twitter to the Edge (Twitter)

Rebuilding Twitter’s public API (Twitter)

Manhattan software deployments: how we deploy Twitter’s large scale (Twitter)

What are Coinbase’s Engineering Principles? (Coinbase)

You need more than one AWS account: AWS bastions and assume-role (Coinbase)

Remote Engineering at Coinbase (Coinbase)

How One Eng Team Works (Coinbase)

How To Be a More Influential Engineer (Square)

Soft-skills Reading List (Square)

Messaging Sync — Scaling Mobile Messaging at Airbnb (Airbnb)

React Native at Airbnb (Airbnb)

React Native at Airbnb: The Technology (Airbnb)

Introducing Pipelines to Airbnb’s Deployment Process (Airbnb)

From Good to World-Class: What Makes Software Engineers Excel at their Craft (LinkedIn)

Scaling Decision-Making Across Teams within LinkedIn Engineering (LinkedIn)

Managing documentation at scale (LinkedIn)

Rebuilding messaging: How we bootstrapped our platform (LinkedIn)

Rebuilding messaging: How we designed our new system (LinkedIn)

How LinkedIn turned to real-time feedback for developer tooling (LinkedIn)

The Modular Monolith: Rails Architecture (Root)

Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity (Shopify)

Product

The Joy of Internal Tools (Slack)

Cracking the Code to build an All-Star Product team (Gojek)

Running premortem analysis — imagining failure to ensure success (Grubhub)

Understanding Why Product Changes Work (and Don’t Work) (Uber)

How we do large scale retrospectives (Spotify)

Seven best practices for inclusive product design (Pinterest)

Building a product engineering culture at Pinterest (Pinterest)

Product Analytics at Square (Square)

Product planning for machine learning (Square)

Contextual Calendar Reminders (Airbnb)

Marketing & Growth

A better click-through rate: How Pinterest upgraded everyone’s favorite engagement metric (Pinterest)

How we use AutoML, Multi-task learning and Multi-tower models for Pinterest Ads (Pinterest)

How Pinterest Supercharged its Growth Team With Experiment Idea Review (Pinterest)

Lessons in growth engineering: How we doubled sign ups from Pin landing pages (Pinterest)

How we increased active Pinners with one simple trick (Pinterest)

Lessons in growth and increasing signups (Pinterest)

Discover Pinterest: Data Driven Growth (Pinterest)

Growing Our Host Community with Online Marketing (Airbnb)

The Science of Quality Growth (LinkedIn)

To-be-curated reading list

Coursesity: Engineering Blogs

sumodirjo’s GitHub project: Engineering Blogs

Changelog

How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (Spotify) on Aug 01, 2021.

Você já ouviu o mesmo episódio de podcast várias vezes? Eu já… Ouvi centenas de vezes os mesmos 215 minutos e 35 segundos de Naval Ravikant: empreendedor e investidor early-stage de empresas como Uber, Twitter, Notion, Clubhouse, Stack Overflow e outras.

Mesmo depois dessas centenas de vezes, ainda não me sinto confortável em escrever sobre o episódio com pretensão de propriedade sobre o que é dito.

Mesmo assim, fiz uma breve (e espero que convidativa) apresentação textual dos minutos iniciais da combinação mais interessante que já encontrei na minha vida: microeconomia, computação e empreendedorismo.

O que é riqueza?

É a fábrica usando robôs na linha de produção, é o programa de computador servindo seus clientes, é o dinheiro no banco sendo reinvestido em outros ativos e empresas.

Riqueza é o ativo que rende enquanto você dorme.

Por que desejar riqueza?

Riqueza serve para comprar liberdade: largar a roupa social do escritório, parar de acordar 6h da manhã para se arrumar e pegar o metrô, desperdiçar sua vida jogando horas produtivas no lixo por causa de um trabalho sem alma ou propósito.

A função da riqueza é dar liberdade. Não é comprar roupas caras, Ferraris ou iates. Esse tipo de coisa enjoa rápido. Riqueza é sobre ser um indivíduo independente.

Todo mundo pode ser rico?

A riqueza não é um jogo de soma-zero. Riqueza é criação de abundância. Por exemplo, todo mundo pode ter uma casa. O fato de você ter uma casa não me impede de ter uma casa. Pelo contrário, quanto mais casas existirem, melhor ficamos em construir casas.

Toda a riqueza da civilização humana foi criada: pessoas, ideias, tecnologias, produtividade e trabalho duro. É por isso que uma pessoa vivendo num país de terceiro mundo hoje é mais rica que um aristocrata francês do século XVI.

Tecnologia é o caminho da riqueza

Tecnologia é ciência aplicada com o propósito de criar abundância. Imagine se a partir de amanhã todo ser humano tivesse o conhecimento de um bom engenheiro de hardware ou software. Todo ser humano dominando o conhecimento necessário para construir robôs, computadores, pontes e programas de computador.

Como essa sociedade hipotética estaria daqui a há 20 anos? Vivendo em abundância e com todas as necessidades básicas da humanidade satisfeitas por meio da automação tecnológica.

Ninguém fica rico vendendo horas de trabalho

Quase todo trabalho assalariado tem uma relação de equivalência entre esforço e recompensa. Você é pago para trabalhar por X horas todos os dias. Quando está dormindo, não ganha nada. Quando está no metrô lotado, não ganha nada. Basicamente, você é substituível e em algum momento uma máquina tomará o seu lugar.

Se você quer ficar rico, precisa de um emprego, carreira ou profissão onde o esforço é desproporcional à recompensa. Busque oportunidades onde uma hora de trabalho pode multiplicar o resultado em mil vezes ou, logicamente, mil horas de trabalho podem levar a nenhum resultado.

Gerar riqueza é trabalhar com o que a sociedade quer, mas ainda não sabe como conseguir

A questão é entender o que você pode fornecer à sociedade, algo que ela não saiba que precisa e que esteja dentro da sua capacidade. O próximo passo é descobrir como escalar isso.

O Steve Jobs e a equipe que trabalhava com ele entenderam que a sociedade queria celulares. Um computador de bolso que fosse fácil de usar e oferecesse todas as funcionalidades de um telefone comum multiplicadas por 100. Depois disso, descobriam como construir e escalar o iPhone desde a sociedade de alto padrão até as massas.

Na Internet a escala é viral e a autenticidade é a cura

A Internet é um meio de acesso virtual aos 7 bilhões de seres humanos no planeta. Por mais que aquilo que você faça não agrade bilhões de pessoas, é possível alcançar 50 mil pessoas que gostam daquilo que você faz. A Internet te dá escala. Contudo, o fácil acesso e a possibilidade de escala sempre atraem a competição.

O antídoto para o veneno da competição é autenticidade. Ninguém pode vencê-lo em ser você mesmo.