Wisdom in threes

I like to encapsulate little nuggets of wisdom about a particular topic in threes. Sometimes it’s a spectrum – from 1 to 3. Other times, it’s a breakdown of something into three parts.

Here’s my collection so far:

Marketing:

1. Brand marketing - who you are
2. Product marketing - what you sell
3. Growth marketing - how you sell it

(h/t Kevan Lee)

Education:

1. Tell - tell them how to do it
2. Show - show them how to do it
3. Do - do it with them

I find this applies to just about anything – from teaching my kids how to use a sharp knife in the kitchen to upleveling my teams’ product thinking and design skills.

Making Things:

1. Make it work
2. Make it fast
3. Make it right

Don’t worry about making it fast or right if it doesn’t yet work. When it works, you’ve earned the right to make it fast, delightful, performant, or beautiful. And finally, if you’re lucky, you can make it right, i.e., remove unnecessary complexity, optimize at the margins, make it extensible, and take it to the moon…

Software Debt:

1. Engineering debt - copy pasta
2. Product debt - v2 was a lie
3. Design debt - just add another tab

We talk a lot about tech debt but rarely dive into what it’s actually comprised of. We can refactor code, but if we’re refactoring the wrong thing – a useless feature or an overly complex user experience – reducing engineering debt is a waste of time.

Launching Software:

1. Code launch - launch internally
2. Product launch - launch to existing users
3. Marketing launch - launch to the world

Tl;dr launching something isn’t a singular event. And creating some nomenclature around the type of launch you’re doing dramatically simplifies cross-team communication and squashes unnecessary worry (Support: “$hit, we’re launching this to all our customers?!” Product: “Nope, just a code launch for us to dogfood internally.”).

Communication:

1. Say what you’ll do
2. Do it
3. Share what you did

It’s such a simple formula, yet we often spend most of our time on #2, a bit on #3, and almost always skip #1. Telling others what you will do is how you bring them along and make sure that when you finally do share what you did, it’s not the first time they’re hearing about it.

Using Data:

1. Aware - we know data exists
2. Informed - we inform our decisions with data
3. Driven - we make decisions with data

Data can be powerful to understand what is happening, but it will never tell you why something is happening. To build great products, you have to use taste, intuition, and data – all three in ratios that shift at each stage of a product’s lifecycle.

Building AI Features:

1. Enable - It’s now possible for me to “write” SQL queries
2. Accelerate - write a first draft for me or summarize the results for me
3. Eliminate - answer common customer support tickets so I don’t have to

I find this is helpful to articulate what sort of AI feature we’re building. Will it give a new segment of users superpowers? Will it save time or speed up the things people are already doing? Or will it completely change a paradigm by eliminating a whole class of tasks?

(h/t Intercom podcast)

Scaling Customer Research:

1. Discovery - talk to customers to understand what matters
2. Insights - create a script and interview 10s of customers
3. Data - run a survey with 100s of customers using questions from your script to generate data

This simple process is a great way to build intuition and collect data. It’s the qual/quant sandwich you need to build great products.

(h/t Oji Udezue)

Systems Complexity:

1. Simple systems - repeatable outcomes
2. Complex systems - mostly repeatable outcomes
3. Complex adaptive systems - stochastic outcomes

A simple system is like making toast. The same inputs will consistently produce the same outcomes. Complex systems are like building an airplane. We can still quantify the inputs and the overall process, but outcomes vary, quality control is needed, etc. Complex adaptive systems, on the other hand, are things like the economy. Modeling the inputs is impossible, and even then, the same inputs won’t yield the same outputs.

You can take complex adaptive systems a step farther and layer on the concept of chaotic sytems. A level 1 chaotic system does not react to predictions about it, i.e., the weather, whereas a level 2 chatotic ssytem does, like stock markets, politics, etc. Whoa.

(h/t Yuval Noah Harari’s Sapiens)

Temporal Basis of Teams:

1. Past - Support, success teams
2. Present - Engineering, marketing, and sales teams
3. Future - Design and product teams

I like to think about where a team is temporally rooted and how that affects their world view and decision making. For example, Support rightly cares about fixing bugs or revising past product decisions. Marketing lives largely in the present, communicating to customers what’s been built. And Design often thinks about what will eventually be, and so on. Each time period has different tensions and time horizons.