How a question becomes a product

Our method is called value engineering. We use it in a plain sense: understand the function we want, look at the effort it takes and try a better route. It is not about trading quality for a lower price. It is about seeing which parts actually contribute to the result.

For an AI tool the real function might be this: help a person judge a code change with confidence. “Read as many files as possible” is then not a goal. A clear explanation, the right evidence and the relevant tests come closer. That distinction stops us from mistaking activity for usefulness.

LeanCTX is one concrete answer to such questions. Its reading views treat orientation and close inspection differently. A structural overview suits the first look. The full content suits a careful examination. So the point is not to make every access as small as possible. The point is to have the right material ready for each step. [1]

Thinkery makes these calls itself. We decide what we develop, release and maintain over time. Value engineering is our internal way of working. It puts development time where it does the most for the task. Feedback from real use leads back to the same question: what belongs in the next version?

Before a trial we write down three things. What improvement do we expect? How would we recognise it? What has to stay intact? That turns “this should be more efficient” into a testable question. For example: does a targeted file view shorten the first orientation without losing an important exception? The second half counts as much as the first.

The first trial does not have to show the whole product. One workflow is enough if it exposes the decisive uncertainty. We build as little as possible in order to learn something. And enough that the observation is more than a nice demo. Difficult inputs, interruptions and changes to the request belong in it.

One possible setup: a code change with an exception built in on purpose. The full read serves as the baseline, the targeted view as the alternative. Both have to reveal the exception. Only then is it worth comparing runtime and text volume. This is an example of a test design, not a reported measurement. It shows why we fix the requirements first. Otherwise a convenient outcome becomes the goal after the fact.

After a change we look at the original task again. Did it help? Did work appear somewhere else? Is the tool still understandable? A trial can show that an idea holds. It can also show that we asked the wrong question. Both are useful when we note the conditions and the observation properly.

Single measurements need context. LeanCTX keeps a local record of savings events whose integrity can be checked. That makes a technical change easier to follow. For the decision we also look at whether the task was done well. A carefully kept record answers only the question it actually captured. [2]

So we separate three levels. “This run used less input text” is an observation. “The selection may be enough for this task” is an interpretation. “We will test the approach on more tasks” is a decision. Mixing the levels makes an early trial look more final than it is.

A trial does not always have to produce a new feature. Sometimes a clearer default is better. Sometimes the existing route stays the right one. And sometimes we record a finding and build nothing for now. A product should get clearer through the work, not automatically bigger.

A product company lives with its decisions. Every extra feature needs maintenance. Every default shapes how people work. So a reasoned decision to keep something small is worth as much as an extension. We want products whose size follows from their purpose. The next version should rest on what we learned.