At DrupalCon Los Angeles I gave a Core Conversation with the unassuming title "No", where I argued that in order for the Drupal project to be successful in the long term, it needs to have a clear and explicit focus. While in part it was an excuse for me to work Grumpy Cat pictures into a DrupalCon presentation, the broader point is one that I believe bears reiterating.

Companies or projects that can't focus tend to have problems. Instead of doing one thing well, they end up doing lots of things poorly. For instance, in an infamous 2006 internal memo that became known as “The Peanut Butter Manifesto”, a senior executive at Yahoo! argued that the company lacked a cohesive vision and was spreading itself too thin trying to be everything to everybody… like peanut butter on bread. In his words, "We lack a focused, cohesive vision for our company. We want to do everything and be everything – to everyone." Sure enough, Yahoo! faltered badly with no killer feature or service and is still struggling to make up lost ground from that era.

Jack Welch, former CEO of General Electric, said it bluntly: "If you don't have a competitive advantage, don't compete." Put another way, if you aren't striving to be the best at something, it's not worth doing. Say "no" to anything where you aren't working to be the best.

What is Drupal's focus?

What do we, as Drupal, want to focus on? And how do we determine if we're doing so successfully? There's no clear, explicit consensus on that within the community. We try to support new contributors and let "rough consensus" decide what we accept or not. That is great for community building, but it doesn't scale to product management at the scale Drupal is now. There’s no way to establish a clear, explicit consensus on what the project wants to focus on (and not focus on), or how to determine if we’re doing so successfully.

Emma Jane Westby called this problem "The Danger of Having No Why" at DrupalCon Austin. Our nominal mission statement roughly boils down to "be a good CMS". What being a good CMS means, and what problems Drupal seeks to solve, is an undefined question. The mission statement doesn't provide any guidance in terms of what functionality to focus on, or what type of user to emphasize. In her words, "We need to stop pretending to be something that everyone will love."

Without a clear and explicit focus, Drupal runs the risk of becoming what Jeff Eaton has called The CMS of the Gaps: a "generic" system that tries to be "good enough" for everyone, but is not great for anyone. That in turn makes Drupal vulnerable to increasingly strong focused tools (Wordpress for blogging, PHPBB for forums, Symfony and Zend Framework and Laravel for custom business logic, etc.) that are not standing still, but getting stronger and more inter-operable every year. We can't "do everything and be everything to everyone" if we want to do that well.

What of Drupal 8?

In the five years since I last talked about its audience priorities, Drupal has made a radical shift. Drupal 8 jettisoned many old assumptions, made significant cultural changes, and reinvented itself as a more modern content management platform.

Drupal 8 shifts the emphasis more heavily toward a certain class of content management that makes a discrete distinction between usage and administration, with a strong emphasis on content strategy and platonic content.

As Drupal has become a stronger CMS, it has become a weaker pure framework. And that's fine, given the shifts in the rest of the PHP market. Tools like Symfony and Zend Framework fill that space better today, while Drupal is a far better content management platform than rolling your own on top of a bare framework. That specialization means end users still have Free Software options for different use cases, and they're better than expecting one generic program to serve every use case.

Looking at what we've accomplished in just a few short years, I am incredibly proud of the work the community has done, both technically and socially. However, the process of getting there was incredibly and unnecessarily painful. Because we didn’t have a well-defined decision-making process, we saw increased conflict and burnout within the Drupal core developer community. Quite simply, the path that we are on will not get us where we want to be.

The new core governance model is a big and positive step forward. Subsystem maintainers and the Product Owners now have greater clarity and autonomy in their roles. But those people need to not only have but communicate, and agree upon, a clear focus for both the project and for their areas of responsibility. If we're all pulling in different directions, or worse no direction, then we're back where we started. If we can all be in explicit alignment in terms of what the goals of the project are, and are not, we can all drive toward that "Why" faster and more effectively, both for the remainder of Drupal 8's development and well into the future.

Deciding Who Drupal Is (And Is Not) For

