Graham McNicoll

Product teams obsess over whether they shipped on time. It's a reasonable thing to track. It's just not a very useful one. I talk to engineering leaders every week who can tell me exactly how many story points their team hit last sprint. Very few can tell me which of those features actually moved a metric. Shipping velocity tells you how much you built. It does not tell you whether any of it was worth building. The metric that actually compounds is learning rate. How many validated insights does your team generate per quarter? How quickly do you find out when something isn't working and move on? At education.com, we ran a series of tests and found something we never would have predicted. Our users disproportionately loved our animated characters. Every test that included them won. We didn't debate it. We stopped treating it as a variable and made it a default. Then we moved on to the next question. That's what a high learning rate actually looks like in practice. You stop arguing about what might work. You find out. Then you use that knowledge to make better decisions faster. When teams skip this, tension fills the gap. Leadership defends gut feel. Engineers start to feel like the roadmap has nothing to do with users. That's how you get attrition and a codebase full of features nobody can tell you the impact of. The goal isn't to prove you can ship. It's to learn how to make something people genuinely want. If your team is tracking the wrong thing, DM me.

Only one snapshot so far — the engagement-over-time curve appears once the daily scrape has captured this post at least twice.