The Blind Spots I Didn't Know I Had

What assumptions have I quietly picked up along the way?

What have I been overlooking?

Every discipline has its blind spots. Product management has plenty, often running on ambiguity and fast decisions, and there's rarely time to stop and question the lens you're looking through. Over time, you get comfortable with what questions to ask, trade-offs to make. These habits, while useful, also create a way of not seeing.

Being at INTERSECTIONS Conference recently  gave me the opportunity to be challenged and the space to reevaluate my processes from a service design perspective. We weren’t solving different kinds of problems, just looking at them through different lenses.

Here are three reframes I came away with.

We optimise the product. Customers experience the service.

This is the question from ServiceSG CEO Sze Ling Lim that reframed the whole session. Why should citizens have to navigate government at all?

As product managers, much of our work happens inside the product. We discuss features, flows, usability and roadmaps. That's where we're expected to create value.

Customers don't experience our work that way.

For them, the product is only one part of a much bigger experience. The Instagram ad that first caught their attention. The onboarding email they almost ignored. The help article they searched at midnight. The support conversation they had after something went wrong. All of it blends into one experience.

Sze Ling Lim, CEO at ServiceSG shared an interesting story. Her team posed a simple question: If the government already knows someone qualifies for a support scheme, why should that person have to fill in another form to prove it.

With consent, the information already existed. The better solution wasn't to redesign the form. It was to remove the need for the form altogether.

The insight here was where her team chose to look for the problem. They weren’t asking how to make the form easier but why the form existed in the first place.

The product can be well built and still fail if the services around it don't hold up.

Before prioritising a feature, I want to consider what needs to happen outside the product for this to succeed.

What has to happen outside the product for it to actually create value?

Try this: Before/After Check

1. Map the Before. What are the 3 touchpoints users will hit before encountering this feature? 

   
   

2. Map the After. What are the 3 touchpoints users will hit after encountering this feature? 

   
   

3. Define. For each touch point, identify what needs to happen here for the user to successfully reach my feature?

   
   

4. Evaluate. Sit down with the relevant teams (Customer Support, Sales, Operations, Marketing) involved in these touch points. Understand the blockers for each

The goal here is not to create a full end-to-end service blueprint, but to get a clearer view of the dependencies that a pure product-only perspective misses.

We design one journey. Customers arrive from many different places.

Most products I've worked on have a single default path. One login sequence. One onboarding flow. One way to get started.

It's efficient to build and easy to measure. Any user who requires something different is an edge case to prioritise later. 

Aaron Maniam, fellow and director at Blavatnik School of Government at Oxford University, described customising how we engage with stakeholders as a metaphor: Some people wade, others paddle, or swim, or dive. Relating this back to the users I build for, a time-pressed user might only ever wade. When you design for only one of those depths, you've decided who the product is really for.

This idea has become even more relevant as our team at 55 Minutes spends more time designing accessible experiences. It is more than just making sure we support assistive technology. It’s recognising that people have varying limitations and that they think, process information, approach decisions differently. This way we’re able to give people a variety of  ways to reach the same outcome.

Who finds this journey effortless?

And just as importantly, who have I designed out?

Try this: Exclusion Check

1. Map your happy path. List the steps in your ideal user journey.

   
   

2. Add an assumptions column. For each step, write down what you’re assuming about the user: What does the user need to already know, understand, see, hear, remember or be able to do for this to feel easy?  

   
   

3. Surface the non-default user. Identify the user types that do not fit these assumptions. For example: someone accessing the product via mobile rather than a laptop, someone using assistive technology. 

Once there is clarity on who the non-default users are and the types of exclusion they face, you can prioritise and work towards solutions for them.

Customers experience the seam.

Harriet Wakelam, head of Group Design at DBS Bank, on how fast the seams multiply and especially so in the age of AI. So many possible connections, and each one is a place a customer can get lost.

An idea that Harriet Wakelam, head of Group Design at DBS Bank,spoke about was the seam. The in-between moments where one experience ends and another begins. 

To the organisation, these experiences could belong to different teams or systems. But to the customer, it’s just one journey.

Harriet pointed out that we often expect customers to bridge those experiences by themselves. We assume they’ll work out where to go next. Internally the transition may be very obvious to us, but for the customer these same boundaries don’t exist.

Harriet’s question stuck with many of us in the room: who actually owns the seam?

Most of the time, no one does. Each team owns their side. The seam itself belongs to nobody.

These are the gaps where users feel the most friction, and are also the moments I'm least likely to design for because they tend to slip through the cracks. Asking ourselves these earlier, before the journeys are built might surface problems long before they show up.

Where are the gaps I've never thought to design for?

Try this:  Test the Seams, Not Just the Flow

 
When planning your next usability test: 

1. Identify the transitions before writing your test script. Look at your journey and highlight areas where users transition (eg. product -> email, online flow -> in-person flow)

   
   

2. Add transition tasks to the test script. For each identified seam, design a task that forces the user to navigate that transition. Don't just ask them to complete a step, ask them to move across the gap.

   
   

3. Watch for the cracks. Pay attention to the moments between steps. Record signals of confusion, hesitation or uncertainty. These often signal a broken seam.

   
   

We can’t eliminate every seam. But this process helps us find the ones that are actively breaking the experience and prioritise what to fix.