If you build software products, it’s likely you’ve heard of a lot of different paradigms or approaches to new product development (NPD).
This isn’t about those. In fact, this article will never be published in a peer-reviewed journal. But it will, I hope, provide a quick shorthand to help you think about your PD approach.
Over the last two decades of designing and building software products, I’ve run across four kinds of people that step into the process with a particular “bent.”
Here they are and see if they match your experience. Also, see if I’ve missed any (and add them in the comments).
Feature-oriented Product Development
These are folks that start with one feature and get so excited by the feature (and the feedback on it), that they end up creating another and then another.
Products in this category end up with tons of features – almost to the point where they’re unusable because no one was thinking about interface or experience at all.
A perfect example of this is those Swiss Army Knives with tons of options. You know the kind – with a magnifying glass, scissors, tweezers, can opener and more.
If you’re on a team like this, my recommendation is to put a big pause after you land on a few features. I’m not saying you can’t release a product with 4 features. But take a pause and ask yourself if it’s enough.
Collect some feedback. See if your three features deliver enough value to generate some revenue. You can always add more features later. Taking them away is much harder.
Revenue-oriented Product Development
These are the folks that almost always talk about “core” and “add-ons” early in the process. They’re thinking about that segment in your target market where they know they’re leaving money on the table. So add-ons become their way of monetizing the approach.
Products in this category have a baseline product and then offer several additional offers as “add-ons” which are priced independently.
The trick to doing this right is to make sure that your add-ons aren’t actually parts of what should be in the core. You know you’ve done it wrong when you start hearing non-stop complaints about charging your customers for things that should have been part of the original product.
We’ve all likely experienced the freemium product gone wrong, where after using it a bit, we’ve had to pay a bit to get more access, or turn off ads, only to hit another barrier and be told we have to pay even more to get access to that part of the app.
If you’re on a team like this, praise the revenue-oriented team for thinking about sustainability. But work hard to define the user paths that help you know what is “core.” In other words, spelling checks and printing aren’t add-ons.
Experience-oriented Product Development
The features have been done for weeks. But your team won’t push them out the door because the experience isn’t right. These are the folks who tell Steve Jobs stories – even if they don’t have Steve Job revenues keeping the company afloat.
Products in this category may never see the light of day, or may start revolutions. You can’t tell until you watch market reactions. But that shouldn’t mean you make the “experience” the only thing. That is, unless it’s really the only thing.
If your team is trying to create a seamless experience that delights and constantly converts visitors into customers without much work, just make sure you’ve modeled the cost part of the experience well. This is what lets you then determine what kind of profit margin you can expect, which will let you know if it’s worth doing.
Pain-Oriented Product Development
Instead of focusing on the user experience, like the last group, this group of folks is focused on client pains. They know the pains. They can talk about the pains. They can even rank them.
I’ll be honest. This is where I hang. I likely saved it for last because it’s my favorite. But that doesn’t mean it doesn’t suffer from its own challenges and blind spots.
When done well, this approach only builds products for the top pains people feel. They solve pain 1, 2 or 3. They don’t build products that solve pain 27. It’s a Maslow kind of thing.
Some of my favorite products have only one or two features, but they solve a key pain. See if you can finish this sentence, “I’ve fallen and I ….” That’s a pain-oriented product.
The upside is that it protects you from building products that sound interesting but may not bring in the dollars, as the traction never comes.
The downside is that you can end up building a product and missing a key feature, simply because it was a given in an industry and no one ever communicated any pain about it. [Trust me on this one, we almost shipped a product missing the one key feature that 100% of our prospects and customers thought was essential.]
How’s your product development going?
There is no perfect approach. There is no perfect model. But there are some pretty amazing teams of people that consistently create amazing products.
Those teams function well because they know their defaults, know the potential downsides to having blind spots, and know how to work past them.
Wherever you find yourself in this set of models, I hope it helps challenge you to know about those blind spots. If so, you can work against them and focus on creating amazing products.