We Kept Making the Right Product Decisions. Somehow, They Added Up to a Bigger Problem.

Have you ever done this? You’re only going away for a few days, but as you pack, you keep thinking: I might need this. I’d better bring that too. Every item has a reason to be there. Every item feels necessary.

In the end, you have to sit on the suitcase just to zip it shut—then drag the ridiculously heavy thing everywhere you go. You’ve packed everything you might need. But now, every step of the trip feels harder than it should. Looking back, I think we’ve been doing something very similar to ExcelDashboard.AI, our AI data reporting product. Over the past few years, we’ve kept adding new features.

Some came directly from user requests. Some brought us real traffic. Some were genuinely used and appreciated. Every decision made sense on its own. But once we packed everything into the same product, it became more powerful—and also more complicated, harder to maintain, and harder for new users to understand at a glance. That’s something we’ve been thinking about a lot lately: If almost every feature decision made sense, how did they add up to a much bigger problem?

The first version of our product had one clear path. Users uploaded an Excel or CSV file. AI analyzed the data and generated an outline for a data report. Once the user approved the outline, AI generated a complete 10-to-30-page data report. The whole product could be explained in one sentence: Upload your data, review the outline, and get a complete data report.

The product was far from perfect. The AI output could be inconsistent, and the editing experience was limited. But at least the product knew what it was. Back then, we could explain it in one sentence. Later, it took us an entire paragraph—and somewhere in the middle, we would usually say:

“Oh, and we can also…” When “we can also” starts appearing too often in your product pitch, it’s usually not a great sign.

We quickly realized that users didn’t really need another beautiful HTML data report. By then, tools like GPT and Genspark could already generate visually impressive web reports. But most of those reports could only be viewed online or exported as PDFs and images. They didn’t fit naturally into the way people actually worked. Real data reports are rarely generated and sent out untouched.

People still need to verify the numbers, adjust the charts, rewrite parts of the analysis, rearrange sections, add branding, and then deliver the report to a client or manager. What users needed wasn’t a report that merely looked finished. They needed a fully editable, native PowerPoint data report. And the charts had to be genuinely editable—not just screenshots pretending to be charts. So we invested heavily in native editable PowerPoint.

We didn’t paste a flat image onto a slide or squeeze a web page into a PPT file. We made the text, charts, and slide elements editable inside PowerPoint. That was a good expansion. It didn’t change the original job of the product. It completed the real data reporting workflow: Data → analysis → first draft → editing → delivery. I only understood the distinction later:

A good expansion makes the core workflow more complete. A dangerous one gives the product another core workflow.

Once you’ve built a few powerful technical capabilities, new features become incredibly tempting. Our users already worked with Excel, so why not generate dashboards automatically? People sometimes found a great chart in a screenshot, so why not let AI rebuild it as an editable chart? Some users only had a written description and no structured data, so why not generate charts directly from text? If we could generate PowerPoint, why not add Excel, PDF, Word, and more?

Every question seemed to have the same answer: “Yeah. Why not?” And these features weren’t complete failures. People clicked on them. People tried them. Some continued using them and told us, “This is really cool.” So we kept going.

It felt a little like scrolling through TikTok. No single video is important enough to deserve your whole evening. But every video makes one more swipe feel completely harmless. New features work the same way. One more feature doesn’t seem dangerous. Then you look up and several hours are gone.

We looked up and realized the main storyline of our product was disappearing too.

Looking back, I still don’t think these were bad ideas. They solved real problems. Some users genuinely needed them. The real problem was this: We kept optimizing each feature locally without optimizing the product globally. We asked:

Does anyone need this? Will anyone use it? Can it bring us traffic? Can we build it? But we rarely asked:

If we keep adding features like this, what will this product become three years from now?

A series of individually reasonable decisions can still produce an unreasonable product.

It’s like adding toppings to a pizza. Mushrooms are good. Beef is good. Cheese is good. Pineapple… apparently has its supporters. But putting everything someone likes onto one pizza doesn’t automatically make it better. Sometimes you just end up with something that needs a forklift.

The first was engineering complexity. At the beginning, we only had to maintain one path from data to data report. Later, we had to support PowerPoint, dashboards, chart reconstruction, text-to-chart, an editor, templates, and multiple file formats. The problem was that these features didn’t stay quietly in separate rooms. They interacted.

Improving one chart type could break another export workflow. Upgrading a model could make one workflow smarter while causing another one to suddenly start talking nonsense. Alvin, our resident technical brain, began spending more and more time patching problems created by the interactions between features. We would fix one part, and another problem would appear somewhere else.

A seemingly simple update could affect several different workflows. An iteration that was supposed to improve the product would often arrive with a fresh batch of regression issues. Eventually, even the process of improving the product started to feel demoralizing. We were no longer maintaining ten features. We were maintaining the relationships between ten features. The cost wasn’t additive.

It was closer to multiplication. The second was user complexity. From our perspective, every new feature gave users another capability. From a new user’s perspective, it gave them another decision. Should I generate a data report or build a dashboard?

Upload data or a screenshot? Start with a template or create a chart first? None of these options was bad on its own. But together, they made one simple question surprisingly difficult: I’m here. What should I do first? We started hearing complaints like:

