Lean Analytics teaches FDEs to pick one number, then let it go

The official Lean Analytics website opens with a very short question: do you know what your most important metric is? Picture a project review at a client site with a twelve-chart dashboard, where nobody can say which chart decides what happens next week. The book’s question is aimed squarely at that gap.

The book was written for startup founders, not for engineers deployed to clients. Yet its central idea, the One Metric That Matters, fits a deployment just as well. A client project also has a short life cycle, goals that shift from one phase to the next, and people on the client side who need to see progress in numbers.

Who wrote it, and why?

Alistair Croll has worked across several fields, from web performance, big data and cloud computing to startups. Ben Yoskovitz is a founder and former startup mentor who is now Founding Partner at Highline Beta and writes the Focused Chaos newsletter. The book’s tagline on the official site is “use data to build a better startup faster”.

According to the two authors, the book’s core idea is this: once you know what kind of business you are in and what stage you are at, you will know which metric to track and optimise. The free ebook on the official site, which is the content of the first edition, contains 13 case studies from companies including Airbnb, SEOmoz, Office Drop, Swiffer and EMI.

For an FDE, the book’s value lies in measurement: proving value with a number that both you and the client believe.

One number to point the team in one direction

It is easy to misread “one metric” as an instruction to throw away every other number. Yoskovitz made the point clearly in an interview with Mixergy: of course it is not the only thing you track; it is there to keep everyone focused.

In another piece he repeated the idea: ultimately, the OMTM exists to create and encourage focus.

At a client site, that focus has a very practical effect. Imagine you are deploying an agent that triages support tickets for a logistics company. You still log latency, token cost and error rate.

But in the weekly meeting, only one number goes at the top, and every prioritisation decision has to answer a single question: does this push that number up?

Three questions that pick the number

The OMTM blog post on the book’s website sets out three criteria: what business you are in, what stage of growth you are at, and who is reading the numbers. Applied to a deployment, those become: is this an automation project or an analytics project, is it in pilot or already in production, and who on the client side needs convincing?

Go back to the ticket-triage agent. In the pilot, the person to convince is the support team lead, so a sensible metric is the share of tickets the agent classifies that staff do not have to reroute.

Suppose the agent handles 120 tickets a day and staff reroute 30: that is a 75% acceptance rate. The number speaks directly to what the team lead cares about: can the agent be trusted with the work?

Today’s good number can be wrong next month

Whatever your current OMTM is, the authors warn, expect it to change. They are explicit that it is not a metric for ever, but the metric that matters most at a given time. Yoskovitz describes it as choosing the right thing to track at the right time.

In the example above, once the acceptance rate has settled at a level the support team is willing to work with, pushing it from 75% to 80% may no longer be the most valuable thing to do.

The project moves into production, the person reading the numbers is now the operations director, and the key metric should shift to the average handling time per ticket. The trap is keeping the old number because it looks good, while the decision-maker has moved on to asking about something else.

Have you picked the right number?

The most common mistake is choosing the number that is easy to measure rather than the one the reader cares about. For the ticket-triage agent, “tickets processed” rises steadily every week, but it does not answer the question the support team lead is asking: are the results usable?

The second mistake is putting five metrics on one slide and calling them all “key”, so that nobody knows which to follow when two of them move in opposite directions. The third is choosing the right metric but not writing down in advance when you will change it.

To check yourself, try answering three questions about your current project. Who on the client side reads this number? If it falls next week, what will you change in the backlog? At what threshold will you move to the next metric? Whichever question you cannot yet answer is the first thing to fix.

Start with the blog post, not page one

Read the One Metric That Matters blog post on leananalyticsbook.com first, because it condenses the three criteria for choosing a metric and the principle of changing it by stage.

Then read the book, prioritising the sections on business types and stages before the case studies. With each case study, ask yourself: if the project I am running at a client fell into this situation, what would the key metric be?

The book is most worth reading if you can already ship systems yourself but still struggle when a client asks how successful the project is. If you are preparing to move into an FDE role, it is also good material for your CV.

Instead of writing “built a monitoring dashboard”, write which metric you chose, why, and when you changed it. If a job posting mentions measuring outcomes for clients, that is the place to tell exactly that story in the interview.

The question on the Lean Analytics website sounds simple. Answering it for each stage of a project is the most direct way to show a client where things stand.