Building Product Families in WordPress

You sit in a room and talk about creating a product. Right? You know what I’m talking about. You talk about features. You talk about the interface. The UI and even the UX. Right?

And then you break up and the engineers head back to their desks to start thinking about how they’ll pull it off.

If it’s their first product, or it’s a pretty big departure from what they’ve been doing, they’ll design the architecture using lessons they’ve learned, but beyond that, the underlying architecture will be unique to that product.

Then it’s rinse and repeat. Right? You build a second and maybe a third product.

And since some of these products aren’t huge, since they don’t take forever to code, you don’t always think much about architecture. Or if you do, it’s from a scalability perspective.

The result is often two-fold:

1. You get three or four products that feel unique to each problem they’re solving.
2. At some point, down the line, your developer suggests rewriting one of your products, to leverage the things you did on another product.

Product Families

Enter the concept of engineering product families, which when you talk about it, feels like common sense.

In a very real way, most WordPress plugins all are part of the same family, given how they interact with the core code of WordPress.

Yet, we have further to go.

The Development Benefits

I got to witness a bit of the behind the scenes work when Thomas Griffin was finishing up Envira. What struck me about his process was how much learning he was doing as he went along.  I’m not just talking about what he was learning about WordPress development. He was doing that, for sure. But I also mean he was learning things about coding his sales pages, his automated emails, and more.

You know what he did, right then, as he was wrapping up Envira? He announced he was going to work on Soliloquy 2.0. You know why? To apply all the same learning he just had on his next product iteration. And his development time on v 2.0 was super fast. It was impressive.

The trick to product family architectures is that it speeds up development. It takes the cost and effort of learning a “best practice” and delivers a return on that investment immediately.

But I don’t want to spend a lot of time on development dynamics today. Instead I want to talk about the user experience.

The User Benefits

This weekend I worked on a site for a friend. It was so nice to use three plugins on that project:

• Envira – the best gallery plugin for WordPress sites
• Soliloquy – the best slider plugin for WordPress sites
• Optin Monster – the best popup plugin for WordPress sites

You know what these three have to do with each other? The coding was done by the same guy. And, as a result, they share enough in common with each other to be considered part of a product family.

When you upload and install the plugin, you’re reminded to activate your license key, to get access to add-ons. Every one of the products works exactly the same.

And once you do, you can click on the Addons tab, and you’ll get the same experience for each of the three plugins.

Of course, this means you don’t need to download and install each add-on from the main product site. You can simply do it from within the settings page of the plugin. Further, you can choose what you add/install, and then separately, what you activate.

At this point, you’re saying “Seriously Chris, so what? Can’t other plugins do things like this? Doesn’t Gravity Forms do this?”

And the answer is yes and no. Lots of plugins have a way to think about add-ons. And the entire idea of add-ons (a la “We want to be the WooCommerce of __________”) is part of a product family architecture dynamic.

So yes, lots of plugins do this.

But that’s not my point. My point is that these are three different plugins that each work the same way!

Check out these samples.

When the experience translates across plugins, the winner is the end user.

Are we ready to mature, when it comes to product development?

Remember I told you that after you build a product or two, you’ll start realizing you can use learning from one for another? Remember I told you that you would likely want to go back and rewrite your old products (which is great, but also increases your total cost of development on that product)?

It doesn’t have to be that way.

When a product ecosystem matures, developers learn to leverage architecture and usability patterns so that they don’t need to learn things the hard (and costly) way.

It means we slow down a bit, and ask questions about our intent.

When everyone else is rushing to create a minimal viable product that isn’t very viable and is barely a product, you could choose to slow down a bit and think about developing product families rather than single products.

I really hope we’re at that point. It can translate to a pretty big win for developers, designers, and customers alike.