“I just want to create a data report. Why do I need to understand all these options?” Some users even sent us screenshots and asked: “Where do I click now?” That was the real warning sign. If users have to understand the structure of the product before they can complete the task they came for, we’ve transferred part of the work back to them.

We wanted to save them from cleaning data, building charts, and writing data reports. Instead, we gave them another job: Figuring out how our product works. We saw more capabilities. They felt more decisions—and more chances to choose the wrong path.

The third was founder attention. This may have been the most expensive—and least visible—form of complexity. When image-to-chart started bringing in traffic, we wondered: Should we focus on this? When dashboards attracted search demand, we wondered: Should we become a dashboard product? When editable PowerPoint received positive feedback, we wondered: Should we become an AI presentation product?

Every feature added more than another piece of code. It added another possible identity for the company. Eventually, the product didn’t just become harder for users to understand. It became harder for us to explain to ourselves.

If a feature launches and nobody uses it, the decision is easy. Turn it off. The difficult features are the ones that bring in some traffic, get some clicks, and occasionally receive praise—but never create deep or lasting usage. The numbers are just good enough to make you reluctant to walk away, but never good enough to prove that the direction is working. We mixed up several very different signals:

A click is not long-term value. A trial is not retention. Demand for a feature is not demand for the product. And traffic growth definitely isn’t willingness to pay. We confused evidence that a feature was interesting with evidence that the product was getting better.

Scattered data can create a dangerous sense of certainty. It makes you feel as if the direction is being validated. In reality, it may only be interrupting the work that matters most.

In the past, a new feature might have taken three months to build. Three months is expensive, so a team has to seriously ask: Is this really worth it? Now, models, APIs, and agent frameworks have made development dramatically faster. Some features take a few weeks. Others can become surprisingly convincing demos in a matter of days.

The cost of building features has fallen. The cost of product complexity has not.

If anything, it may have increased. AI is like placing an always-on vending machine beside every founder and product manager. Every time you walk past, it says: “We can build this too. Want one?” And when you press the button, something actually comes out.

That makes one question increasingly dangerous: Can we build this? Because more and more often, the answer is yes. The question that matters is: Should this become part of the product?

Learning to step away from all those flashing new capabilities—and stop obsessing over what else we could build—has become more important than ever. We need to ask what users truly need us to do exceptionally well.

In the age of rapidly improving foundation models, having a lot of AI features is not necessarily an advantage. The feature you build today may become a default model capability tomorrow. Today, text can generate charts. Tomorrow, the model will do it natively. Today, AI can generate a PowerPoint.

Tomorrow, it may not only generate it, but edit the entire thing directly. If we keep wrapping every new model capability in another product feature, we enter a predictable cycle: A new model launches. We add a feature. It gets some attention.

Then the next model upgrade erases the difference. What compounds over time is not simply the ability to generate more things. It is the specific, messy workflow knowledge that sits beyond general model capability.

For data reporting, that means understanding how a company defines its metrics, knowing which changes deserve a place in the report, distinguishing a meaningful anomaly from normal movement, preserving calculations and supporting evidence, matching the team’s existing reporting style, and reliably repeating the workflow when the next set of data arrives. Foundation models will keep getting smarter. But they will not automatically understand how every company actually works.

The product should be built where general model capability ends and workflow knowledge begins.

First, protect the core from scattered demand. A feature can have users. It can bring in traffic. And it can still be the wrong priority. We no longer ask only: “Does anyone want this?” We ask:

Will this make the core data reporting workflow meaningfully stronger over time? Second, measure work removed, not capability added. The value of an AI product is not that it has one more button. The value is what the user no longer has to do. Did we remove a decision?

Did we eliminate another round of data cleaning? Did we save the user from manually adjusting ten charts? Did we give them three hours back? If we cannot clearly identify the work a feature eliminates, then it may be adding demo value rather than user value. Third, build the depth that foundation models will not automatically provide.

We would rather invest in metric definitions, supporting evidence, insight judgment, reusable templates, stability, and repeatability. These improvements may not produce the same traffic spike as launching a shiny new tool. They can be painfully boring. But a lot of important product work is boring. Nobody applauds on Twitter when you fix the hundredth edge case.

But that fix may determine whether users trust you with their real work.

We are not going to stop building new features. That isn’t restraint. That may just mean the company is dying. Real restraint means accepting that not every useful feature deserves the same investment, visibility, or influence over the product. Some features should become part of the core workflow.

Some should stay one level down as supporting capabilities. Others may bring in traffic and still belong outside the core product as separate experiments. They should not be allowed to redefine the entire product. For a long time, I thought product progress meant enabling the product to do more and more things. I’m less sure about that now.

Especially in AI, “doing more” is becoming easier every month. What may become truly scarce is the ability to go deep enough on one important problem that users are willing to trust you with their real work, again and again. The hardest part of product restraint is not rejecting a stupid idea. It is looking at an idea with users, traffic, and a perfectly reasonable argument behind it—and still deciding not to build it yet.

Because every useful feature we build takes time away from turning the core product from “good enough” into something exceptional.

Every feature can make sense on its own. The hard part is making sure the product still makes sense as a whole.