Your Customers Didn’t Attend the Meetings That Built This

You know exactly where the settings live. You understand why there are three different dashboards. And that slightly confusing step during onboarding? There’s a perfectly reasonable explanation involving an integration, a deadline, and someone named Kevin.

Your customers know none of this.

They’re trying to get something done. Preferably without needing the director’s commentary.

When you’ve spent months or years building a product, you accumulate context that makes everything feel more obvious than it is. You remember the decisions, understand the terminology, and instinctively work around the rough edges.

That knowledge is valuable. It can also make it difficult to see what the experience asks of someone arriving without it.

That’s where outside help comes in.

You’ve learned the choreography.

Using your own product is a little like performing a dance you’ve rehearsed a thousand times. You know the transitions. Your feet go where they’re supposed to go.

A new customer is still trying to figure out which way to face.

You might recognize an icon instantly because you helped choose it. They’re wondering whether clicking it will download a report or launch something irreversible. When you know what happens next, it’s easy to overlook how little the interface explains.

Your fluency with the product can hide the effort it takes to learn it.

One useful exercise: watch someone from your intended audience complete an important task without coaching them. Ask them to explain what they’re thinking. Pay attention to hesitation, wrong turns, and assumptions.

Resist the urge to say, “Normally, you would just…” That sentence is often where the interesting part begins.

Every feature has a backstory. Customers still need a clear path.

Products grow through decisions that can make perfect sense individually.

Sales needs something for a prospect. A customer requests another filter. Engineering finds a practical workaround. The founder has an idea during a flight. Eventually, the product has the plot density of the Game of Thrones, and completing a basic task requires knowledge of Phase Two.

An outside partner can help examine how those accumulated decisions work together.

Where are customers making the same choice twice? Which labels reflect your internal org chart? What gets in the way of the task people actually came to complete?

The goal is to understand what still earns its place and what needs to change. Sometimes the most valuable design work is deciding what can be combined, clarified, or retired.

An embedded partner first job is to ask better questions.

When someone says, “We need to redesign this screen,” I want to understand what’s happening around it.

Who uses it? What are they trying to accomplish? Where do they struggle? What happens when they get it wrong? What evidence points to this being the priority? The answer might lead to a screen redesign. It might reveal that the problem starts three steps earlier—or that the interface is carrying the weight of an unresolved business rule.

I bring those questions into conversations with founders, product managers, engineers, support teams, and customers. Each sees a different part of the experience.

Then we can connect the pieces, identify what needs investigation, and make a decision with something stronger than whoever delivered the most convincing monologue.

Excellent presentation skills. Still a hypothesis.

Fresh eyes need evidence, too.

Being new to your product doesn’t automatically make the partner's opinion correct.

Your customers may understand an industry term that I need explained. A workflow that initially looks cumbersome may serve an important requirement. Something that bothers me might barely register for the people using it every day.

An outside perspective is a starting point for investigation.

I pair that perspective with customer conversations, usability testing, product data, support patterns, and the knowledge already inside your team.

That helps us separate a personal reaction from a recurring problem—and a recurring problem from one worth prioritizing now.

We can then test a focused change before committing to a broader rebuild. The size of the investigation should fit the uncertainty and the consequences of getting it wrong.

An embedded partner stays for the complicated part.

A critique can point out problems. Moving a product forward also requires decisions about scope, dependencies, ownership, and what the team can realistically deliver.

As an embedded partner, I work alongside your team through those decisions. That can include clarifying priorities, mapping workflows, testing concepts, building reusable patterns, and reviewing implementation.

You get senior design judgment connected to the actual work.

Sometimes that means challenging an assumption. Sometimes it means helping the team move forward with a sensible compromise. Sometimes it means saying, “This part works. Let’s spend our energy elsewhere.”

Every feature doesn’t need its own *Renaissance* tour.

Keep the vision. Check the experience.

Being close to your product gives you conviction, history, and insight that an outside partner needs to understand.

My, and any other's embedded partner's role is to help you see where that knowledge is doing work the product should be doing for its customers—and help your team close the gap.

If every demo requires narration, customers keep missing something you consider obvious, or the roadmap keeps growing while the experience gets harder to explain, we have a useful place to start.

I’ll bring the questions we need to make the next decision clearer. You bring the vision, the constraints, and the story about Kevin.