The overall goal of this series is to provide strategies that single developers (or small teams of developers) can use to help plan, build, market, and maintain successful WordPress projects and do so on little-to-no-budget.

In the first post, we covered several important aspects in planning the project. Specifically, we took at a look at how to conduct some cursory market research, how to strategically name the project, and some high-level tips for branding the project.

At this point, we're prepared to begin building the project; however, this doesn't mean it's time to begin writing code.

Define the Features

Before getting started implementing your idea, it's important to identify exactly what the project is going to do. To go one step further, this doesn't mean that every feature that you want to implement provides much value to your potential users.

Just as we discussed in the last article, simply because something seems fun or interesting doesn't mean that it's a candidate for a project or, in this case, a feature. Instead, it's important to critically examine the problem that you're trying to solve and narrow down exactly what's required to make it happen and nothing more.

Reducing the project down to the most basic level is typically called the the minimum viable product. Think of it this way: what is the simplest set of features needed to accomplish what you're trying to do?

If you can answer that question, then you're not only prepared to identify your project's MVP but you're in a position for planning the next version (or several versions!) of your project.

Draw the Roadmap

Ideally, the MVP should be your 1.0 - it will be a simple solution for the problem at hand and lay the foundation for future development.

One easy way to identify your 1.0 is by the following exercise:

• List out all of the features that you want for your application
• For each feature, identify those that are absolutely critical for solving the problem and collect them in their own list.
• For the features that are not critical, place them in a separate list.

Ultimately, you'll be left with two lists: the first list is your feature set for 1.0, the other list serves as feature candidates for the next release.

The advantage in doing this is that you're preparing yourself for a strong 1.0 as well as a roadmap that will continue to give life to your product for at least one more version.

Bring it To Life

After determining the MVP and planning the product's roadmap, you're just about ready to begin writing code. The only outstanding decision left is to determine what version(s) of WordPress you are going to support.

For example, if you want to target only the current release and forward, then you only need to configure your development environment using that version of WordPress; however, if you plan to target say, 2.9 through 3.3, then you'll need an installation of WordPress for each version in order to properly test your work.

At this point, you're ready to write code. Depending on the size of your project, it can be helpful to have a development methodology in place. Various techniques, styles, and methodologies are beyond the scope of this particular series, but here is a suggested approach for working on your project:

Each project - be it a theme or a plugin - can be thought of as a collection of functions. Each function should serve a unique purpose within the overall context of the project. As such, reduce each feature down into a function (or set of functions) that you can implement one at a time. As you implement each function, test that particular code before moving on to the next.

Doing any sort of big bang development (or writing all the code before testing) can prove to be needlessly time-consuming. Instead, think in small iterations and repeat the process until development is complete.

a Note About the Market

Although this is a bit premature since we haven't really discussed how to market and manage the project, it's important to note that the market may respond differently than you anticipate for your roadmap. That's expected and acceptable - you just have to be prepared to change course!

For example, say that you release 1.0 and plan to begin working on features for the next version but your receive a significant amount of feedback that seems incompatible with what you initially planned to development.

That's okay! This not only indicates that your 1.0 was a success, but that your customers are looking for you to continue improving their experience by taking a product in the other direction. Gather their feedback and perform the same exercise as above.

If the market fails to respond, that's okay. That doesn't mean that the product was a failure - people are much less likely compliment a product than complain about it. Assuming that you have a consistent stream of downloads (or purchases), don't let the lack of feedback be discouraging.

To be complete, it is worth noting that there is always a chance of failure. If your product never seems to take off or your receive an extraordinary amount of negative feedback, then it may be worth re-evaluating the product.

Plan the Release

Assuming that you've completed development and testing and have project bundled and ready to release, it's time to plan out the release date.

This can be somewhat arbitrary but it's important to give yourself enough time to prepare documentation, the project's web site, and demo site (if you plan to include one). It's also important to leave enough time to talk with certain people that can help you market the launch of your project in order to get the word out.

In the next post, we'll take a deeper look at releasing the product as well as look at a few [free] strategies that we can use in order to publicize the product launch.