The 47th-Best Feature

Why we at Palagus have learned that product development is at least as much about leaving things out as it is about building them. And that is not as easy as it sounds.

The most dangerous feature in a startup is rarely an obviously bad idea. Bad ideas are convenient because you can bury them after a few minutes of discussion and then tell yourself that you have done good product work. The truly difficult ones are the other ideas: features that customers could use (perhaps purely theoretically or because the use case is a no-brainer), that are technically feasible, that would look good in a demo, and for which the team could easily come up with ten convincing arguments. These are exactly the features that can slowly pull a product in every direction at once. And it becomes like a vicious cycle that you enter and somehow find difficult to crawl back out of.

While building Palagus, we encounter this problem constantly. There is an enormous amount you can build around AI Visibility: generate content, analyze products, reach additional target groups, develop new pricing models, integrate personas, and probably a hundred other things that would look perfectly reasonable on a roadmap. The crucial question, therefore, is increasingly less about whether we can build something. Especially in the age of AI in development, this question is more important than ever. What interests us much more is whether Palagus becomes a better product if we build it.

That sounds like a small semantic difference. For us, it has become one of the most important distinctions in product development.

A good idea is far from being a good feature

At the beginning, you almost inevitably treat a product roadmap like a list of opportunities. A customer asks for something, a competitor releases something new, an idea comes up within the team, and suddenly there is another item that could theoretically be implemented. The problem is that every individual decision can seem perfectly reasonable when viewed in isolation. Only when taken together do they create a product that can do a little bit of everything and where, at some point, no one can clearly explain what it was actually built for.

That is why at Palagus we now try to distinguish more clearly between four questions: Does the feature solve a core problem for our target group? Does it fit the behavior we want to encourage with the product? Does it make our positioning clearer or more diffuse? And what long-term baggage are we taking on with it? In my opinion, the last question is particularly often underestimated, because a feature does not only cost the days required to develop it. After that come UX, support, documentation, bugs, analytics, further development, and above all the expectation from customers that this feature will remain part of the product.

A few decisions from our product development so far illustrate what we mean better than any theoretical prioritization matrix.

Why we did not want to build a content machine

We talked about content generation at Palagus for a long time. Sometimes you are torn back and forth. At times it seems logical, at other times it does not. You see that many competitors offer it and think that perhaps all customers now expect it, or that somehow our product would not be complete if we did not explicitly build this feature. After all, the idea is actually quite obvious for a product centered around AI Visibility: We analyze where companies are visible or not visible in AI systems, this reveals opportunities for optimization, and the seemingly logical next step would be to generate the necessary content as well. Analysis in, content out. From a product perspective, that would create a wonderfully closed loop.

But this supposedly logical loop was exactly what bothered us, and it bothered us a lot. If we offer a large “Generate content” button, we are not just optimizing a workflow, we are also influencing our customers’ behavior. Because generation is cheap and fast, there is a strong incentive to produce more content. Ten identified gaps become ten new articles, and a hundred gaps eventually become a hundred articles. The question of whether the hundred-and-first article really makes a relevant new contribution can easily disappear behind the pleasant feeling of having “optimized” something.

An important distinction is necessary here: AI-generated content is not categorically penalized by Google. Google explicitly states that how content is produced is not the central criterion and that high-quality content should be evaluated independently of whether AI was involved in its production. At the same time, Google warns against using generative AI to create many pages without providing additional value. This may fall under the spam policy on “scaled content abuse”; automated or AI-assisted content production with the primary purpose of manipulating search rankings also violates the guidelines. [1], [2], [3]

For us, it therefore would have been wrong to give our customers a feature that almost automatically turns useful analysis into a flood of content. Not because AI content is fundamentally bad, but because we cannot control, and should not control, how much our customers publish and what editorial quality processes sit behind it. We therefore decided against direct content generation within this workflow.

