Design Leaders Must Prioritize Time with Customers

Design leaders: If you haven’t talked to a user in the past two weeks, you’re cooked.

As design leaders assume more responsibility, one thing often falls through the cracks: direct connection with the user.

It’s understandable. Your calendar is packed. You’re thinking about hiring, team morale, headcount plans, design systems, research roadmaps, cross-functional alignment, showing impact—the list never ends.

But here’s the truth: If you’re not deeply connected to the user’s challenges, none of it matters.

Most design leaders think the job is running a design team. It’s not. Your job is staying obsessed with user problems.

You were put in this position to solve problems. Real ones. You were probably promoted into your position because you’re really good at solving user problems. But if you drift too far from those problems, you risk leading a team that is active but ineffective—busy, but not impactful.

Success Tracks Directly to Time with Users

Want clarity on what matters? Want to empower your team to focus? Want to show meaningful business impact?

Spend more time with users.

It’s that simple. Staying close to their frustrations, goals, and realities gives you the clearest line of sight into what your team should build—and why. It’s how you avoid chasing vanity projects and start delivering real value.

If your team is always shipping but it’s hard to articulate the impact, chances are you’re solving problems that don’t matter. And the fix? Time with users.

How to Stay Close to Users (Even When You’re Busy)

Here are practical ways to build a consistent user connection into your leadership routine:

💬 Executive Sponsorships

If your company assigns executive sponsors to major accounts, ensure you’re included in the rotation. These relationships offer a high-fidelity line to customer needs, especially for strategic, high-value users. If your org doesn’t do this yet, advocate for it—it’s a game-changer.

🧠 Sit in on Discovery Research

Not just validation. Discovery. You want raw, unfiltered user pain. Shadow your research team on calls or listen to recordings. Ask to be looped in on early-stage work where users talk about goals, frustrations, and context, not just how they’re responding to a prototype.

🆘 Listen to Support Calls

Customer support is a goldmine of insight. Join live support sessions or watch call recordings. You’ll hear the real pain points in users’ own words—and start to notice repeat patterns fast.

🎧 Join the Support Rotation

If your company allows it, work a shift. Triage tickets. Answer chats. Escalate bugs. It’s humbling—and enlightening. You’ll quickly see the delta between what you thought users struggled with and what they experience every day.

💼 Sit In on Sales Demos

Sales calls give you the unvarnished first impression. What makes people lean in? Where do they get confused? What promises are being made? You’ll understand how your product lands with new users and how your brand story is being told.

📹 Watch User Call Recordings (But Don’t Stop There)

This is the easiest path—but the least rich. Recordings are helpful, but they lack nuance and depth. You can’t probe or dig deeper. Use them as a supplement, not a substitute.

🔑 Tip: Not sure where to begin? Talk to your heads of Research and Customer Support/Success. They can plug you in right away.

So… How Much Time Should You Spend?

Let’s look at the math.

One 30-minute user call per week? That’s 1.25% of your workweek. That’s not enough. Your calendar reflects your values—whether you like it or not.

Years ago, John Chambers (former Cisco CEO) said something that stuck with me:

“Show me your calendar, and I’ll show you what you value.”

He’s right.

If understanding user needs is at the core of your team’s success (and it is), then you need to block meaningful time for it.

I recommend aiming for 20% of your time.

That’s about 8 hours a week, spent actively listening to and learning from your users.

Is that a lot? Sure. But so is the cost of working on the wrong things.

Final Thought

Being a design leader means you’re no longer just shaping pixels—you’re shaping what gets prioritized, why it matters, and how your team makes an impact.

And the only way to do that well… is to stay close to the people you’re building for.

AI In Your Product: Magic or Transparency

Yes, AI is pretty nifty. But when integrating AI into your product, you have two paths:

One—seamlessly integrate AI into the product, making it feel like magic for the user. The product is smarter, which makes the user feel smarter. Until it isn't. Sometimes, AI things go wonky (technical term, I'm sure), leaving your users frustrated and blaming your product.

Or two—call out that it's powered by AI. However, this could prevent users from trusting your product or make them opt out of using that feature or product altogether.

Which path do you choose? When and why?

The answer, of course, depends on the experience you're designing—and your users' tolerance for unpredictability.

If your AI feature is additive—something that enhances but doesn't make or break the core workflow—magic might be the way to go. Think auto-tagging content, generating a first draft, or suggesting an action. The risk is low, the payoff is high, and when it works, it feels delightful. When it doesn't, users can easily course-correct.

But if the AI is critical to success—driving decisions, surfacing key insights, or replacing a human task—it might be better to show your work. Users want to understand what's happening under the hood. They want transparency, clarity, and sometimes even a little control. Acknowledge the AI, set expectations, and design affordances that allow users to review, edit, or override as needed.

There's also a third path: contextual transparency. You don't need a flashing "AI did this" badge on every screen—but you can signal it thoughtfully. A well-placed tooltip, a short explainer on first use, or subtle visual cues that communicate what's automated versus manual. Transparency without fear. Trust without overwhelm.

