Welcome to Continuum Tracker

A new era is arriving, one in which the work of optimizing products moves to machines. Machines can read the entire history of a product's development and surface the patterns the human eye misses. They spare us the repetition and open up room to create something radically new. People can then free their minds for real innovation — for the ideas that will change the future.

Product development in 2025

Software has become a commodity. Building an online store is a good example. Today you can build one in a few minutes on Shopify, with no need to hire a external developer. And thanks to the enormous rise of customer-centric product development, most product ideas have already been explored. The ideas themselves, however, have not yet been commoditized.

We have reached a point where, inside every company, we ask more and more often: "Is this good enough for the customer? What does the customer want or need?" That approach, aimed at solving real customer needs instead of delivering top management's wish list, is unquestionably the right one. Every so often, though, it is worth asking another question too: "Are we reinventing the wheel?" The relentless push for customer-centric development has left product managers, CPOs, and designers solving the same problems over and over. Good example is search functionality. Chances are that thousands of people had already taken a similar feature or product through discovery and delivery.

Filtering is another classic example. It is among the most requested feature. And yet every company tests and validates it from scratch, as though it was a newly discovered market need.

Why to start from a blank page when thousands product managers, CPOs, and designers already shipped similar feature in past? By studying how similar features and products came together, you'll instantly see the design pattern for something like L1 categorization in an online store.

Continuum Tracker was founded to make product research and its presentation more efficient. The more efficient those processes become, the more confident a product team can be in its decisions and the smaller the risk that new features see low adoption.

Our vision at Continuum Tracker is to cut down the wasted debates and dead ends in product development by focusing on the problems that are actually worth solving. We are looking for products that will endure for millennia.

And how do we get there? For a large share of features and products, some research has already been done. Our mission is to offer the largest library of the products and services on planet with advanced search and analysis capabilities, so that anyone can see in an instant where the consensus on, say, filtering is.

Do products exist that last for millennia? Yes, they do.

Example of a product that has been with us for thousands of years

Why don't we do product research at scale?

Why aren't we learning from the past already? Because it takes a lot of time to track down the product-related information, including the context of every product release and every feature specifications, and then compare it. And comparing is important.

Any car shopper recognize a Škoda Kodiaq from a Porsche Cayenne. But comparing features of a Kodiaq with a Tiguan, or two generations of the same model, is far harder. It is the same with other products. Look closely enough and there are always substantial product differences. Weighing the specs of several variants of a similar product is a demanding task, both for shoppers and for seasoned members of a product team. And even for AI.

Reviewers mostly compare the big, visible features that set products and their versions apart. One reason is simply that big features are easier to find. Not every last screw gets its moment in a marketing brochure. Sticking to the headline features costs less time and less money. A full, side-by-side comparison of two products is exhausting.

Most of managers work from the assumption that it is precisely the big, strategic features that decide whether a product gets bought and adopted. Those are the features that get presented and analyzed. By contrast, from the customer's side, the product is a finished service or physical product that they weigh against the alternatives before deciding whether to buy.

Broadly speaking, that assumption about the difficulty of comparison feeds indirectly into product development process, where every considered product feature can be sorted into one of the following three categories:

1. a big thing (must-have),

2. a mid-sized thing (nice-to-have),

3. and a technical improvement or customer service (support).

Filtering, for instance, is not only about narrowing the options as a must-have. It is also about which specific filters help the most, which is where the nice-to-haves come in.

The backlog in product development. Based on empirical findings.

Look at a product this way and you find that a FINAL PRODUCT can be defined as a set of individual features, spanning different categories, that someone adopts at a given price. In the ideal case, the shopper mechanically assembles a map of every feature and its weight (its category) and sets that map against another product. That is how the shopper decides, weighing adoption against price.

Every product, then, can be broken down into small prime factors (its features) and their weights. Doing that takes a great deal of time, which is why it is mainly the visibly big features that get judged.

From individual features to product strategy

We have looked at comparison through the eyes of the customer, of management, and of the product person. Let us move up to the strategic level of running a company — product strategy. The people who work at that level are, for example, Group Product Managers, a Head of Product, or a Chief Product Officer (CPO).

