We document

<aside> ✏️ We take the time to write things down because it helps us move faster.

*- Meetings always have an agenda, shared in advance.

</aside>

We believe that a team’s documentation practices are one of the best predictors of its velocity. The best-performing teams we’ve been on have been zealots about documentation, and the opposite is true for the worst. When documentation is healthy, new folks onboard quickly, meetings are a good use of time, and workload is balanced across individuals — and that’s just the beginning.

We know that this doesn’t happen automatically, nor is it free. Everyone has to take part, we must hold each other accountable, and we need to make these investments even when they slow us down in the present. That’s okay, because documentation is real work. And, yes, sometimes things should be simplified or automated first, but that’s no excuse to do nothing. We start by choosing action.

Like our other principles, this one is not an absolute. There will be times when we decide not to document, but we will restore the balance shortly thereafter.

We move at the pace of customer discovery

<aside> ⛵ Our product development process moves in lock-step with customer discovery.

- We validate problems through customer discovery before starting new initiatives. *- Schedule at least one customer meeting every week that anyone can join.

</aside>

Ours is a path beset by traps. Many people have tried to solve the Marketing ROI problem, and many have failed. We will be successful not because we are smarter or work harder, but because we are more disciplined and because we ask the customer the right questions. Like any software company, we experiment and iterate to find the right product to bring to market. However, compared to other companies, we need to make larger investments in customer discovery to know what we should build. Our intuition, alone, won’t get us where we need to go.

This means that, most of the time, when we have an idea we would be better off talking to a customer than building a prototype. The customer doesn’t know what the solution to their problem looks like, but they do know what their problem feels like, and if we’re not 100% sure they’ve already told us, it’s time to ask.

We’ll validate concepts through user testing before we write code, and not the other way around.

We ship it when it’s done

<aside> ✅ We prefer success criteria and transparent progress to deadlines.

*- We debate prioritization, success criteria, and solution design — not timelines.

</aside>

We care a lot more about velocity (moving fast) than predictability (knowing when things will be done). We believe that the most important factors impacting velocity — things like number of engineers, their knowledge, the technical architecture — often have no impact on the predictability. Beyond that, when companies try to improve their predictability, they often hurt their velocity. People become stressed out, lose focus, and get less done.

So we focus on moving fast. To make this work, we expect a few things from each other:

We will, of course, have some deadlines we can’t avoid. We’re not pretending that we won’t. However, deadlines will be for the times when we don’t have a choice. The rest of the time we will ship it when it’s done.

We bring our constructive energy

<aside> ☀️ We keep the mood positive, even in difficult conversations.

*- We take responsibility for our failures, learn, and move on.

</aside>

We are committed to keeping a positive and buoyant (while genuine) work environment. We adopt a few principles to achieve this:

Of course, not everything is positive, and we can’t always be happy. If we’re not real, no one will respond to any positivity we try to spread, and if we don’t discuss our failures openly, we’ll never improve. Even so, we expect ourselves to keep these moments constructive and focused on the mission.