As you work through the requirements for your product, you’re going to run into a classic problem: what should it, and what shouldn’t it, do? How much flexibility do we offer users?

The temptation, when standing at this recurring fork in the road, is to opt for flexibility. Potential customers flash though your head as you imagine the myriad of scenarios your product will need to support: “But, what if someone needs to make it turn upside down and inside out? We need to be able to support that!” And, while you’re undoubtedly well-meaning, you’re also probably being irresponsible.

Here’s why:

Flexibility isn’t cheap. Flexibility – especially in an enterprise context, where this kind of nonsense can get radically out of control – incurs cost for your organization in at least three ways:

• Design Cost – with increased flexibility comes increased time and effort needed to mitigate the inevitable cognitive  overhead you’re going to dump on the user. Additional features means increasing complexity. And while we know we can’t get rid of complexity in a product, we have to do something with it. That something is design, and if it’s done well, it won’t be cheap.
• Development Cost – it goes without saying (hopefully), but extra flexibility is also going to incur extra development cost. Building features and options takes time sitting down and writing code, and code costs money. Often, lots of it.
• Market Opportunity Cost – this is the sneaky one, and it’s based on a fairly simple principle: additional flexibility doesn’t translate into a linear increase in user satisfaction or market adoption. The fact is, additional flexibility increases complexity, which increases risk in the product. This risk puts increased pressure on design and development to deliver a solution that mitigates complexity in a way to reduce the attrition due to a degraded product experience. Unfortunately, the pressures of most product development cycles short circuit this critical design and development attention, and the product goes into the marketplace with a sub-par experience, costing the company product adoption, all in the name of “being attractive to as many customers as possible”. Ironic.

So, how do you know what to include?

Understand your market, and understand your go-to-market strategy.

Understanding your market is about research – know who your users are, why they’re using your product, and what they need out of it. Go talk to them! Find out what their lives are like, and use that understanding to carve out a set of offerings that meet the major pain points.

Secondly, understand which customers are important, and when. This is about understanding, clearly, how your product gets to market, and what your initial period of adoption looks like. Which core customer group is going to be the most important in gaining that initial product traction? What are the major things we can solve for them that provides real value? How do you deliver the value proposition to these customers, and what features are required in the delivery of that value?

The key in this is understanding who’s not important. Knowing which markets you’re likely to go to market with initially helps you trim features and flexibility that other markets may want or need. Being able to say, definitively, “That’d be nice, but it’s not going to be a deal killer for our first 12 months of customers” is an absolutely critical level of awareness if you want to get out the door quickly, and with a product that’s lean and excellent at what it does. And, this is exactly the kind of awareness that most companies aren’t able to get to, at least on their initial product offering (hopefully, by product #2 or #3, they’ve learned the lesson).

Do me a favor. Next time you sit down to spec out your next product, start with what it won’t do in this release. Intentionally cut things out. If it makes you feel better, put them on the roadmap for the next release. Do whatever you have to do to say no to yourself and your team.

This is all about balance. Your goal, as you spec your product, is to come up with as little functionality as possible to make it viable until the next release. Be absolutely ruthless on your quest to cut things and limit flexibility, and you’ll find yourself launching a much more focused and effective product.

It’s trite to quote it, but Mies Van Der Rohe did have it right – less is more.