How to decide fast

The faster you make decisions, the quicker you'll move. The better those decisions are, the more successful you'll be. Start by building a data-informed culture.

Recently, my co-founder

Ben McRedmond

shared How to ship fast, a set of principles to help accelerate outcomes. But how do you make the decisions that drive those outcomes? And make those decisions better and faster? Data.

Unfortunately, most organizations don’t know how to establish a culture where data actively and appropriately informs decision-making. Here are a handful of principles I’ve learned and applied over 10+ years, creating organizations that deeply value and understand their data. 

---

1. Look at metrics every single day

Most companies organize their finances and pay bills monthly. They have board meetings and report quarterly. These are easy cycles to fall back to—even small startups that compete on speed fall back to reporting monthly or quarterly. A surefire way to create complacency around data is to fall back to these cadences. 

Decisions are made daily—often multiple times a day, particularly in startups. You need a set of metrics that match the cadence at which you’re making decisions. “But we don’t get enough signal or volume to look at our key metrics daily.” Fair enough; that’s often the case. Then, you should find an earlier indicator you can measure daily.

2. Deliver metrics where your team works

We build dashboards because we assume people will log in regularly to view them. But they don’t–people are lazy. No matter how important the dashboard or metric is, days are quickly consumed by meetings and never-ending to-do lists. Teammates will go weeks before logging in to view your beautiful dashboard. 

The fastest way to change how data gets used in an organization is to deliver it to them, where they’re already working. I know because I’ve done it. Sending key reports and metrics daily via email or chat will quickly change your teams’ understanding of and ability to act on data.

Developing habits requires making small changes on a consistent basis. To make data habitually part of the conversation, force it to be part of someone’s every day. 

3. Keep it stupid simple

If you send your team metrics, you want to ensure they understand exactly what they are. They should be able to articulate why they matter and how they’re calculated. This is obvious. Most think this means creating a data dictionary or a repository where someone can find the definition for every metric. I think that’s because the metrics are complicated to start with. Instead, pick inherently simple metrics. 

For example, if you’re running a SaaS business, you probably want your team to stay on top of Net Revenue Retention (NRR). It’s actually a quite complex metric that's not widely understood and is multifaceted. Most don’t really understand it. So, instead, you might consider showing the team the actual number of customers who made it to X period trended over time or the amount of expansion/contraction dollars over time. Those are metrics everyone understands and feels empowered to act against.

4. Bias towards action, not investigations

Analysts are always after the elusive measure of causality. It’s easy to think that if you incorporate more data, dig in further, and cut things by more dimensions, you’ll prove that one thing leads to another. But often, that’s not the case. 

The easiest way to prove causality is by acting—changing something in the business and seeing what happens. But ensure you’ve done everything above first–set up daily reporting and push people simple-to-understand metrics. You also want tight feedback loops between the actions you take and the metrics you expect that action to move. This is the fastest way to learn and helps instil a culture of acting and measuring that reinforces the use of data.

5. You need engineering

So often, I hear finance, analytics, and operations folks wanting to get better at measuring their business. But they’ll say, “I don’t want to involve engineering.” They’re setting themselves up for major failure.

Know that you’ll have to build a strong relationship with engineering. Without engineering, there’s just no way to create an ongoing system that allows you to connect your web analytics, funnel, billing, and product usage data. None.

This is yet another reason for finance, analysts, and operators to learn SQL. You’ll learn how all your systems fit together. You’ll have more specific requirements for engineering (they prefer that). You’ll build credibility and a relationship that will only get stronger over time. Speak their language, and engineering will want to help you instead of having to help you.

6. Don’t perfect your architecture first

I see organizations think they won’t be ready to use data until they’ve built the perfect underlying infrastructure. “We need all these systems to feed data into this data warehouse, build these types of tables, and feed data back into these operational systems.” It’s a falsehood.

No matter how much you invest in those systems, they’re never done. Your business always changes, and new systems and data flows always break. You’ll never design the perfect system upfront. Instead, find the first most pressing set of questions that need to be addressed and build the infrastructure that supports answering them. Then, pick the next set of questions. Rinse and repeat.

7. Self-serve analytics is an illusion

We hear it all the time, “We want everyone in the organization to get whatever data they need, whenever they need it, to answer their questions.” Whenever I hear this, I immediately think, “This is going to fail.” 

Here’s a better approach: Make a list of every important question that needs to be addressed across the business, prioritize, and start working through them. Find a way to set up reporting so those questions can be easily answered by those asking them without you having to be involved. Don’t chase the mirage.