It seems like quite a few new projects have been popping up in the competitive TF2 community recently. Some of these ventures have been successful, others have fallen, and we’re still waiting for a few. Many will probably know of the one I’ve been involved with, PugChamp, and most would place it in the first category. Given my recent experience and general knowledge about past and present projects, I’ve started thinking about what makes projects successful, and have come up with a list of factors to consider.
The first and arguably most important factor is the scope of the project. When it comes to new projects, it is almost required that the project has a reasonably-sized, well-defined scope pertaining to what it’s aiming to accomplish.
Attempting to be too ambitious may lead to important goals not being hit and the project, even though it may have accomplished part of its purpose, being deemed as an overall failure. It’s been my opinion that the establishment of CEVO as a league aiming to completely replace ESEA as soon as possible is an example of this, and its failure to do so quickly enough led to its collapse, despite the fact that it might have been a great secondary league. (I’ll discuss more of the problems that CEVO had overtaking ESEA below.)
In contrast, the scope of the project can’t be too small, or else it may not end up being anything of note and worth. There isn’t any specific example I can give for this, but most people probably won’t have the problem of dreaming too small.
Reasoning is a bit more of a personal factor, though there are cases where it can be an important force driving the project to completion or a barrier that is hard to overcome. As a result, it’s important for each person involved and the project as a whole to ask the question: “why am I/are we going forward with this?”
If the answer to that problem is something trivial like “I’m bored and thought this might be interesting,” there should be some level of skepticism applied to whether the project has a long-term future. While some great things have come out of boredom, they tend to be ignored or even discarded when more interesting projects come along. I can readily provide my own example: StatusSpec was a project born out of boredom in spring 2014, and gradually grew into a behemoth of a project as that boredom continued. However, I’ve had many other pursuits and involvements since then, and it’s no secret that it (and many other projects) have suffered as a result.
On the other hand, a really good reasoning can help an individual define their role in a project, or even help a project define its own purpose. This is something I can ascribe to projects like TF2Stadium, which were born out of ideas like “this project and the people behind it have acted against the interests of the broader community, and we want to make a service that serves the community first and foremost.” Applied properly, projects can use a purpose like this to drive their own longevity and interest, but they must make sure that the purpose is kept at the forefront and always remembered.
Position in the Market
Even if a project is simply aiming to provide a service, it’s important to consider what other “competitors” there are. One of the best ways to ways to make sure a project has a good shot at success is entering a space where there are no other competitors—a unique niche. If there are no competitors, it’s pretty simple to make something useful: if it provides value, people will use it.
If there are competitors, it becomes much more difficult to gain a share of the market. Naturally, the players already in the market already have inertia, and it will be difficult to convince people to move to a new project without significant incentives to do so. Going back to the current PugChamp example, tf2pug.me, the site it replaced, was already unstable and crashing fairly frequently with no end to the problems in sight. On the other hand, PugChamp was built to be more stable and provided more features like ratings.
If the incentives to switch are not significant, a new project will be forced to compete with the other established projects for a much longer period of time, which may be detrimental to the success of the project. A great example of this was CEVO when it was established as an alternative to ESEA. The primary reason most people had to switch was better community interaction—lpkane’s public persona was very abrasive, and the ESEA TF2 admins seemed to be unresponsive to the community’s needs, while CEVO was formed by Lange and Nahanni, both figures who were admired for their many contributions and seen to have the community’s best interests at heart. Unfortunately, ESEA had many advantages over the new league, including a better prize pool, an established LAN, better game servers, and more sane scheduling. This combined with its inertia due to already being the league for top-level play meant that CEVO had a very large hill to climb. The two leagues did compete with each other, but when it came down to picking a single league (due to not having enough time to participate in both), enough teams preferred ESEA and many more teams decided to play in ESEA as a result. As a result, CEVO collapsed the very next season.
For a project to have success over a longer period of time, it really helps to have a good team behind it. While there are many talented individuals who could build amazing projects on their own, there is so much better that they could do if they worked together. A project team, if set up well, supports itself and makes sure that everyone is working for the benefit of the project.
A team also helps make the project viable long-term. It’s hard for a new person to pick up the pieces left behind by someone who has gone on to other ventures, which will inevitably happen to most people making successful projects. Of course, the same applies to a new team trying to replace an old team, but the likelihood is that not all of the old team will move on simultaneously, and hopefully enough will remain behind such that the project is not entirely lost. Once again, I will admit to being guilty of this, with many of my projects (all done individually of course) in various states of disrepair, from being incomplete to being swept aside for another project. (It’s not necessarily a bad thing that an individual wants to do more things—most people that are good at what they do rarely want to do only one thing and leave it at that—but it shouldn’t be an excuse to move on without tying up the loose ends of whatever is going to be left behind.)
Of course, it’s important to make the team well-suited for the project. Too few people will leave the pressure of the entire project concentrated, and too many people may prove impossible to manage. In addition, not everyone is created equal—some will have different roles than others, and this will need to reflect in how the team is organized. Unfortunately, I don’t really have an example of a good team to show you, simply because it’s very hard to make a well-balanced team.
This is perhaps more of a personal preference, but I do feel that projects must not make too many promises or create too many expectations on what they are going to deliver. It relieves pressure if people don’t know what to expect, and surprising them with something unexpected will always work better than letting them down after overhyping a project.
Hype can certainly be a very powerful tool if used correctly, but it’s quite often overused. As a result, I’ve come to regard it with a high dose of skepticism. I try to practice what I preach and avoid hyping up my own efforts, preferring honesty and secrecy (though I’m imperfect and sometimes break my own rules). This approach is the one we took with PugChamp—most people were unaware that its development was occurring, in the case that we were unable to accomplish our goals, and only found out when we had something tangible to show in the form of an open alpha. Quite a few other projects in this community do try to take the hype approach and thus never seem to meet the expectations in a timely manner.
Good projects usually don’t come out of nowhere. Due to this, new projects created by previously unknown members of the community receive a lot of scrutiny. Part of it has to do with being skeptical to combat hype, but more of it is due to trust. Almost all people can’t judge the merit of a project easily, so they use trust to figure out whether the project is worth considering, and in general people who are known to have invested themselves into the community or are otherwise well-known are more trustworthy than those starting out.
This naturally presents a problem to those who might have a legitimate project but don’t have enough reputation yet. One option is to recruit trustworthy members of the community into the project in order to bolster the project’s credibility, but it might be difficult to do so if the project isn’t already in an advanced stage and the people behind it don’t have the reputation. Another option, generally slower, is to work with those members of the community on other projects and gradually earn recognition and respect. Of course, a project can always try to proceed despite not being backed by well-known people, but that path will always be fraught with peril. It is worthy to note that it is possible to do, as I once did with StatusSpec back when I didn’t have any contributions to the competitive community, but the project has to distinguish itself on its merits without the help of a creator’s good reputation.
It’s always important to remember for whom the project is being created, because they always have to be considered when it comes to building a project that is truly helpful to them. While Steve Jobs had a nice saying about the customer not knowing what they wanted, it is important to remember to listen to them to get a better understanding of what they really need or want. Getting a better understanding will help the project to be the best that it can be.
That being said, understanding when to ignore your audience and do something different for the better of the project is also important. It should be fairly rare that this has to be done, but acquiescing to the audience is not always the best approach. Unfortunately, understanding when to go against an audience is just as difficult as understanding what they truly want or need if not more so.