Project vs. Product Mindset: Why 85% of Your Product's Features Are Useless, and What to Do About It

Hi! My name is Artem Gerasimov, and I'm the Product Owner for SimpleOne SDLC. In this article, I want to talk about a problem that most IT companies face: they spend millions developing features that nobody ever uses.

Even in the best companies in the world, only about 15% of a product's functionality is actually in demand by users. In average companies, that number drops to 5-10%. The other 85-90% of features become "synthetic sugar" — they're there, but nobody is using them.

Take Microsoft Word, for example. Most users work with just two or three tabs out of the dozens available. The rest of the features are hidden somewhere in the interface, and people don't even know they exist unless someone tells them or they happen to read an article about it. But the truth is, they don't need those features. They only make the software more complicated and create technical debt for the developers. Every unused button has to be supported. Developers have to dig into every feature when they're fixing bugs. The more bloated the functionality, the more expensive it is to maintain the product.

This problem is a direct result of the approach taken to development. Companies are still working the old-fashioned way: they gather requirements, write a technical specification, the team disappears for six months to build it, and only then does anyone find out that half of the features are completely useless. The product-centric approach offers a different logic: build in small batches and test every single step. So why do most companies keep doing things the old way?

Project vs. Product

Imagine this: a team gets a task to add a new feature to a product. Let's use the example of a "review mode" in Word. How would the team act under different approaches?

The Project Path

The team goes to the users, asks for their requirements, and draws up a technical specification. They create a Gantt chart and then disappear for six months to build the feature. Six months later, they deliver the finished product: comments, a review panel, versioning, and change tracking.

Everything works, the users are happy, and the project is closed.

But nobody ever checks which specific buttons people are actually using. It's possible that half of the features are unnecessary — they'll just add to the technical debt. Every single one of those features has to be maintained, tested during updates, and have its bugs fixed.

The measure of success for the project approach is the "project triangle": did we stay within budget, on schedule, and within our resource limits? This is an internal measure of success. It's about doing what we promised to do, not what's actually needed.

The Product Path

The team still goes to the users and figures out what they need, but they don't try to build everything at once. They work in iterations.

First, they add only the ability to make comments. They run an A/B test and see that people are using the feature. Great, that means the feature is needed.

Next, they add versioning. But during testing, it turns out that this is too complicated for the target audience. Nobody wants to deal with different versions of a document.

So, they rework the versioning feature into a simple "accept" or "reject" for edits. They test it again, and now people are using it.

The measure of success for the product approach is external: does the user need this, and does it bring them value? The tools for constantly checking hypotheses are quantitative metrics, NPS scores, and both quantitative and qualitative research. But it's not just the process that changes; it's the entire philosophy of work. Instead of "building what we think is right," the team's mindset becomes "building what the user actually needs."

Why Doesn't Everyone Follow the Product Path?

The product-centric approach has been around for years. You hear about it at every IT conference, and Agile and Scrum have become mainstream. But most companies are still doing things the old way. Why?

The main barrier is psychological. Managers are used to control and planning. In the project world, everything is clear and predictable: Smith is working on task A, and Jones is working on task B. The Gantt chart shows exactly who is doing what for the next six months.

In the product world, you don't have that kind of certainty. The team is working toward a common goal, for example, "increase the number of users by 2%." How exactly will they do that? The designer might start working on marketing materials, a developer might optimize the demo version, and an analyst might work on video scripts.

The lines between roles become blurred. No one knows exactly what they'll be doing a month from now. For managers, this is stressful. How do you control the work if there's no clear plan? On top of these fears, there are some dangerous myths about Agile floating around the market.

Three Myths About Agile

Myth #1: Agile is more expensive

Many people think that flexible methodologies just inflate budgets. To some extent, that's true, but for a specific reason. In the product approach, there's a constant temptation to keep improving things: "Hey, let's also rework this part," or "Can we add just one more feature?" The scope of work grows because the team sees opportunities for improvement but forgets to account for them in the budget planning.

Myth #2: Agile is faster

Leaders often think, "We have a project deadline in a month, so let's just create an Agile team and we'll get it all done." Agile really can speed things up, but it's not magic. The speed comes from the fact that the team stops constantly switching between tasks. When a developer is working on task A and then has to switch to task B, they waste at least 20 minutes just getting their head into the new task. Agile encourages you to focus on one or two tasks at most — that's where the time savings come from.

But the total amount of work is still the same. Agile is about flexibility and adapting to the market, not primarily about speed.

