Beth Martin’s talk invites product teams to stop obsessing over the thing they’re shipping and focus instead on the experience people have around it.

You can build an excellent app, website, or database, but if the path users must walk is confusing, slow, or frustrating, your “awesome product” will still feel bad to them.

Start With Who Your Users Really Are

Martin asks us to imagine we’ve built a digital product for a specific group and now need to scale it to a broader, more diverse audience we don’t know well. Her first move is to “time travel” back to the beginning and re‑examine what we know about our users.

She recommends creating personas that capture:

• The roles your users have

• The different types of users

• Their motivations and goals

• What they are trying to accomplish

You can ask questions, analyze existing data, and observe behavior, but she emphasizes that the best way to understand users is to talk directly with them. Those conversations become the raw material for everything that follows.

 

Map the Journey and Look for Friction

Once you understand who your users are and what they’re trying to do, Martin suggests placing their actions on a timeline in a journey map. Each key moment in the experience becomes a touchpoint.

She uses buying plane tickets as an example:

• Research where you want to go

• Compare ticket prices

• Select a flight

• Make all the additional choices and confirmations

Each of these is a significant point in the journey. Some interactions are smooth and easy; others are dreaded and frustrating.

When you can see those points laid out, you can identify where you need to remove friction or barriers.

Martin notes that if you make the early parts of the journey easier, everything that happens further along the timeline becomes easier too. The work you do “upstream” reduces pain “downstream.”

She also talks about friction in another way:

• For tasks that happen frequently, you want them to be easy and fast. Like submitting an IT ticket.

• For tasks that happen rarely but matter a lot you actually want some friction. (Like paying taxes!) That friction gives users time to validate numbers and double‑check that they have the right information, often with prompts like “Are you sure?”

Sometimes improving the experience means taking things out so people aren’t slowed down unnecessarily. Other times it means adding friction where a pause and a confirmation are valuable. Examples would be steps, forms, or requiring signatures.

Expose the Hidden Work – Swim Lane Diagram

After you understand the user’s journey, Martin recommends translating it into a swim lane or business process diagram.

Here, each row represents a stakeholder or role that has to do something for the journey to succeed.

In this picture:

• The user might submit a form in one lane.

• That form then goes to someone in another lane who must approve it.

• Then it may go to yet another lane for a second approval.

• Finally it returns to the user—sometimes with a rejection such as “You forgot this information.”

When you draw this out, it becomes clear where friction points live. For example, if forms are often rejected for missing details, one solution might be to tell users up front exactly what they need to provide, so approvals flow more smoothly.

By combining user research, journey mapping, and swim lanes, Martin says you can get “a really good picture for this mess you’re trying to solve.” The complexity becomes something you can see and work with, rather than a vague sense that “things are hard.”

Mid‑project? Use a Pre‑Mortem

Martin acknowledges that this kind of deep understanding takes time and is not a one‑time task. But what if you’re already in the middle of a project, making a big change to an app or website, and you don’t have time to do full user research and mapping?

Her answer is the pre‑mortem.

A pre‑mortem assumes that your project has failed in the future, then asks everyone to imagine why.

It’s a way to:

• Bring the team and stakeholders together around a customer or user experience problem

• Let people voice concerns and risks

• Build empathy, much like journey mapping does, but focused on the project and stakeholders instead of end users

Martin stresses that this exercise is flexible. You can run it on an online whiteboard, or you can just use sticky notes and markers in a room. The important part is the conversation and the structure, not the tools.

She also mentions a related idea, where you imagine the project has been a huge success and you are looking back at what made it work. You can then reverse‑engineer those success factors.

How the Pre‑Mortem Works

Martin describes a practical, step‑by‑step way to run the pre‑mortem around a customer or user experience issue.

1. Name the issue
   Start with a clear CX or UX topic. This could be some communication issue, experience problem, or big change you’re about to make.

2. Brainstorm concerns (blue notes)
   Give everyone time to write down all the reasons they think the project could fail. 10 minutes is a good starting point. One idea goes on each sticky note.

   Examples of concerns might be:

   • “We don’t talk with marketing and we need them.”

   • “We don’t talk with IT and we need them.”
     

3. Group by theme (yellow notes)
   After everyone has posted their blue notes, you group them into themes. If several notes are about missing conversations with IT and marketing, that might become a “communications” theme.

   

4. Discuss possible fixes
   For each theme, talk about how you could address the underlying problem.

   In the communications example, you might decide you need to:

   • Learn why IT or marketing seems to be “stonewalling.”

   • Schedule a session to explain your perspective and hear theirs.

5. Turn fixes into actions (green notes)
   Then you move into specific commitments.

   For the communications theme, you might write things like:

   • “We will set up regular meetings with the IT department.”

   • “We will set up regular meetings with the marketing department.”

   • “We will invite IT and marketing representatives to our planning or agile meetings so they can see potential roadblocks early.”
     

6. Fold actions into the project plan
   Finally, you take those green‑note actions and build them directly into your project plan. That way, the fears people had at the beginning are acknowledged and addressed through concrete steps, instead of remaining unspoken worries.

This process lets people voice fears they might otherwise be “afraid to voice.” Once those concerns are out in the open and you have agreed‑upon actions to mitigate them, the project can move forward with more alignment and fewer surprises.

From Awesome Product to Awesome Experience

Better experiences come from understanding users, making their journeys visible, exposing the behind‑the‑scenes process, and giving stakeholders a structured way to talk about failure and fix problems in advance.

Beth’s central theme is that shipping an “awesome product” is not enough.

You need to design and continuously refine the experience that surrounds it. Reducing friction where it doesn’t belong, adding it where it protects users, and involving the people around the project so their concerns can become part of the solution rather than quiet sources of risk.