Hiring someone with no domain experience might be the smartest hire you make

We’re taught to hire for expertise. For familiarity. But lately, I’m seeing the opposite unlock better outcomes.

When you bring in someone with no baggage—just raw problem-solving skills and a beginner’s mindset—they question everything. They notice friction others accept. They redesign from first principles.

And more often than not? That leads to simpler, smarter solutions your users actually love.

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.

5 Tips to Improve Your UX Team

Building a great UX team is more than just hiring ‘better designers’. Even the best designers will fail if their work environment doesn’t set them up for success. Over the past decade of leading, building, and growing user experience teams, there are five key areas I focus on that result in noticeable and speedy improvements.

Resourcing

It’s hard for a UX team to be successful if you don’t have the team to keep up with the demand. The backlog only gets bigger and the design debt builds up. You need to ensure the UX team is staffed appropriately to the Product and Engineering teams you’re working with.

If the Product team is bigger than the UX team, the workload demands will quickly surpass the team’s capacity. From there, the UX team could get a reputation for being slow or the bottleneck, or worse, teams start to work around the UX team resulting in poor experiences making their way to your users.

If the Engineering team is bigger than the UX team, then they’ll quickly burn through the work that has been properly researched, designed, and validated. Now engineers don’t have anything to work on, and again, the UX team gets a reputation for being slow.

My rule of thumb for UX team staffing is typically 1:1:1—one product manager to one UX designer to one engineering team. This is only a starting place; you may need to increase or decrease those numbers, and it may vary by team. For example, one team might only work on a set of APIs, so they’re not likely to need a dedicated UX designer.

Team Culture

A UX team one of the few jobs where 25% of our role is criticizing others’ work. If the team doesn’t have a healthy culture and strong guidelines for healthy critiques, then the team will spiral out of control. There are several great resources on creating a healthy environment for critiques. Below are two of my favorite:

• Book: Discussing Design: Improving Communication and Collaboration through Critique
• How to Cultivate Healthy Design Feedback

Beyond critiques, the team has to like and trust each other. That means you need to create time and space for people to connect at the human level. I found that a monthly happy hour or brunch (for international teams) helps, as long as the time is engaging and helps build connections between each other.

Streamline Processes

Every new design hire brings their ideas of how work should be done. Right or wrong, those ideas are typically different from how the team is currently operating. When teams aren’t operating under the same processes or quality standards, you have a misalignment. With your team, define your design processes, critique processes, escalation process, file storage and labeling, documentation standards, meeting cadence, etc. Write it down and have the team all sign off on it. Now the team can work on fun parts of the job and solve real problems and make users happy.

And by the way, you just wrote 95% of the onboarding docs for all your new hires. Good job, you.

Prioritization

There likely will never be enough designers to do everything, which means you need to work with your counterparts to determine how the UX team can deliver the most value for the company and users.

Now, prioritization isn’t just saying ‘no’ to people. Every decision has to have a reason, and you have to realize that you’re not a dictator… others have to agree with your decisions.

Your team should focus on projects that move the needle on your business KPIs. That’s it. That is the framework that should be used with all your Product cohorts when prioritizing design workstreams. You should be asking:

• What KPIs does this project support?
• Is it more important than X, Y, or Z?
• Do we have the skillsets to deliver a quality outcome?

Be Visible

Make the design work visible to the company. This could be regular newsletters where you share design prototypes or research insights. Or it could be smaller, maybe a regular email to the senior leaders of the top 3-5 design wins or outcomes. It could also be presenting at the company All Hands meetings, or giving your team shout-outs regularly in front of others. The important part is to socialize the work and impact the UX team is doing.

It’s That Simple… in Theory

Easy, right? Of course not. That's why they pay you the ‘big bucks’. Not all of the areas will be problem areas for you and your team. But hopefully, this can serve as a guide for areas to evaluate and look for hot spots or areas you can improve.

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.