If we want to improve developer morale and avoid defaulting to the “CMS of the Gaps”, then we need to prioritize certain tasks and use cases at which Drupal needs to excel. And that means saying “no” to other tasks and use cases. That distinction needs to be one that is both explicitly made and communicated, so that we know that at the end of the day everyone is on the same page.

This means that as a project, we need to be thinking about questions such as:

• What edge cases are just not worth supporting due to the instability they'd cause in the system?
• What types of applications are we okay with people not building in Drupal?
• What features are we willing to not accept, because they make the code too brittle or complex for the other use cases we support?
• What site is just "too simple" for Drupal to be an appropriate tool?
• What site is just "too complex" for Drupal to be an appropriate tool?

There are a couple of ways we can go about answering these questions:

One would be a revision to Drupal's mission statement to make it more targeted and actionable. The current mission statement doesn't provide any guidance in terms of what functionality to focus on, or what type of user to emphasize. A mission statement should be a statement that you can always refer back to and say "does this thing support that statement? If yes, do it. If not, say no."

Another useful tool is personas. Personas are an important part of content strategy and user experience for a website, but also an important part of product development. They can help identify the users that are being targeted, and how to serve their needs, but, by extension, those features that are not useful to an identified persona are easy to exclude.

Take the Content Working Group's personas for Drupal.org users, for instance. They lay out five personas: Newcomer, Learner, Skilled, Expert, and Master. The purpose of Drupal.org's content is to help people move up that scale as smoothly as possible. However, the working group makes this very explicit statement:

For further clarity and focus primary and secondary personas were determined. Primary personas are who we design for first. Each primary persona requires their own set of features and content, and the needs of a primary persona will not be met if we do not design for them explicitly. The needs of secondary personas can mostly be met by focusing on the primary personas. However, there are a few needs specific to them that we will need to accommodate for.

Based on user interviews, Learner and Skilled were determined as primary personas. Secondary persona is Expert. Newcomer and Master are tertiary personas.

That is, Drupal.org is "for", primarily, Learner and Skilled users, and helping those users get to the next higher level. Content decisions should be made, primarily, to support those users. Content that would help an Expert or Master user is fine, but only if it doesn't hinder the primary goal of aiding and training Learner and Skilled users.

That provides a clear framework for deciding not only what content and information architecture to adopt, but what to not bother spending resources on and, potentially, what content to reject (at least from high-level pages) as it would confuse that primary audience.

Similarly, we could develop "use case personas" for Drupal. These personas are not archetypical people but archetypical sites or applications. For what type of site or application do we want Drupal to be the world-recognized obvious best choice for? And in order to achieve that, for what type of site or application are we willing to say Drupal just is not going to be the best fit and likely never will be? We need to ask, and answer, both questions.

At the very least, we need to define some metrics to define our focus. In late 2010, on the eve of Drupal 7's release, I noted that the HTML5 Working Group has a very clear metric by which it guides its focus:

In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.

Drupal needs to define its "constituency tie-breaker" metric and apply it consistently. Favoring different users over others in some issues, but the other way around in others, does not help Drupal succeed. It just confuses both contributors and users.

Getting to “Yes” by Saying “No”

Focusing on a goal is how one achieves it. Focus is a prerequisite for effectively achieving that goal. And focusing on that goal means not focusing on other potential goals.

Few people enjoy saying "no" to someone. It's difficult. It should be difficult. But that doesn't mean we can avoid doing it. Sometimes we need to say “no” in order to make an explicit decision, as opposed an implicit amorphous one. Implicit decisions are those that get made for us by us environment, by our process, or by someone else we don't know. Those kinds of decisions are rarely the best ones. To once again quote Jack Welch, "Control your own destiny or someone else will."

Saying “no” and saying “yes” are complementary tasks. While we can’t say “yes” to every feature, by explicitly eliminating a few, we can focus our efforts, and our decision-making about what to include or not include, on those that remain. And by building a collective priority of audiences and use cases that puts us all on the same page, we can support those users at the top of our list even better than we do today.

So as we wrap up Drupal 8 and start looking toward 8.1 and eventually Drupal 9, I put the question to everyone: To what shall we focus our efforts on, and to what we say “no”?

Those questions cannot be separated.