The structural problem with UX
Untested products failing in the market? No “seat at the table”? The root causes might go deeper than you think, and we’ll start with Conway’s Law.
You ultimately ship your org structure, so Conway’s Law says: big, bloated companies with lots of big, bloated departments wind up selling big, bloated products with too many dependencies.
So, we went Agile. We went Lean.
Then the trouble started.
This is no polemic against Agile — far from it: I have coached teams in Agile practices and have the requisite dodgy Scrum Master course certificate.
There’s just a loss of learning that has transpired in the rush to embrace more dynamic ways of working.
To explain, let’s walk back a little.
You need to be different
At the start of the 20th century, “pile ’em high and sell ’em cheap” was the mantra of factory bosses and fledgling marketers. Speed of production was paramount, which later developed into the efficiency gains of the Toyota years, which then gave rise to Agile.
If you focus on cutting costs, it’s a race to the bottom until nobody is making a profit.
If you focus on efficiency, you risk squeezing out your capacity to respond to the unexpected, tying up teams in red tape until the machine grinds to a halt.
Ultimately, the only sure way to sustainable profit is through differentiation. Famed business guru Michael Porter defined strategy as a set of decisions to choose an offering that you can sustainably and profitably provide that your competitors will find hard to copy. Coca-Cola, Ted Baker, the Fallout franchise and the music group Blackpink are great examples of differentiation.
According to CB Insights, over 90% of all products fail, most commonly due to no market need.
To be different in a way that resonates with customers, you need to understand the wants and needs of the people buying your product.
Customer intimacy as strategy
I learned research at a mid-sized company that grew into a large one. At its core, it was selling data, so analysis was highly prized.
Market Research, as the unit was called then, was part of the Business Planning & Marketing department — essentially, the strategy function — serving both C-suite and product teams.
As the business matured and developed, the team became Customer Insights, including most of what we’d call UX Research. A fledgling UX team did small and frequent usability tests, working seamlessly with CI, coordinated by the product marketing manager who would commission research.
At the next company, the line between Customer Insights and UX blurred further until I was placed in the UX team. My move into a full time UX role was the tiniest of sideways steps: I’d already been doing discovery (“depth interviews”), usability tests (“interview-with-task”), tree sorting, card sorting, surveys and observations for well over a decade.
More importantly, I’d learned from seniors and then passed that knowledge on to colleagues in both CI and UX — an underrecognised benefit of working in teams.
In mature companies, “research” is a broad and deep discipline conducted by teams of highly trained specialists.
Where did all the researchers go?
The modern startups I’ve encountered lately don’t have “Customer Insights”. Instead, they mostly hire designers who have covered research as one or two modules in a wider UX course. If they hire a researcher at all, they’ll typically hire just one who’s too busy putting out fires to develop a deep understanding of customer needs.
Much of the research work is performed by people outside of either CI or UX whose work will often contain dangerously misleading misinterpretations because they don’t know how to do research well. If you ask a customer if they would buy your product, they will probably say “yes”, just to please you.
Many business leaders conflate “agility” with “speed”, and, in the rush to produce more features more quickly, behave with reckless negligence:
If Agile is about shipping valuable software, it’s pretty risky to ship something you don’t know is valuable!
A designer will develop a prototype and put it in front of users, who will pick it apart and send it back to the frustrated engineer, who now has to do a ton of rework, because the unresolved problem is that nobody ever properly found out what was needed in the first place.
We’re not asking enough questions
The first coping mechanism I see from solo researchers or designer-researchers is interview length: calls of 15 or 20 minutes about products that don’t have extensive prior research. There’s not much you can learn in that time — the what, but not so much the why.
The quality of the work isn’t bad per se, but it’s too shallow to uncover the systems at work. Too much is taken at face value. I read the report, but it doesn’t tell me very much:
I understand that the user struggled to use the product, but I don’t understand who the user even is, and if you can’t answer that, there’s no point asking anything else.
To fix it, we need to go backwards
The first thing I did in my next role was embark on a process of reverse discovery:
- Who were the people buying the product in the first place?
- Why on earth did they decide to use it?
- Why are they still here?
My first interviews were up to 90 minutes each, going deep into everything from their morning routine to purchasing criteria. There’s a strong overlap with market research in UX discovery work because the market research work still needs to be done, whether you have anyone designated to do it or not!
No market need, no sales.
Even if you lucked out and have been selling well for a while, without that customer understanding, you will eventually part ways with the user needs and your sales will decline.
The first thing you need to do as a researcher is to understand who your customers are, even if that work should have been done years ago.
THEN you can pick up the pace
Once you have a clear set of validated behavioural personas, by all means have those quick evaluative tests. You already know their habits, routines, and current solutions — you don’t need to ask that every time.
My typical interviews have dropped from 90 minutes to 45 — a quick sense-check of their context, then straight into using the product.
Later, we can invite them back, and since we already know them, cut straight to the chase: 90 minutes becomes 20, and we’re no longer asking if we built the right thing, but if we built the thing right.
At my previous company, we could turn a small research project around in a few hours. My record lately is 36 hours, but we’re getting there.
Thankfully, we now have a market researcher to pick up the pricing and market landscape stuff while I deep dive into usability, working closely with designers. The payoffs continue to grow.
Unarguable benefits
When you’re producing valuable work, you don’t need to argue about it. The impact is subtle at first, but people start to pay attention.
I’m positioning Research as a function of Strategy because that’s what it is. It’s Day One stuff on every business studies, entrepreneurship or product management course.
If you don’t understand your customers, it is impossible to develop a strategy that works.
Most startups fail, but occasionally, one will luck out and coincidentally develop a product that meets user needs. You’ll spot them when they then struggle to replicate that success — the only way they can sustain their early growth is if they learn about what their customers truly need.
As that learning filters through, the benefits become self-evident, but if you’re on your own, you can probably only do that for one product, and that one product will thrive while the others falter.
I saw my previous company hire one researcher, then two, then four, then eight. It’s not about having big bloated teams shipping big bloated software, but having enough people to give sufficient coverage for the number of products in the portfolio.
The neglected products in understaffed companies are characterised by masses of unused features — if Agile is about “maximising work not done”, understanding your users is the only way to be sure that you are (only) doing the work that matters.
Having a team of researchers isn’t bloat; NOT having enough researchers is waste, because too many things will be built that people won’t buy or use.
In summary:
- To continue to grow, you need to be different in a way that meets customers’ needs. That means understanding your users
- Customer research is a broad, deep specialist discipline that goes far beyond usability
- Most startups don’t have enough specialist researchers, leading to untrustworthy research and excessive rework
- Most research at early stage startups is evaluative, which doesn’t tell us what users truly need. To fix it, we must discover who our users are, and once we know that, we can move faster efficiently
- Research is a core function of strategy — you cannot develop a good product strategy without understanding customer needs. To get that understanding, you need enough specialist researchers
You ultimately ship your org structure, so if your structure includes a team of enough researchers to understand your users’ needs, then your product will be efficiently focussed and positioned for success.
