Startups fail for a number of reasons. And some of the most common ones have nothing to do with the product itself. Many startup failures that I’ve seen have come down to one issue: the inability to settle creative disputes effectively.
Of course, settling disputes effectively is really difficult.
Dictating from the top-down, for example, inevitably leaves one side feeling slighted or offended. It also fosters resentment for you as the decision maker. Whatever conclusions you come to when finalizing creative direction should be seen by all sides as fair and logical — in other words, supported by data.
That’s why the best place to start when it comes to conflict resolution is prioritizing data and logic.
But how, exactly, do you do that? What if both parties involved believe passionately that they’re right?
The best way is to find some way to quickly “test” each side’s opinion or hypothesis to produce measurable results.
Then these results can then be used to determine the most logical course of action. The goal here is to encourage a culture where people are okay to be “wrong,” and whatever proves most logical is considered most fair. You shouldn’t test every dispute meticulously, but when two sides are at a serious impasse, abiding by this technique will be far less expensive than a continuing, never-settled argument.
Here’s how to do this correctly, depending on the situation.
1) Design decisions
Creative decisions are some of the easiest to test, yet they can often be the most contentious and emotional.
At Dairy Free Games, I witnessed huge blowups between designers over seemingly tiny decisions. Ironically, more often than not, the smaller the issue, the bigger the blow-up. Designers are innately emotional and passionate when it comes to their opinions and perceive them through a more qualitative lens. The good news is, even qualitative opinions are easy to quickly test.
One of the easiest ways I’ve found to test UI/UX decisions is to run a fast usability test online on UsabilityHub.
With a “5 Second Usability Test” on UsabilityHub, you can test with a real end-consumer and quickly get the information you’re looking for. Even under the Free Plan, you can get access to a 2-minute test, which is more than enough. And if you tap into one of their pre-selected panels, you can literally get the results back in minutes.
Photo source: UsabilityHub
What you end up with is ethnographic information that informs you of a real end user’s gut reaction to the design. It acts as a first impression. Even for creatives, that’s data that’s hard to deny.
In the end, we are making a product for somebody else. Having your team understand this and optimize for testing any hypothesis on the end consumer (whenever possible) is one of the best ways to mitigate creative disputes and create a more collaborative and data-driven culture.
2) Product decisions
Testing lends itself neatly to settling product disputes, too. Whether you’re a gaming studio or an enterprise software company, you’re already testing multiple iterations of nearly everything you’re doing anyway.
Photo Source: Decision-Making Strategies for UX Product Designers
For example, when it comes to product marketing, it’s very easy to test different versions of your product’s messaging. Test new positioning with a simple set of Facebook ads targeted at different demographic segments. Rather than continuing to hypothesize, or finding out you made the wrong decision months later, in as few as 1–2 days, you can get a large enough sample size to be much more sure of your decision.
You can apply the same test-oriented approach to the actual building of product features, too. At Dairy Free Games, we tested new ideas for games or features by way of paper prototyping. The idea was to do as much legwork and testing as possible before coding any logic. If things passed the paper-prototyping stage, we even had a separate Unity app. In this app, we tested new ideas or UI layouts just to get playability data and catch any edge cases.
This may seem like a lot, but it is more work to add a half-thought-out feature or piece of logic.
And then needing to roll it back, taking the time to test and sort out edge cases upfront is a big time saver in the end. Think of it like you are writing an essay back in high school. Everybody hates writing an outline since it’s more work up front, but it will inevitably save you time in the long-run and keep your thoughts much more structured.
3) Engineering decisions
Technologies are always changing. If you read Hacker News, it seems like there is a new “must-use” technology, process, framework, or tool released almost on a daily basis. And naturally, many of the conflicts I’ve seen on the engineering side come back to the innate desire of all engineers to want to re-architect the work of their predecessors or test out new technologies.
Your immediate thought as a founder is probably that there are already enough risks for your startup. Why introduce even more risk by incorporating an unproven technology? But obviously, you can’t reject every technical “risk” and hope to produce a modern product.
As a founder, you must refocus your engineering team into thinking in terms of cost-benefit.
They need to think through what will provide the most value for your company as a whole. If the engineer’s proposal actually could have material benefits for the business (cost-adjusted), and he or she comes to you with a well thought-out and logical argument for why then it’s your duty as the founder to test it.
Instead of this decision turning into a stalemate full of hypotheticals, give your engineer 1–3 days to fork your codebase and implement their idea or build a quick sample app using the new technology. After this time, you will not only have real metrics to support a decision, but your engineer will also have learned something in the process that they can go back and share with their team.
4) Process decisions
When you’re contemplating a process change, especially one that will affect all teams, it’s best to conduct your testing on a single “guinea-pig” unit before disrupting the process flow for everyone else. Otherwise, if the change proves unworkable, you’ll be forced to roll it back across your whole company, which is expensive and time-consuming.
Consider, for example, the ever-contentious decision to switch project management tools.
At Glu, we used Jira for our project management suite. Of course, everybody constantly complained about it, suggesting newer and sexier tools like Asana or Trello with Power Ups. Multiple times, we’ve tried making the switch with one team, and almost always the results come back that although Jira is not the greatest, it’s still the most effective for us.
The expense of coming to that conclusion? Relatively low, because we do it with one small unit.
When making decisions, it’s best to conduct your testing with as small of a sample size as possible. A single team or unit will do.
At the end of the day, what matters is peacefully resolving creative disputes with logic and transparency.
This means that you, as the leader of your company or team, must always lead by example. You can’t ever assume that what you believe is automatically correct. You must appreciate the importance of testing for the most logical outcome as much as you encourage the rest of your team too. And you need to come to the bargaining table prepared with evidence to back up your reasoning. Creating a data-driven culture starts from the top.
So when a person is resistant to testing their opinion, for example, especially when the test is easy and fast, you need to make it known to your team that that’s unacceptable. If you want a culture where the best decisions always rise to the top, everybody needs to be comfortable being wrong, as often that’s what’s best for the company.
Remember, there will always be disputes within your teams. To an extent, that’s a good thing.
You want a certain amount of creative friction — that’s what drives progress. But that’s only true if you push yourself and your team to approach creative conflicts with the correct, data-driven mindset.
This piece was originally published in Crunchbase.