Ultimately, it comes down to trust, clarity, and control. Not just what the AI does—but how you help the user understand what just happened, what they can do about it, and whether they feel empowered or undermined by the experience.

Because the real magic isn't that AI is in your product. It's when your user still feels in charge—even when they're not.

The Case for Outputs

Scrolling through twitter I stumbled across Barry’s post—Your Mission is to Produce Outcomes, Not Outputs—it got my interest immediately. As I was reading Barry’s post, I found myself nodding my head. A lot of good points. But I think it’s easy to miss what Barry is stressing, which is essentially to deliver value you can measure. So many people interpret this as ‘skip documentation and just ship something’. But that’s not the case at all. Sure, outputs aren’t typically a business model, but they’re tools that enable speed and quality.

In many cases, the maturity and size of the team determine the need for outputs. For a small, stable team, where the vision is clear and there are no blockers, many outputs could be skipped. But for large teams, often with various layers of stakeholders, outputs can help a team fire on all cylinders, reduce duplication, and quickly transfer context.

Yes, businesses survive on outcomes

Essentially Barry is saying the only real deliverable that matters is the outcome—the thing that moves the needle. Process maps don’t generate value, but a product that eliminates those process pain points might be worth more than gold. Outcome-based businesses value results. If your customers don’t succeed your effort is wasted—regardless of all the output you create along the way.

So many times, teams are showing dashboards of vanity metrics, or chart porn. These outputs make the team look busy, but it’s the same type of busy as hamsters on their wheels.

However, there can be a case made for outputs with outcomes. Outputs can be key to making sure outcomes are targeted, relevant, and impactful.

Outputs help makes success repeatable

Some products just work—AirBNB, Instagram, etc. There was a clear hole, the founders knew the space and how to solve it, and they nailed it. In these cases, the founders were scratching their own itch—they knew the problem space well. So why doesn’t everyone just do that? Well, it’s hard. And often times, teams are paid to scratch someone else’s itch. A lot of teams have found that a process can help them repeatedly hone a solution into a valuable product. A process, or checklist, is a way of ensuring you don’t forget key steps when you’re tired, excited, or just pressed for time.

These checklists often generate outputs that serve as inputs into next steps. For example, in the product design world, we generate personas to better understand the type of users we’re targeting—these are typically in the form of presentation slides or poster outputs. We then use those personas to map their journey in a given scenario and highlight their pain points (typically delivered as a poster). Then we co-create solutions around those pain points, validate, then integrate those solutions into our product. We follow this process whether it’s a new product or existing, digital or physical. It always works. If we jumped right into the journey map, we might gloss over one of our most important personas.

But checklists aren’t just for product development or innovation. Many industries use checklists to ensure a thorough job is complete—safety inspectors, pilots, and even busy shoppers. In fact, pilots depend on them for every flight. Yet we don’t say ‘a pilots job is to fly, not check lists’.

Checklists help us stay on track, and follow a process we’ve proven to work.

Outputs can reduce duplication

Often times different products within a business or organization will share similar users, scenarios, workflows, etc. In those cases, teams often dig up past project outputs to get a better understanding of what we know, what we don’t know, and what to validate. Now, typically we don’t take those old outputs as gospel, but it provides a baseline to validate and build on.

Without those past outputs, we start over fresh. This not only burns additional cycles, but it can start to negatively impact your stakeholders. If you interview a key executive every year asking similar questions each time, by the third time they might not accept your call.

Similar to history, if you don’t learn from your past outputs, you’re doomed to repeat the same discovery.

Outputs transfer knowledge

But the most powerful use of outputs is to preserve the context of the work. It could be helping the customer understand the impact of your findings or vision, or merely to educate so they can empathize better.

In large enterprise companies, it’s not usual for teams to morph over time—team members get promoted, move to other teams, or even other companies. Outputs help the team document knowledge along the project in meaningful ways, onboard new team members, and quickly answer ‘why are we doing this?’.

Rather than depending on tribal knowledge over time, new team members can review a few key outputs and get up to speed in no time.

Outputs create the outcome

Okay, not really. But often times, a proven process often generates and iterates outputs, and those outputs become inputs for future steps, and so-on. Those outputs and iterations will help ensure you’re making good decisions. It will help make sure your final solution is on point. It will help track your success, and know when you get there.

Move fast but don’t break things

Facebook’s motto used to be ‘Move Fast and Break Things’. Now, I have no idea how Facebook actually works, but hearing that motto and things like ‘Outcomes over Outputs’ always conjures images of bus-boys rushing to clean tables and get dirty dishes back to the kitchen only to have a bin full of broken dishware.

Barry is right—don’t fetishize outputs, because outcomes are the real value. But don’t throw outputs out the window; just find the right output. Realize they’re tools that can often help large teams get to value faster and more often.