Myth #3: The product approach is a one-size-fits-all solution

The product approach is not for everyone. First and foremost, it's designed for unpredictable, competitive markets where you don't fully understand what you need to build at the outset.

If you're automating a factory, it makes no sense to install one industrial robot, see how it works, then install a second one and see how that works. It's much simpler to create a project plan, calculate everything in advance, and install all the robots at once.

Examples of Companies Suffering from the Project Approach

The products of one well-known developer of enterprise automation solutions are a classic example of project-based thinking. The interface is overloaded with features, and adapting to changes is slow. The company wins because of its integration with the tax authorities and because users are used to it, but not because the product is user-friendly.

For example, this same company has an ERP product that other companies invest tens of millions in. But the implementation fails, and the perception of the system sours. The partners who implement the developer's solutions can't make enhancements quickly; everything has to go through complex approval procedures.

The project management solution from this developer shows the same problem. The product has a Kanban board, so in theory, development teams could work in the same system as the rest of the company's processes. But in practice, companies use Jira instead of this local solution. Development teams don't want to switch to it because the system's development is slow and its functionality is limited.

The Price of Being Slow

History is full of examples of companies that paid a heavy price for sticking to the project approach:

• Nokia's downfall was a story of strategic missteps. The leadership saw the threat of touchscreen interfaces but was afraid to disrupt their successful business model built on Symbian. Inertia won out over common sense. Internal battles between departments for resources paralyzed development. Instead of talking to users, the company was at war with itself. When the iPhone appeared, Nokia's response was too little, too late.
• BlackBerry became a victim of its own success in the corporate world. Its leadership believed that security and a physical keyboard were unbeatable competitive advantages. The company made tiny improvements to its existing models, completely ignoring the signals from the market. Users wanted multimedia features and an app ecosystem, which Apple offered. BlackBerry didn't listen and just kept doing what it thought was right.
• Intel lost the mobile market because of its architectural and business decisions. Its powerful x86 architecture used too much power for smartphones, while chips based on the ARM architecture from its competitors were more efficient. Intel refused to adapt its profitable business model for low-margin mobile chips. The company started creating energy-efficient solutions far too late — Apple and other manufacturers had already captured the market.

The common problem for all three of these giants was that they operated under the paradigm of "we know what our users need." Instead of researching the market and adapting to what their audience wanted, these companies just kept perfecting what they thought was important. This project-based mindset — plan at the beginning, stick to the plan, and ignore external signals — led to catastrophic consequences in a rapidly changing industry.

How Your Mindset Changes in the Product Approach

With a product-centric approach, a manager's entire focus shifts. If before, the main thing was to control deadlines and budgets, now it's about analyzing value for the user. Instead of asking, "Did we stick to the plan?" the manager asks, "Does the user need this? Are they willing to pay for it?"

The team no longer works on individual, disconnected tasks. Everyone is focused on the product and its evolution. The product becomes the central entity that unites people around a single vision.

A product's success is now defined by whether it makes money for the company. But money isn't the only criterion. NPS and user feedback show how stable your position is in the market, as there's always a risk of losing your niche if a more user-friendly competitor appears. As we all know, the market can change overnight. Companies that can't adapt quickly risk being left behind by competitors who can react to changes in a matter of weeks, not months or years.

For new tasks, companies choose new tools. For the project approach, PM systems and task trackers work well, where each team works on its own board, in its own project. There's a main PM who plans everyone's work, but the connections between the teams are blurry. In contrast, in the product approach, you need a strong connection between different development streams. One of the modern approaches to managing the development of complex products is the Software Development Life Cycle, or SDLC.

SDLC systems unite the vision of the entire product, giving teams access to shared goals and development strategies. In these systems, you see integrations with Git, testing systems, and advanced knowledge bases for development. The tools are designed specifically for development, not just for task management.

At the same time, the product approach doesn't end with the release. SDLC is about managing the full lifecycle of development, which includes the stages of improving the product. After a release, support and continuous improvement begin, which is why at SimpleOne, we've integrated SDLC and ITSM, so that developers have a way to work with incidents after a release.

ITSM covers the support of existing products, while SDLC covers the development of new ones. The connection works through the KEDB (Known Error Database): tech support creates a task for a quick fix, and the development team works on a planned fix for the root cause.

***

The product-centric approach solves the main problem of IT development — bloated, unnecessary functionality. Instead of getting a product where only 15% of the features are useful, you get a product where every single button has been tested by users and is actually needed.

So, which camp are you in: the project approach or the product approach?