The feature worked. That was the problem: because it worked, we could have spent weeks making the wrong thing faster.
In an early product conversation around Saleslyt, the system could collect activity, enrich it, and present it cleanly. The architecture discussion moved naturally toward more connectors, automated analysis, and a more capable pipeline. Then the demo reached the question that mattered: what should the user do next?
The product had information. It did not yet remove a decision.
What we mistook for value #
Engineering progress is easy to count: an integration completed, an event consumed, a model response generated, a dashboard populated. Product progress exists when a person’s next action becomes clearer, safer, or cheaper.
We had optimized the supply of intelligence before defining the decision contract:
Given this evidence, for this person, at this moment,
what action is justified—and why?Without that contract, adding data increased cognitive load. Every new signal created another fact the user had to interpret.
The decision #
We narrowed the roadmap. Instead of treating “more intelligence” as the outcome, the product flow had to earn three things:
- identify a specific next action;
- expose the evidence behind it;
- make uncertainty visible rather than decorating it as confidence.
That changed the engineering sequence. Provenance became more important than another enrichment source. Feedback on whether a recommendation helped became more important than a richer dashboard. A smaller, explainable action loop became more valuable than a general agent with broad access.
The management lesson #
Stopping technically good work is uncomfortable. The code is real and the team has momentum. A leader must make it safe to say that correct implementation is not evidence of product value.
I now ask for a decision sentence before approving a major product system:
After this ships, which decision can a user make that they cannot make reliably today?
If the answer is a list of features, the problem is still undefined.
The review moved from component completeness to decision quality: false positives, missing context, stale evidence, and the fallback when the system was unsure. Those are product questions and architecture questions at the same time.
The dirty engineering lesson is that a roadmap sometimes improves by deleting a technically impressive path. The cheapest moment to remove the wrong abstraction is before more of the organization depends on it.
All Field Notes · AI evals are release engineering · Architecture decisions need expiry dates