Several weeks ago, my company released a new product: a tool that helps small service businesses with client follow-up.

We did it very quietly, late one night after most of the department had gone home. A few of the product leaders made the decision, flipped the switch, and went home.

There was no public announcement, no social media campaign, no press releases. We just deployed it to the production environment and send an email to the marketing team to let them know they could start the digital ad campaign that would start funneling strangers into the product for the first time.

We all felt uneasy because the product that went live was ridiculously lean compared to the grand visions we had in mind for the product. We had stripped it down to its most fundamental components, and it felt like there were a million things missing from it.

However, that ultra-narrow feature set was just minimal enough that we could plug up the major holes and turn it into a self-contained product. It was small, but it technically worked.

And that meant it was time to launch.

Smart people want to think of every possibility

This product had been in development for years, so you might naturally expect it to be robust and full-featured after all that effort.

However, the version that launched was actually the smallest iteration of it anyone had ever come up with. And that’s exactly why we were able to launch it.

Product people all tend to suffer from the same curse: they’re really smart.

When you put really smart product managers, UX designers, and engineers together in a room, they naturally begin to consider every possibility:

• Everyone who might be able to use the product
• Everything they might want to do
• Every path they might take
• Every customizable option they might want
• Every feature they might ask for

Whiteboards are filled with passionately-scrawled diagrams. Walls are covered in sticky notes. Elaborate feature maps are prepared. Slide decks are designed.

It feels like it’s going to work, because they’ve thought of everything.

Only, that’s not how things actually go.

Master-planning doesn’t actually work

There’s a reason why pretty much every attempt to build a utopian community has failed.

It seems like every architecturally-minded genius eventually takes on the mental exercise of designing a perfect community, like Paolo Soleri’s Arcosanti or Le Courbusier’s Ville Radieuse.

Almost inevitably, they wind up becoming struggling tourist traps or half-finished ghost towns. Some achieve an awkward-but-functional equilibrium. The luckiest among them are probably those that remained unbuilt fantasies.

The main problem is (as usual) that people are complicated. Any time someone feels like they’ve got humanity all figured out, they’re ultimately proven wrong. They always miss something. Or hundreds of things.

If you live in a master-planned housing community, for example, you know that feeling. It’s probably very a pretty and convenient community, but deep down, you feel the artifice. It feels like you’re living in the Matrix. Despite all the careful consideration put into making you feel exactly not that way, it still does. And it bugs you a little.

Now consider the feelings stirred by some of the world’s most-loved cities: New York City, Paris, Bangkok, San Francisco, London, Singapore, Montreal, and so on.

From a master planning perspective, these cities are inefficient, outdated, and confusing. They’re suboptimal in thousands of ways. They’re everything utopian projects try to fix. Yet somehow, they just work. Day after day, year after year, they work. And people love them.

Evolving toward greatness

The reason these cities work is generally because they started small. Cities like these typically start as a few neighboring huts and farms. They eventually grow into a little village, then a town, and so on.

Instead of trying to answer the question “How can we become a huge city?” they simply dealt with their issues one day at a time, evolving gradually over time based on the needs of the moment. At each point, they’re creatively solving their real issues with real resources based on real priorities. There are always some inefficiencies and rework required along that path, but they were complete and functioning communities at every point along the way.

Product design works the same way. If you try to to build directly toward an idealized end state, you’ll have something partially-finished and non-functional through the whole process, and then  the needs will probably have changed (or were different from your assumptions) by the time you finish anyway.

Instead, you should start a product the same way a great city starts: you find a good location, put some huts near each other, and then you solve for the problems of the day, over and over and over again.

Lean product thinking is unnatural (especially to designers)

Designers love to talk about minimalism. We love to pin sexy-looking minimalist designs. We love minimalist fashion. We all repeat the same minimalist quotations:

• “Good design is as little design as possible.”
• “Great design is eliminating all unnecessary details.”
• “Identify the essential. Eliminate the rest.”
• etc., etc…

