The Makers Manifesto has four 4 and 16 principles. I’m a contributor to the whole manifesto but there are 7 I keep coming back to, because together they point at the same conclusion: speed is only an advantage if you're willing to act on what you learn. And acting on what you learn means being willing to kill things, pivot hard, or go in a completely different direction when you learn that it doesn’t work.

Most companies aren't willing to let their teams do that. Or they are but they are not able to do that. A significant number of teams aren't getting to the point where the question becomes relevant, because they're not measuring anything in the first place.

Two failure modes, same outcome

The first failure mode is the most common: teams don't measure or even track what they build. They ship, move on, and call it progress. Nobody asks whether the thing they shipped actually worked, because the next thing is already in the backlog and the pressure to build it is already there. Shipping is visible. Checking whether the last thing worked is invisible, unrewarded, and nobody scheduled time for it.

The second failure mode is subtler and in some ways more frustrating: teams that do measure, but don't act on what they find. The metrics are tracked, maybe there is even a dashboard or regular reporting. The data sits there telling a story, and the team reads it and then builds the next thing they were already planning to build anyway. Because changing course feels like admitting failure. Because the roadmap was committed to three months ago. Because the management wants the feature and the data is inconvenient. Because… Well, you know the game.

Both failure modes lead to the same place: you build what you assumed was right from the beginning, regardless of what reality is telling you.

What the manifesto is actually asking for

Seven of the sixteen principles speak directly to this.

• Principle 07 “Measure what drives value” is the most explicit: “What we choose to measure shapes what gets built; the consequences should deliver value without distraction.”

• Principle 11 “Build on real evidence” puts the sharpest edge on it: “Faster building is only valuable if building understanding keeps pace, continuously testing signals against reality.”

• And principle 12 “Re-orient continuously” argues that “the ability to re-read the landscape and adjust course is more valuable than the ability to execute a plan well.”

Read those three together and let them sink in. They mean speed without understanding isn't progress, it’s just a faster feature factory. AI can make this worse if you ship without thinking, because it makes building faster while doing nothing to improve your ability to know whether what you're building is actually worth building. That makes it an even faster feature factory.

I used to say “sh*t in sh*t out just faster on the market” for any fake-agile working style. While I’m genuinely excited about the turbo speed we’ve gained in building and shipping, I see that we might have to handle even more sh*t even faster on the market if we don’t learn from what we ship. This makes getting back on track becomes even harder. Which in return makes it even more important to think what you should build and what NOT before you build, or if you build with AI-speed to have the discipline to take it down if it doesn't perform.

Let’s continue.

• Principle 05 “Harness speed with clear intent” reinforces this from the strategy side: “Speed is power if paired with clear direction — without it, every capability accelerates in its own direction.”

• Principle 06 “Make context explicit” makes the enabling condition explicit: “Good judgement requires clear intent — strategic direction, trade-offs, constraints — without this, what we optimise for will drift.” Judgement isn't about having all the answers but rather about looking at the pieces you have access to and making a call anyway. There is no case of 100% information, never, nowhere.

• Principle 02 “Seek opportunity within new possibilities” adds the forward-looking dimension: “Hold well-informed convictions on where your world is heading; actively seek the opportunity within new possibilities." That's not gut feel, that's informed sense-making based input, information, learning, processing which compounds into experience, which then is a very different thing.

• And finally, principle 09 “Make for adoption” adds another layer that often gets missed: “Distribution, adoption, monetisation, retention don't come after making — they are now what making means.” You are not done when you ship, you are done when someone is using the thing you shipped, getting value from it, and coming back. That's a fundamentally different definition of done, and most teams are nowhere near it.

  
  

Example: My Doodle Chrome Extension story

Let’s apply those principles to an example that I’ve lived through.

At Doodle, we built a Chrome Extension. The idea was good: what if Doodle lived right inside Google Calendar, showing users which times worked for them without leaving the app they were already in?

Back then apps didn’t exist in the Google ecosystem, so we had to hack our way in. Every time Google Calendar updated, our extension broke. The maintenance cost was constant and painful. We measured the traction, looked at the maintenance burden, and made the call: take it down. The evidence was clear and we acted on it. That was the right decision.

Then Google announced apps. And I said no to building a Doodle app in the Google Calendar.

My reasoning was based on evidence: we had tried it with the hack, traction was low, usability tests showed limited interest, and we had a full roadmap already. All of that was true. But I used evidence from a broken implementation to make a call about a completely different opportunity. The hack and the native app were not the same product. The context had fundamentally shifted, and I didn't re-read the landscape. I read the old map instead.

That's principle 12 in action, or rather, the failure to apply it. The evidence that led to killing the Chrome Extension was valid in its context. The mistake was treating it as evidence about a new context it didn't actually speak to. As soon as a channel opens, you want to be one of the first to occupy it. I didn't see that clearly enough, because I was looking at old data instead of the new landscape.

What "act on it" actually means

This is where most conversations about measurement stop too early. Teams talk about tracking metrics and building dashboards, and then assume that having the data means they will use it. They usually won't, not without three things in place.

1. A habit. Reviewing what you launched, asking whether it worked, and letting that answer shape the next decision has to be a regular rhythm, not an occasional retrospective. If it doesn't happen on a schedule, it doesn't happen. I call this “post launch analysis” or “after launch analysis”.
   
   

2. A genuine tolerance for being wrong. Build-measure-learn only works if "learn" is allowed to mean "we were wrong and we're changing direction." If changing direction is treated as failure, the loop breaks. Teams will keep measuring things that confirm what they were already planning to do.
   
   

3. The willingness to take things down. Not just pivot or iterate, but actually kill something. The Doodle Chrome Extension got taken down. That was the right call. Most teams hold on too long because removing something feels like going backwards, even when keeping it is costing more than it's worth. If you are not willing to take it down, don’t put it out that fast.

   
   

Putting this into practice

The place to start is not with a new dashboard or a new tool. It is with three questions asked consistently after every launch: did this work, how do we know, and what will we do?

If your team can't answer that question with data, you have a measurement problem. If your team can answer it but the answer isn't changing what you build next, you have an incentives problem. Both are solvable. Neither solves itself.

The Makers Manifesto gives you the principles. The harder work is building the habits, the rhythms, and the honest conversations that let those principles actually shape what you do on Monday morning.

Don't try to apply all of them into practice: Perfect doesn't exist. Start with the conversations, one principle at a time, and see where they'll take you and your team.

Which principle will you pick to start the first conversation?