Whether you’re out to develop the tastiest chimichangas north of Sinaloa, or the best order processes for your online shop, there are plenty of ways we unintentionally ruin what should be a good product.
It’s a story utterly familiar to most of us. We had a great idea, and everyone else thought the same. Everyone agreed “There’s just no way this wouldn’t work!”
Yet, by the time it’s made it to the introduction stage, it’s almost ridiculously far off from what was originally intended.
Sometimes this could be a good thing. Working out the kinks is the point of product development, after all.
Other times it doesn’t work so well. Mainly because no one could agree nor understand what the kinks are to begin with.
I’ve personally witnessed and been part of these problems all my professional life. See which ones apply to you!
Too much red tape
To quote The Thick of It‘s Malcolm Tucker:
“The Queen’s butler finds a cockroach in a pantry, he just stamps on it. She doesn’t even know.”
Unless perhaps, the Queen suffers a severe case of micromanagitis. Or if the butler had to file a 3 page report on why and how he stomped on the cockroach and needed the report read and signed off on by layers upon layers of bosses, boss’s bosses, and boss’s bosses’ bosses. Maybe next time, he won’t even bother to stamp on the next roach he sees.
If you’re creating a situation where everything requires multiple levels of approval, and where you invite more people than needed to make their mark on things they might not have full knowledge of, bad products are almost always sure to follow.
User experience isn’t everyone’s priority
This can happen a bunch of ways.
- A project leader might be too attached to a process or a tool, when it might actually slow things down.
- Copywriters might wrongly believe they’re ‘David Oglivy X Ernest Hemingway’ incarnate.
- Graphic designers might have fallen in love with Helvetica, or flat-design, or some other “circlejerky” trends.
- Coders might be more interested in elegant code than in dirtier yet more functional solutions.
- Analysts might start seeing numbers and statistics where most of us see people.
- A business owner might be more interested in short-term savings than they are in return business.
- Marketers might misunderstand the what customers want.
None of these situations are inherently disastrous. But if enough people working on a product lose sight of the customers they are creating it for, it’s easy to see how any of these motivations can prevent any product from achieving true greatness.
Creators serve higher-ups– not customers
This isn’t always a bad thing if the business owners and project leaders do have a genuine grasp of what their market really wants.
If.
And how often does that happen?
You’re all on different pages
Communicating the true purpose of a project and all the steps required is an absolutely necessary task. But it can get tedious. After all, who doesn’t (claim to) hate meetings?
It’s understandable that specialists from different fields who work together on a project might blank out when someone working outside their own immediate expertise brings something up. Maybe the ideas are too abstract, or too far removed from professional experiences. Or maybe they just write e-mails or conduct meetings in a way that annoys other people.
Whether we like it or not, this kind of thing happens all the time, and usually gets worse the more people in a project. It’s no surprise then that as the days grind on, everyone develops their own understanding of how things should go or what other people meant.
No one gets along
An environment where people make an effort not to talk to each other isn’t likely something you’d want for any team designing a product or service. True, some people do their best work best alone, but in the context of bringing a winning product to the market, this is hardly ever the case.
Not getting along doesn’t necessarily mean the end for a team or a partnership. Think of Shaq and Kobe from 1996-2004, or Noel and Liam Gallagher during Oasis’s most successful years. Or William Shatner and nearly everyone else on the cast of the original Star Trek.
But these tend to be the exception rather than the rule. Plus in those cases, lines of communication were still mostly open for those involved.
When you’re trying to create something both coherent and functional, a team where everyone can actually stand each other enough to actually communicate possesses a definite edge over one where passive-aggression has taken hold.
We want to make things easy for ourselves–not users.
Sorry lazy people who think you’re bright: Hard work beats talent when talent doesn’t work.
Bill Gates has often been misquoted as saying:
“I will always choose a lazy man to do a hard job. A lazy man will find an easy way to do it.”
Not only did he not say it, but what kind of “laziness” do you think we’d be talking about? Is it the kind where you do a horrible, slack job so you create even more work for yourself and others in the future? Or does ‘lazy’ in this context mean more efficient– meaning you put in more hours only when it actually matters?
Face it. The bare minimum effort very rarely aligns with things people actually want. If you’ve ever had to work with underpaid coders, designers, and writers — or anyone from Fiverr, basically — you know just how this goes.
This kind of attitude however, isn’t confined to whoever happens to be underpaid, and the temptation to “slack off” non-productively will probably always be part of the human condition. Keep your eyes on the real prize and you’re most of the way there.
There aren’t enough generalists in your team.
An often misused proverb goes:
“A jack-of-all-trades is a master of none”
True, for a lot of technical fields, you need to put in a massive amount of time in order to just be proficient, let alone specialize in it. But that doesn’t mean we shouldn’t try to know more about how our work meshes together with what everyone else does.
In fact, this absolutely has to happen if the whole package is to make as much sense as it could. But of course, it might be a stretch to realistically expect everyone to be great at everything. But managers absolutely have to be a bit generalist if they are to be effective.
Effective leaders as a rule, tend to be pretty good or at least decent at most tasks involving their projects, but probably not as good as those assigned to do specific things.
But they don’t have to be. All they have to do is understand enough of it so they know how things go together.
You’re pushing for a perfect solution when ‘good enough’ is the best way.
“A good solution applied with vigor now is better than a perfect solution applied ten minutes later.”
–General George Patton
A degree of perfectionism is often necessary to produce quality work. In psychology circles, a healthy amount of this is often referred to as “adaptive perfectionism”, where one is able to take the situation into account and accordingly adjust their goals. The opposite is “maladaptive perfectionism”, where perfect solutions are sought at any cost.
The line between the two isn’t always that easy to find. Steve Jobs was a notorious perfectionist who oversaw the development of products that were crafted with painstaking attention to attention to detail, yet often managed to lag behind its competitors in key areas. His approach was responsible for many of Apple’s successes, but also their failures as well.
How often have you stymied your own growth because you were holding out for the best possible choice? The truth is, there is no way to know if a choice is a good one until after it’s made. Sure, you can use historical data to figure out likely outcomes, but in the end, at least a few things will be up in the air.
There are very few real world problems where an absolutely perfect fix will present itself. For example, there are motorcycle riders against mandatory helmet laws because we can still die despite wearing them. However, it’s undeniable that helmet use greatly reduces the chances of dying in a motorcycle accident.
Maybe your product would be ‘better’ if it contained a certain feature. But what are the associated costs with it? How much are you willing to give up so that it can happen the way you want it?
Image credits: all images licensed under Public Domain or Creative Commons via Wikimedia.org
What other product and service development problems have you faced? Comment below!