Aggressively cut scope
Complexity is the most significant contributor to a project's demise, and what brings complexity? Features. But most importantly, why do we add features? There are moments when features are an absolute necessity for the project's existence in the form of a business need. But in many other cases, features only reflect a lack of understanding at a business or technical level.
Simplicity is the ultimate sophistication.
To create a simple product or system, you must understand the business problem. And that's not easy. As an engineer, I tend to jump straight to the technology part to work and create stuff, but that's not ideal for us or the business we may be working for. It requires challenging assumptions about the problem and challenging peers and managers, but it can go against the company's culture. Therefore, any technical manager/lead is also responsible for understanding and questioning any design decisions as much as possible.
But let's skip the mindset of an employee working for a corporation for a moment and visualize ourselves as an entrepreneur or solo developer; there, feature creep is extremely dangerous. While in a corporation, extending the deadline may even be in the interest of the contractor/employee, for an individual or small team, it can be deadly. Deadly not only for the current project/company but for future endeavors, too. Let me explain.
There are two types of feature creep:
- Features requested by your boss or product manager. Those features are good because they are usually based on calculated cost/benefit analysis, and required for existing clients.
- Features developed for a new product without client feedback. Typically found in new SaaS startups or small teams. These features are created without any verifiable market need.
The second type of feature is dangerous because it increases the project complexity and reduces flexibility when adding new features. But it can also represent a deeper psychological problem. If the market is avoided, a.k.a. no real market validation is pursued, it could mean the team is afraid of failure, which manifests in perfectionism. And that perfectionism can be carried into other endeavors.
Perfectionism is a tricky word because it implies that somebody is trying to achieve "perfection." However, that's not really how perfectionism manifests in a capitalistic endeavor. Instead, it lurks as creating a product that doesn't suck.
Embrace the suck
To not be a perfectionist, means to allow, accept and welcome that your product will suck. Granted, it should eventually suck less than the other alternatives in the market in some regard to be economically viable. Here, the keyword is "eventually", right now, and even for a long time, it will suck, and maybe, it will continue to do so forever, but the process must be incremental. Fast and incremental improvements are the key.
This is why Y Combinator keeps saying: "Talk to your customers". I don't know how deep they go into the psychology of their founders but what they for sure mean is:
- Don't isolate yourself from the market.
- Do market research.
- Get comfortable with your MVP or idea sucking.
Features can become a way to escape the reality of the market. Therefore cut the scope, and to be able to allow yourself to cut scope, you must first accept that your software/service will suck. There is a reason that most software sucks because it is all about maximizing the value delivered to our users, regardless of how incomplete it may be at a given time.
