Show Takeaways!

Remember your target audience for your plugin before you cater to every feature request.  Better to have a product that easy to use and works for 95% of the people, than a product that’s harder to choose that works for 99% of the people.

Don’t put too many new features into a release, otherwise you’ll never release.

Today’s topic is about planning plugins, how to decide what features make the cut, and a behind the scenes look at WooCommerce.  Patrick and Meeko joins the show to discuss WooCommerce’s release cycle, how new features get picked for a release, and provides some awesome insight and advice for plugin developers on how to make sure your plugin gets to market.

With such an active (300 contributors and 10,000+ commits) and large (on over 380,000 sites) product with , Woocommerce is a surprisingly tiny team with 5 people.  Patrick shares how Woocommerce stays on the roadmap for releases and manages what features get in and what find themselves on the cutting room floor.

Show Notes

Patrick Doesn’t Sleep

• Patrick is the new WooCommerce Product Manager, he plans all of the features down the road at WooCommerce by performing research about the new features.
• Patrick is writing a book on WooCommerce and how to use it, set to be released in 2015.
• He also has developed a number of add-ons for Ninja Forms.
• Patrick also speaks at many WordCamps.
• According to him, his biggest asset is his blog.

WooCommerce’s Workflow

• By using an ideas board, when new requests come in they go on the board and get voted up to “fight it out” to make sure that it’s something the vast majority want.
• By reaching out to people who make the requests, Patrick can narrow the scope of the features.
• WooCommerce sets out to do 3 major releases per year, even though with ecommerce software you really only have 10 months in a year.
• They don’t use release branches and ‘master’ branch is their develop branch.

Plugin Roadmaps

• Keep releases small to get to release.
• Remember to test for backward compatibility.
• Adjust quickly and often to estimate time and effort.
• Build Unit Tests first, rather than going back and retrofitting them in.

Patrick gives great advice for developers to find your blogging voice.