But if you ask pretty much any designer to design a product, they’ll do exactly what every other smart person does in the same situation: overthink, overplan, and overengineer.

This is the product designer’s curse, and we have to fight against it every day of our careers.

Let’s get uncomfortable

If you feel like your product just small enough to have covered all the essentials, you probably overdid it. That’s not what a lean product feels like.

A lean product feels like “Oh, no, I can’t believe we’re releasing this. It’s missing 90% of the features we wanted to add. We can’t go through with this. I feel sick….”

When you start to feel like that, you’re probably getting it close to right.

Why?

Because that’s when you’ve truly cut it down to just the core essence of something that will provide value to customers. It’s just barely enough that they might stick around for a minute and tell why they can’t use your product because it’s missing this feature or that.

But you know what? That’s awesome news. When customers tell you they won’t use your product because you’re missing a particular feature, you know know exactly what you should build next. You might have burned that customer, but it was worth it because now you know. You’re solving actual user problems instead of trying to master-plan a solution based on your own assumptions.

Traditional software looks like this:

• Build feature A
• Build feature B
• Build feature C
• Build feature D
• Build feature E
• Build feature F
• Build feature G
• Launch the product

But think of how much more efficient this is:

• Build feature A
• Launch and learn that customers really want feature E
• Build feature E
• Launch and learn that customers really want feature G
• Build feature G
• And so on…

This process is the shortest path between you and software that impresses your customers, software that feels like you knew exactly what they wanted—because you did. And you get to save time by not building the features it turns out they actually don’t care that much about.

To do that, thought, you have to learn to get comfortable with the idea of going live with feature A all by itself, as uncomfortable as that makes you feel.

(And this principle of stripping the product down can still apply even if you’ve already built out features, as I was reminded in this particular situation.)

How we made it happen

The first step is admitting you have a problem.

For us, that came when our VP pointed out that the various sections of the product we’d built didn’t feel like they had any “connective tissue.” Each feature was fine on it’s own, but when we put them together it felt like a mish-mash of different ideas. It just wasn’t tight.

We’d painstakingly designed all those different pieces, optimized them through user testing, and already coded them out. We’d sunk a bunch of time into the current direction already, and nobody wanted to shelve what we’d been doing.

But the VP was right: the product team had fallen into the classic trap of over-engineering a solution instead of focusing tightly on a single problem.

So we got the leadership together in a room with lots of whiteboards and we beat our head against them until we started to understand the real problem we were trying to solve: client follow-up. Every business owner has painful stories of the project they didn’t win because they missed a critical email, or the potential client who went with another provider because of the late response. We wanted to help them with that.

And only that.

We didn’t need all the features we’d already invested in. We didn’t need all the cool interfaces we’d designed. We didn’t need all the great code we’d already written.

We just needed to help small businesses follow-up with their clients. And we needed to do it in the leanest way possible.

So we took out the task lists, the project board, and all the other fluff, and we reorganized the product concept around a single feature: giving people an intelligent list of contacts they should consider following up with. Once they connected their email account, we could parse the emails quickly to look for clues about which ones might be important, and we would show them a prioritized list of contacts.

It doesn’t sound like much, but it was enough to provide value. That feature alone might have helped me-in-a-past-life not lose a potential six-figure project because I’d forgotten to reply to someone (which actually happened).

Breaking through to the other side

That focus is what enabled us to break through the revision cycle we’d been in for years and actually launch something. It was a quiet launch, but it was enough that we could start learning from real customers.

In the months since, we’ve learned a lot. The product isn’t great yet, but we’re working on it. Fast. It has already evolved significantly from the original version we launched with. It’s undergoing continued major iteration, and we’re learning more every week.

It would have been great if we’d caught ourselves earlier, but at least we caught ourselves at all. Some companies go decades without ever realizing they’re falling victim to the product designers’ curse. (You might even work at one of those companies.)

Step back and take a look at what you’re designing and building, and remember that if it feels like you’re trying to cover all the important things, you’re probably overthinking it. Try stripping it down to its core essence and see where you can go from there.