While it tends to go against my personality, I continue to learn that when developing a really good software product, we must default to saying no. We operate in a societal culture where we are too quick to say yes to everything – after all, many of us are “go-getters” and “pleasers”. We WANT to say yes…it feels GOOD to say yes…but it isn’t always BEST to say yes. Building a good software product is about having a coherent view of the problem you are trying to solve, and determining the simplest approach on how to solve that problem. It isn’t about trying to code for every edge case or adding features for the sake of adding features, even when those features might seem “useful”.
While the default should be no, there are so many seemingly compelling reasons we think we need to say yes. A few of those that we continue to be challenged with at DonorDock are:
It will be quick to add
This one is one of the most dangerous reasons why we might say yes. While it may be true that the code to implement a feature might only be a few lines or take a small amount of time, it is all of the downstream work that really takes time. The QA time and additional complexity, along with the risks of unintended consequences are typically much higher than the cost of developing the code itself. All of these things have costs, both real and intangible, that are often overlooked by developers.
Another pitfall to this reasoning is that it perpetuates quick decisions on features and often short-circuits the thoughtful approach that good features are built on.
Fighting this tendency is one of the most challenging things for developers and visionary leaders alike, but defaulting to no and taking the time to reflect properly on the feature is always the best approach.
It can be optional
While this may seem like a good compromise, adding “optional” features that can be turned off and on creates a messy system. Not only must you create conditional logic in your application, it adds additional burden to your support team. Customers may not realize the feature exists, or may not be sure how to disable the feature if they don’t want it, all leading to more support calls.
You should also argue that if a feature is “optional”, does your product really need it to begin with? Does it truly help solve the problem that you are trying to solve in a simple way? If so, why make it optional at all? If not, why have it all?
The team has nothing to do
I would argue that there is always something to do, and often times these things are not as “fun” to develop as new features, but can be much higher value work items. Adding features to keep people busy is a dangerous tactic. Once again, it sacrifices thoughtfulness for speed. If we are just trying to keep people busy, we likely haven’t completely thought through the feature, haven’t designed it well, and it ultimately won’t land. Instead, take the time to allow your team to work on paying off technical debt – refactor code, perform additional QA and testing, or write better documentation. All of those things are high value, and ensure that you are being purposeful when looking at new features.
A competitor has the feature
Just because a competitor has a feature, doesn’t mean it is a good feature. You have no idea, or control, over their processes and how they determine what features to add. In short, you have no idea if they default to no.
Also, trying to copy features from a competitor will always have you playing catch-up. Instead, spend your time thoughtfully and purposefully thinking about how you can innovate in solving the problem you are solving with your application. Never build a feature to check the box that you have it because a competitor has it. This will not lead to the results you are looking to achieve.
A customer says they will leave without it
Building features for one customer isn’t building a software product – it is building custom software. These two things are very different and are mutually exclusive. The idea that we would create something for one customer is the first step down the road to a custom piece of software that works really well…for that one customer. This sacrifices all other customers and their needs in the process. In this scenario, if the customer cannot find value in your software without that one feature, then there may be other solutions on the market that fit them better. Call the bluff, take your time in analyzing the request and whether it fits your vision and helps ALL of your customers, and your product will be better because of it – this I promise.
The CEO really wants it!
This one is a challenge in a lot of software companies, including DonorDock. Many CEOs are visionary leaders who are always churning out new ideas. It is important to take the time to really understand and reflect on the ideas, analyze the fit within the product, and make sure to design and plan them properly. It is also important to say no to ideas that don’t fit the vision for the product, or don’t provide value to the customers. Some CEOs are very involved and knowledgeable about the product, the target market and how best to deliver value to the customers – others are less so. Understanding that can help to make saying no easier.
As someone who has been in both a CTO and a CEO role, I have started to develop some self-awareness about this topic. It is important for a CEO to understand the impact their ideas may have on the rest of the business. For example, a quick drive-by socialization of an idea may be mis-interpreted as a directive from the CEO to build or work on something. Making sure to be clear about intentions and creating a culture where your team feels enabled to challenge and say no is an important step in curbing this desire to just say yes.
What we do at DonorDock
At DonorDock, when discussing new features and determining our road map, we ask ourselves a few questions:
- Does this feature serve our target market and have broad applicability within our customer base?
- Can we add this feature without creating unneeded complexity within our product?
- Does the feature truly enable small nonprofits to fund-raise more and better engage their donors?
If we can’t answer yes to all of these questions, this isn’t a candidate for our product. A lot of ideas make it to the road map for a product – this doesn’t mean they should ever make it into a product. This is why I don’t believe in sharing a road map with customers or prospects, but that is another blog for another day.
In the end, my best advice when it comes to product management is to default to no.
.webp)
