Stay Close Enough to 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 didn’t rewrite the strategy. I didn’t reorganize the team or rebuild the roadmap. The thing I did was much smaller than that.

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.

We didn’t try to measure how much we learned, or how valuable the insights were. Just how often we were in a room (or a Zoom) with someone who would actually use the thing. We were maximizing the frequency at which we could learn, trying to put ourselves in the best positions to build a sticky product in a short amount of time.

People ask me sometimes what the leading indicator of success is for a product team, and this is the answer I give now: successful teams have the shortest cycle time between customer-facing learning activities, and it should normally be under 1 week. Every week, someone on the team needs to have had a real conversation with a real user.

It sounds reductive. It is reductive. That’s the point.

Measuring learning directly almost never works. Learning is tacit by definition — 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 really easily measure how often you put yourself in a position to learn. And when a team reports on that number every week — when it’s a KPI, not an aspiration — the behavior changes. Customer conversations stop requiring research projects to justify them, and instead get built into the team cadence. 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 was built around measuring online behavioral signals, like 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 — while they all shared the same stated need and pain points, the questions were wildly different, because the way each of them thought about brand and marketing metrics was wildly different.

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. The interpretation was the opposite of what the number suggested. 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 actually 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 we killed it. We thanked the customers for their input, pulled the plug and pivoted the team to other things.

The discipline worked. It produced the clarity we needed to know to stop.

The cycle-time metric didn’t tell us what to build, it put us in a position where the right call became obvious. The team got 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 where the cascade from the last piece starts to run.

Clarity that saves a team from building the wrong thing is worth more than most things that ship. We just don’t tell the story that way, because it doesn’t feel like winning.

The second piece ended on a line about staying close enough to feel where the compression is happening. This is what that looks like in practice. It’s not a framework or some process overhaul, it’s just a cadence that keeps people next to the work, and a number that holds them honest about it.

Sometimes that produces something worth shipping, sometimes it produces the clarity to stop. Both are the discipline working. Consistently staying close enough to where the work is happening is how you navigate the temper line.

This is the third in a series about the boundaries between structured and unstructured knowledge in product development.