At the same time, we did not want to artificially take this option away from our customers. Our solution was MCP: anyone who wants to integrate Palagus data into their own AI workflow and create content based on that data can do so. In this way, we deliberately move the decision to where it belongs, namely to the company itself. For me, this is an interesting distinction between “Our product can do this” and “Our product forces you into this workflow”.

A shopping analysis that would absolutely make sense

Another example is analyzing your own products in a shopping context. Here too, the feature did not fall out of our plans because we think the idea is bad. Quite the opposite: For e-commerce companies, the question of how their own products appear in AI-driven research and shopping scenarios can be extremely interesting.

Our decision against it was more strategic. Palagus is currently focused on B2B companies. If we invest heavily in shopping analyses, we would primarily be solving problems for a target group that is currently not our core audience. We would therefore invest development time in a new direction, open up additional requirements around products and e-commerce at the same time, and probably improve very little for those for whom we are currently primarily developing Palagus.

The interesting part is that we did not decide against the feature itself. We decided against the target group that we would implicitly serve more strongly by building it. To me, product strategy increasingly works exactly like this: Every major function is also a statement about who the product is intended for. If that statement does not fit our current strategy, even a good feature can be the wrong decision.

Pricing is also a product feature

We applied a similar principle to pricing. Of course, we could offer different packages, separate features from one another, define limits, and then work with upgrades and upsells. That is not an unusual SaaS model, and on paper it can be optimized extremely well.

Nevertheless, we deliberately decided against complicated upsells and a large number of different pricing models. Because pricing also creates product complexity.

That does not mean that differentiated pricing is fundamentally wrong. It only means that monetization optimization also has a price. Especially in an early product phase, a simpler offering can be more valuable than theoretically perfect extraction of every segment’s willingness to pay.

And then there are features where we deliberately say yes

If this article consisted only of things we did not build, you could derive a fairly boring product philosophy from it: Palagus should simply stop developing anything at all. That is why our decision around personas is particularly interesting to me.

We talked for a long time about whether prompts in Palagus should be tied to personas. We could have treated personas as an additional option that users could enable when needed. That would have been the more cautious decision and would have committed us less strongly to a particular conceptual model.

We deliberately decided against that and integrated personas firmly into the logic. The reason lies in the subject we are analyzing: A question does not exist in a vacuum in marketing. Who asks a question, the context from which it arises, and the need behind it all change its meaning. If different customer types have different decision-making paths and information needs, we do not want to attach this dimension to a prompt afterward as an optional label.

To me, that is the other side of good product strategy. Focus does not mean building as little as possible. Focus means being so convinced of a particular product logic in some decisions that you deliberately make it part of the system, while leaving other attractive possibilities untouched.

The roadmap is also a list of noes

I probably used to think that a good roadmap should show as convincingly as possible what a company is going to build next. By now, I find the list of things deliberately not built at least as interesting. Content generation, shopping analysis, and complicated pricing models are not automatically bad ideas for us. They are ideas where the strategic cost is currently higher than their benefit to the product we want to build.

Personas are the counterexample. After a longer discussion, we did not simply add another function. We made a decision about how we understand the underlying problem. Those are exactly the kinds of decisions I would like to make more often, even if they later have to be corrected.

Perhaps the 47th-best feature is therefore not actually the feature in position 47 on our roadmap. It is a metaphor for all those ideas that would be good enough to build, but not important enough to give up focus for. A startup rarely suffers from a lack of ideas. The more difficult task is to say no to so many good possibilities that enough time, money, and attention remain for the few decisions that really matter.

And sometimes the best feature is simply the one you do not build.

Sources

• [1] Google Search Central: Guide to using generative AI content on your website — https://developers.google.com/search/docs/fundamentals/using-gen-ai-content?hl=de

• [2] Google Search Central: Google Search’s guidance about AI-generated content — https://developers.google.com/search/blog/2023/02/google-search-and-ai-content?hl=de

• [3] Google Search Central: Spam Policies