A bright future for strategic thinkers

The ability to identify and frame problems is your most valuable asset.

A horizontal axis over which a series of upside-down orange rectangles move from left to right increasing their opacity — illustration by Ed Orozco

Engineering won’t be the most valuable tech skill for much longer.

As no-code app building becomes commonplace, and vibe coding gets better, the important question changes from “how do we build this” to “what should we build”?

Guess who’s great at figuring out what to build? Why, your friendly neighborhood designer, of course!

Design’s true superpower is identifying problems people will pay to solve. Developers and PMs can also do that, but design is uniquely positioned to translate those ethereal ideas into communication artifacts everyone can align to.

The problem is that, in most organizations, designers are relegated to a narrow space of creating solutions, rather than identifying problems.

Narrow focus on solutions

The process of building software usually goes like this:

  1. Stakeholder has an opinion
  2. They tell the designer to design it
  3. The designer designs it
  4. The developer builds it
  5. Some metric goes up or down but nobody knows why

This is how most software is made. It’s the result of a poor understanding of what design is. It rarely works unless you have loads of cash, and oftentimes that’s not even enough.

Restricting design to only finding solutions is problematic in two ways. It limits how much value it creates for the business and its customers — and we’ll talk about that in a second — but it also allows teams to fill up the product with failed features they ship hoping something will stick.

As more features are added, it becomes harder to make the overall design coherent and sensical. Soon features are crammed into corners that don’t make sense. — Jared M. Spool

It’s not always easy to deprecate failed features. The more useless things you put in the product, the greater the chance they’ll become dependencies for other important things.

Take two-factor authentication via SMS:

Turns out your users move a lot for work and switch numbers. So they often get locked out of their accounts, which means frustration and a lot of support tickets.

Had you done your research in advance, you’d have realized they would have preferred 2FA via an authenticator app or email. Now you can’t fully remove 2FA via SMS until you implement another authentication method. And then you have to get your entire user base over to the new method. Until then, people will continue getting locked out of their accounts.

What began as “let’s ship this thing we need” and “here, design this” became an expensive problem that will take weeks of engineering time to fix.

Oops!

Design doesn’t just prevent you from building the wrong thing — it helps you figure out the right thing to build. By discovering and framing valuable problems, design boosts the teams ability to innovate based on what the market wants.

Discovering valuable problems

The highest-impact part of the design process is identifying and framing valuable problems to solve. Valuable is the key term here. It has to be valuable for customers and profitable for the business.

“Product taste, user understanding, and the ability to define problems clearly are becoming more valuable than pure coding skills as Al handles more implementation.” — Lenny’s newsletter

Leveraging strategic UX research

I’ve been designing and building products for over a decade. I have yet to find a better way to discover valuable problems than talking with people. Sure, you can look at secondary data and narrow down your scope. But only by talking to people will you understand why certain issues are problems worth solving.

“Page visits reflect what you have, not necessarily what customers want. There may be tasks that you don’t have content for — so it’s unlikely they will show up in search and site data. And analyses of page views often reflect an amalgam of tasks; it’s hard to separate the top tasks on these pages from the tiny tasks.” — Gerry McGovern

There’s a widespread notion that research costs time and money that’s hard to justify. I believe this attitude stems from leaders conflating strategic UX research with tactical UX research. And there’s some important differences between the two.

Tactical vs strategic UX research

Tactical UX research is what most people refer to as evaluative research. This is when you capture users’ thoughts on existing solutions. Strategic UX research, on the other hand, focuses on problems for which a solution does not yet exist.

“The problem is, when you only work tactically, you never feel like you’re making progress. The teams always doing tactical UX research are caught in a feature factory.” — Jared M. Spool

It doesn’t have to be complicated. 2–3 conversations with users a week, which won’t take longer than 2 hours, can be instrumental on improving the adoption and retention of your product. Other than sales, it’s hard to think of an activity with a higher ROI.

Strategic UX research is one of the most important inputs in deciding what to build. If you don’t know what your customers or audience are willing to pay for, you’re best case missing out on business opportunities, worse case burning cash building stuff people don’t find important.

Framing problems

This is another way in which design steers the product development process in the right direction. Framing a problem helps align the team around the problem they are solving and, just as importantly, the problems they are not solving.

Problem Framing combines product discovery with a strategic decision-making process. It ensures teams align on the right problems before diving into solutions. — Dana Vetan

One of the simplest ways to frame a problem is asking who, what, why, where. Which is a variation of People, Activities, Contexts and Technologies (PACT).

The specific framework you use isn’t as important as the actual exercise of properly framing the problem and using that common understanding to resolve the inevitable tradeoffs of product development.

Wait, isn’t that what PMs are supposed to do?

Let’s talk about the elephant in the room: The turf war between product managers and designers.

In startups, where roles are more relaxed, designers have a lot of wiggle room to define their role and own larger parts of the strategic work. It’s important to achieve mutual understanding on who does what, early on.

You have to work in how you work. You have to invest time in defining the roles in your team and the agreements on the charter of your project and your team. How do we work together? — Christian Crumlish

As the company matures, though, the roles settle and changing them becomes harder.

In most larger organizations, strategy is the official responsibility of product managers and other stakeholders. Designers are there for mere tactical support. It that’s your case, rather than wasting your energy trying to change corporate culture from the bottom up, you’ll be better off transitioning into a PM position.

If your company doesn’t offer an IC track for designers, switching to product is a sensible step towards increasing your influence.

.
An estimation of the degree of business savvy between designers and product managers at different levels of seniority.

A bright future for strategic thinkers

Being good at identifying and framing problems, whether do bear the design title or not, is going to become a key differentiator. Everyone can ship, but not everyone can figure out what to ship.

While strategy is not exclusive to designers, their ability to produce artifacts to align stakeholders around a research-driven vision, is what will help the organization solve real problems rather chasing vanity metrics.

Sources


A bright future for strategic thinkers was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

You may also like...

Popular Posts