Making Space for Curiosity
Orgs trying to shift to customer-centricity (or product mindsets or Agile) always run into the same non-starter issue: a lack of “time” to actually understand customers and their problems. But in my experience time isn’t the real blocker. What’s lacking is a tolerance for curiosity.
Most businesses believe they run on answers, not questions. They measure performance based on deliverables, not conversations. In this type of environment, when a middle manager is used to assumptions, questions feel like attacks. When a program manager is used to durations, open-ended studies feel like failure. I’ve even been in environments where engineers didn’t want to be seen at a whiteboard for fear it would look like they weren’t working! No educational initiative or executive speeches alone will change the habits built from a culture of assumption.
There’s a common UX-based refrain that says “fall in love with the problem, not the solution”. It’s a rallying cry to snap teams out of their myopic focus on shipping features and understand the real business innovation opportunity. I’m confident this is a more successful approach that betters both the customer and the business, but orgs simply aren’t used to working this way. People in the business don’t have the capacity to step back and learn. They have delivery deadlines. If we want people with solution mindsets to adopt learning habits, we have to listen to ourselves and love the problem: we have to first create safety for curiosity.
Making Space for Curiosity
When a project timeline is ticking, it’s too late for exploration; no one feels comfortable with an activity that doesn’t feel like shipping a product. We must start discovery work much earlier in the process when the ideas and business cases are being formed. I’ve had far more success getting people to explore questions and validate requirements before there’s an approved project plan. It can be difficult to get involved early because unknowns look like knowns (“we don’t need research”) or because UX deliverables come later in the process (a problematic subject for another time). How do we get there earlier? If you are on the business side, you do this by engaging UX and research earlier than you think you need. If you are in UX or research, you do this by building and maintaining relationships with counterparts in product, category, engineering, development, etc. so they can help advocate for early discovery.
Another approach to creating space is to sell leadership on the idea of a different type of project or way of working. When the obstacle is the existing project plan template (often waterfall), prototyping a new type of project can allow discovery-without-solution to be viewed as producing. When middle managers are following the trial approach knowing it won’t change everything they are doing for all projects, they feel much better signing off on resource allocation…and the teammates can feel empowered to be curious.
Maintaining Curiosity
Doing a design sprint or customer study will get a trial run at curiosity, but these are so often one-off larks that exist too far out of the regular work stream. Maintaining space for curiosity requires a promise of actionable insight, else why invest? When pitching to get involved earlier in the process, I’ve found success tying the outcomes to stakeholder benefits: stronger customer cases to aid project approval, better details for building requirements, or clearer understanding by the product team so they can move faster in development. I like to start with a time box approach: we’ll use _____ days/weeks and hand over actionable intel. My mantra for research teams has always been “Insights into Action” because it keeps the focus on impact, which helps guarantee we get asked to work on more projects.
Intentionally Breaking Bad Habits
If curiosity doesn’t fit with the enterprise habits in some way, it gets rejected. All of our efforts to switch people into learning mindsets are really exercises in change management, and it behooves us to understand and leverage habit loops. As Charles Duhigg illustrates in The Power of Habit, we have more success moving one aspect of the habit (trigger, routine, reward) than asking people to change all at once. When I described creating space, I was talking about triggers (getting invited early in the process) or routine (new project type). In maintaining curiosity, my examples focused on reward. Institutional habits can be some of the most difficult to break and are often what cause change initiatives to fail even when mandated. Paying attention to the habit loop helps us chip away at change.
In solution-oriented environments curiosity is threatening. To create safety, the solution often lies in “hacking” existing directives to work for unknown domains. That can be direction from leadership to work in a different way for certain projects or trial efforts that diverge briefly from the existing project patterns. It can feel like theater at first since we aren’t doing research or UX in its “pure” form; but in the process of doing even a little discovery, everyone still learns and sees the value added to their daily work. They will want these benefits again and will ask you to do more in the future, earlier. That’s how habits start to change.