From where they sit, a company never offers just one product. It offers a whole product portfolio, and that portfolio needs a strategy, so the products fit together, do not duplicate one another, and slot into the everyday lives of the users who adopt them. In terms of product strategy, then, senior management allocates capital to building products and services in whatever way delivers the most profit, the most sales, or whichever metric management track.

The Head of Product therefore compares several products at once, judges the strategy as a whole, and decides where the limited capital will go. Feature sets are still the foundation of product strategy. So there is a certain hierarchy in how product development gets viewed.

Even in that overall assessment, though, a large share of managers again point out the big, strategic pieces they believe carry great weight with customers. But money is limited, so some of the products in the portfolio end up updated less often. They matter less inside the organization, they get developed less, and they carry less weight in the portfolio. And that happens even when they are very successful.

The global market

One reason customers see so many products on the market that look so much alike is the uneven way capital gets allocated to product development from one organization to the next. That, though, is only my personal hypothesis.

Take the market for electric kettles in the Czech Republic.

The electric kettles on offer at Alza in 2025

The customer cannot tell these products apart at a glance. And that is because the product manager who developed the new kettle had neither the time nor the money to work out the new set of individual features that someone adopts at a given price for the PRODUCT THAT ALREADY EXISTS.

"Is this a kettle customers actually want? Have we tested it?" asks the Group Product Manager.

"It's a kettle that in a month" (the time available) "I managed to test with 31 users, and the market seems to want it," the product person replies.

The time dimension

Let us add one more dimension to our comparison problem — time. Comparing across time is worse still, because it leans on memory and, to a large degree, on the need to dig up old information. Picture a product manager comparing an electric kettle from 1962 against today's models. It makes little sense, because the customer is always choosing among the options available right now.

Now take a look at an electric kettle from 1962.

A patented electric kettle from 1962

Back in 1962 there was already a kettle much like today's. That shows how little today's products differ from the ones that came before them. From cases like this, we can largely conclude that most products barely differ from their own earlier versions.

It follows that if a product manager can study products in enough depth (features), breadth (competitors), and length (time), they can far better grasp the set of individual features that someone adopts at a given price. Because products change so little over time, most new features fall into the nice-to-have category. And nice-to-have research can be automated.

The only thing left is to do enough product research on the products that already exist, and then copy the feature sets that keep recurring. That gives you a new version of the product. The process can run again and again for as long as the capital spent on research stays lower than the profit from sales.

When product research and the way it is presented are fast, development can turn its attention to new products instead of reinventing the wheel with every fresh iteration of a products that already exists.

Automating product improvement

We have seen that the basic user need a kettle meets, the way it is built, and the way users judge it against other products have all stayed more or less the same since 1962.

Continuum Tracker takes on the hard job of recommending what the next iteration of a product should look like. We are building generic product management. How? With our AI, a person can study products and their features down to the smallest detail across time, features, and competitors. We automate the search for the optimal set of nice-to-have features.

The first layer of the product backlog is already being automated, slowly, by companies such as SentiSum and others. Continuum Tracker is aimed at automating the middle layer of that product backlog. The last layer stays in human hands.

Automating product development

The future of product development

The year is 2032. New products, the ones the world has never seen, never known, that no one has yet invented, are still original. Over time, though, the way people see them settles onto the set of features that define the product — and at that moment its development turns generic.

The next version of the product is then no longer a matter of innovation but of optimization. That is why optimizing does not demand as many resources, human ones above all, as building new products does. Iterating a new version of a product follows a simple equation:

The impact comes through most clearly on Everett Rogers's innovation curve. Its S-shaped curve charts a product's performance over time. As the years pass, improvement gains slow. Each new version brings only small performance increments. This is exactly where the automation of product development shows up most.

Everett Rogers's innovation curve shows the future of electric cars as an example.

The future of product development does not lie in how many more nice-to-have features we added to the product. It lies in machines taking over the repetitive work of keeping existing products fresh, so that people can focus on real innovation — the kind that changes the world. And the more efficiently we optimize the small improvements, the more capital we free for the bold ideas that carry humanity forward.

Let's improve product research together. In a short interview, walk me through how yours works. Get in touch with us.