Stay Close Enough to Stop
The smallest thing I've seen work most reliably: measure how often the team is in a room with a real user, and let that number tell you whether to build or stop.
Years ago I joined a product team at an enterprise SaaS company that had been at it for almost two years and hadn’t shipped anything. They were talented and working hard to execute on a strategy set by leadership. They were also about to get defunded.
My boss sat me down and gave me the lay of the land; I had to ramp up, get this team bought in, and find a way to get traction fast. We needed something to point to and justify keeping the team and product around.
I left the strategy, the team, and the roadmap alone and did something almost embarrassingly small, which is the thing I’ve seen work most reliably.
We scoped down to the smallest version of the product we knew we could deliver, and we built it over a couple of weeks. Then I started measuring one thing: the cycle time between opportunities to learn from a customer.
That meant counting how often we were in a room (or a Zoom) with someone who would use the thing. We wanted as many chances to learn as we could get, because we didn’t have long to build something sticky.
People ask me sometimes what the leading indicator of success is for a product team. My answer comes from running this on most of my teams: the shortest cycle time between customer-facing learning activities, normally under a week. Every week, someone on the team needs to have had a real conversation with a real user.
It’s reductive on purpose.
Measuring learning directly almost never works. Most of what a team learns from users is tacit: what shifted in your gut about what matters, what you couldn’t articulate yet but will use next sprint, what you absorbed in a customer call that nobody could grade, the way a customer made a face when you suggested something. It ends up as unfiltered information overload, or it turns into product theater within a week or two.
But you can easily measure how often you put yourself in a position to learn. And when a team reports that number every week as a KPI, the behavior changes. Customer conversations get built into the team cadence and stop needing a research project to justify them. People stop performing certainty about what users want and start checking in with them, because there’s always an opportunity to do it less than a week away.
This metric is an intervention dressed up like a measurement. It puts a hard structure around the team that keeps them close enough to the soft knowledge to navigate by it.
So we built the MVP, shipped it to a handful of customers, and talked to them every week. We learned fast.
The product used online behavioral signals (search, social media interactions, news articles) to measure brand and marketing metrics. The customers were a diverse mix that already used our existing products aimed at brand and marketing managers. A direct-to-consumer women’s wear brand. A youth-focused nonprofit. A major tech company. An outdoor apparel brand. A wedding-dress retailer. An airline. The diversity was the first signal: they all shared the same stated need and pain points, but they asked wildly different questions, because each of them thought about brand and marketing metrics in its own way.
We had a marketing manager from the airline on a call. We pulled up her dashboard and pointed at the trend: share of search climbing fast in three specific metros. We started asking the right product manager questions: are these new hubs? Are you expanding routes? Running any marketing campaigns here? We were excited to show signals that something she was doing was working.
Instead, we heard:
There was just a major ice storm across those cities and we had to cancel flights for days. Our share of search is increasing because everyone is frantically googling us to figure out how the fuck to get home.
The number was right, and it meant the opposite of what we’d read into it. All the data we were analyzing was publicly available, and the interpretation and analysis layer was the product.
We could see the shape of what these customers needed: a layer of brand-specific judgment on top of the data, the kind of work a smart marketer does with their morning coffee. We could see what we could build: clean, scalable, normalized signals across the entire web. The two didn’t meet anywhere we could productize in the runway we had.
So I killed it. We thanked the customers for their input, pulled the plug and pivoted the team to other things.
What the cycle-time metric did was put the team close enough to actual users to see what was real, and what was real was that we shouldn’t be building this product.
The alternative was pretending the strategy and roadmap would get us out of the hole we were in, that building for another year or two, adding another feature or three, would get us to the point where it would be successful. That’s how teams end up spinning for years and then burning out. Or, more likely, shipping something that limped along, generated some revenue, kept the team employed, and quietly bled engineering investment from things that mattered more. That version is the cascade in Reset to Zero, where a bespoke pipeline kept selling while feature development stalled behind it for years.
Reset to Zero ended on staying close enough to the work to feel where it gets compressed, squeezed into reports and metrics on its way to the people making decisions. In practice that comes down to a cadence that keeps people next to the work and a number that holds them honest about it. Some weeks that produces something worth shipping. Here it produced the clarity to stop.
I still think about how close we came to never hearing about the ice storm. The chart looked like winning. The cadence is the only reason someone was in the room to tell us it wasn’t.
This is the third in a series about the boundary between soft and hard knowledge in product development: what your gut has learned, and what you can write down and check.