## Co-Founder AI

If you’re developing a product, mastering the art of saying “no” is essential. Not “maybe” or “later,” but a clear and decisive “no.” During product development, avoid incorporating options that might theoretically add value but are tangential to your core offering. These unnecessary features can prevent you from precisely defining your product’s parameters and its direction.

As evidenced by Apple’s latest advertising campaigns, there can be thousands of versions of your product emerging from various features, both important and trivial. Most of these versions will fail spectacularly, and only the best will successfully serve the market.

# So Many Reasons to Say Yes

When you’re in the process of creating a product, you’ll be inundated with great ideas. These ideas will come from your customers, colleagues, and even yourself. You’ll have numerous reasons to say yes because they are good ideas. Here are 12 arguments in the style of Don Lindsey that often lead unnecessary features into a product.

## “But the Statistics Look Great”

“We tested this feature with a small group of testers, and the improvements are noticeable on the graph.” This approach often suffers from selective statistical analysis. A product is a complex system. Even if the statistics are good and the data is stable, you still need to consider what your product represents and its intended purpose. Add Tetris to your product, and you might see improvements, but will your product truly be better because of it?

## “But It Will Only Take a Few Minutes”

In reality, time should never be a reason to add something to a project. Yes, it might be worth adding it to the plan and considering it later, but don’t strive to do everything now.

Many bad ideas can be implemented into a product very quickly. Don’t be tempted. There are no such things as small changes. In fact, even a minor change can complicate the product, and simplifying it doesn’t fit into those “just 5 minutes.”

## “But This Client Might Leave”

This is blackmail. No client is more important than a good product. This path will lead to creating a perfect product for one of your clients because you did exactly what they said. If you overvalue one client, it means you’re undervaluing all the others.

How to Create Terrible Software:

1. Promise the client their one-off features will be integrated into the project.
2. Fulfill the promise.
3. Repeat.

This cycle leads to disappointing results and a diluted product focus.

## “But We Can Make It Optional”

This leads to death by settings. Optional features hide the complexity of the main screen of the application, but this complexity starts creeping into all other parts. The visible cost of this is a terrible interface with a heap of conditional design and tons of settings. The hidden cost is the loss of your product’s focus. Your product becomes “an organizer that seems like it can send you bills and coordinate payments, but it doesn’t notify about current events, it’s unclear and unreliable.”

## “But My Neighbor’s Cousin Said…”

A week ago, I talked with my sister’s neighbor’s cousin. She perfectly fits our target audience (25 years old, female, holds a graduate degree). She said all her friends actively use hashtags. Thanks to her, I realized our product would fail without hashtags. I’m calling an unscheduled meeting tomorrow at 8 AM. Candy (her name) will join our video conference.
#Thanks #Team
End of transmission,
CEO

This sounds like a joke. It’s common in SaaS companies that can’t understand the work they’re doing. Extrapolating from a tiny sample is a sure path to years of testing, research, data analysis, and behavioral studies. Statements like, “My brother’s company uses Google Analytics, and they use advanced segments,” can lead to using advanced segments while bypassing questions like: What is it? What does your product do? Is your brother’s company good at choosing clients? Do they actually use it or just say they do? Does this approach suit you?

## “But We Have Nothing Else Planned”

Idle hands seek work. Many, seeing idle developers, come up with new features just to keep them occupied. Idea adoption accelerates—all to avoid idleness. This is not the best way to improve your product.

Instead of developers having a bit of extra time, they lose it. Everyone who works as a developer knows: “If you have time to be lazy, you have time to clean up code.” Free time is perfect for fixing bugs, cleaning test cases, refactoring. Don’t just keep the team busy.

## “But I Thought We Would Work on Whatever We Wanted”

This argument has become a classic. Many large companies promise developers that they will work on whatever they want and sell it. There are two outcomes:

1. It’s a lie told to attract developers. It quickly becomes evident and fails.
2. It’s true, and the end result is a completely useless product with half-baked ideas.

There is a difference between offering developers the chance to work on meaningful projects (good) and embedding unplanned features into the product (bad).

## “But 713,000 People Want This”

Avoid situations where someone tries to justify with raw numbers. Any developed product will find its number of consumers. For example: “We can fill Dolores Park with people who requested Excel integrations.” This forces you to veer off your original course and succumb to the influence of the crowd, becoming “one of them.” Can you really say no so harshly?

You must. Otherwise, most of your clients might suffer. The question is not, “Can we fill Dolores Park with people who need this feature,” but, “Is it valuable within the focus of our product? Will buyers use it?”

## “But Our Competitors Have It”

This doesn’t mean it’s a good idea. Maybe they’re just testing a new technology. This idea might not be brilliant. Maybe they’re already planning to remove it from the app. It’s a mistake to assume your competitors are smarter and more insightful than you. Obsession with competitors’ ideas can drag you down so much that you end up showcasing yesterday’s technologies only tomorrow.

## “But If We Don’t Do It, Someone Else Will”

This doesn’t mean it should be in your product. If someone else does it, will clients leave your product? Will they switch to another? Just saying, “someone else will do it,” is fine but meaningless. I find myself saying this often. This logic is used to expand the product because you don’t want to stop even for a second. You fear reaching the finish line of your project.

Example: A typical date includes movies, dinner, and going home. If the movie theater owner constantly worried about what other businesspeople would do and wanted to gain more benefits, he’d embed a restaurant in his theater and create a taxi subsidiary to transfer clients home. All these three services would be terrible. Then restaurants would start showing movies…

## “But Our Boss Wants It”

If the boss is also the product manager and has the time to make smart, holistic decisions, then it’s fine. But if someone is just trying to earn points in front of others, it will lead to problems.

## “But It Will Change Our Product”

The truth is, changing the product forces you to think deeply about what should be done. You might tell everyone about any change and claim it will definitely change the product, but it’s just a story. When you fear making serious decisions, you start believing that “this is it, the one thing.” You end up with a collection of ideas and a repository of their implementations, but not a finished product.

# Why “No” Is So Important

The thing is, nobody plans for failures. Identifying and cutting them out is straightforward. But the decisions made while working on a serious product are not so simple. They make you read the entire description of a feature and its implementation and say, “This is a good idea, I understand why our clients would like it. Great job. But we won’t add it to the product… Here’s what we’ll do instead.”

By focusing on the core value and refusing unnecessary features, you ensure that your product serves its target audience effectively without diluting its purpose.

---