Key Takeaways
- As tech professionals engage in product discussions, clarify abstract terms, and adopt an "attitude of not-knowing" they enrich the clarity of requirements and enhance team communication by promoting a culture of inquiry, reducing misunderstandings, and building common understanding.
- Align your product and tech conversations with users’ future preferences and needs - not just their current problems. For each task, ask yourself if the solution tackles the user’s needs and provides value.
- Using nuanced, solution-focused language and tools, such as the Dialogic Orientation Quadrant (DOQ), can make product and tech conversations in the team and externally with users more outcome-oriented.
- Most of the time, your assumptions about the company, users, and stakeholders shape how you perceive them and guide your approach to conversations with them. Be genuinely curious to accurately identify the needs.
- Consider resistance as "needs in disguise" and recognize it as an opportunity for deeper understanding, leading to more productive interactions throughout the whole team, benefiting the product.
Navigating the world of product development is not only about developing, mastering techniques and methods, and filling out templates - it’s also about the art of effective communication and interpersonal relationships. Everyone - business and tech people - can benefit from product leadership. You’re building a product for users and customers - so even though there’s often an official "product owner" or "product manager," tech people can show product leadership, look through the user’s glasses when discussing requirements or tech solutions, and shift team conversations when they seem to be unproductive.
In my experience, having tech people who identify with the product, challenge the requirements and circle their conversations around the users increases the overall team performance and productiveness of interactions. I’ve also seen developers eager to join any kind of user interviews. (In this article, I refer to business- and tech-oriented roles as "product leaders." The tools and methods they use work within the team, with other departments, with users, and with any other interaction between people.)
In this article, you will discover how and which parts of coaching and nuanced language can help you leverage your interactions to yield better results. Integrating specific coaching principles can enhance the quality of your conversations by guiding dialogue to uncover actionable insights, foster trust, boost collaboration, and drive clarity in your objectives. You will uncover tools and strategies that can significantly impact how you approach product development and team and stakeholder engagement.
Challenges product leaders face
Much of my role as a product leader centers around communication. This involves liaising internally with the (Scrum) team, management, and various departments such as marketing, support, or operations. Externally, I engage extensively with customers and users. The primary challenges stem from obtaining accurate information, involving the appropriate stakeholders, dealing with passionate users, identifying precise needs, and ensuring that everyone comprehends the context and goals we try to achieve.
It’s not uncommon for stakeholders and users to discuss the same topic but employ different terminologies. Therefore, deciphering the fundamental needs behind their verbalized solutions is essential. This ensures that as product leaders, we cultivate the right solutions with our teams and avoid the pitfall of users later stating, "That’s not what I meant."
I’ve observed many product leaders, myself included, halting during user interviews and stakeholder discussions as soon as their conversation partners describe what they don’t want. This is commonly known as the problem - typically brought to light when asking "Why?"
While it’s crucial for product leaders to understand user issues, our products can reach greater heights when we continue asking questions that reveal our target group’s underlying needs and desired outcomes. The question "What for?" offers a clearer view of our users’ goals. This allows us to tailor the product to meet their needs and expectations more effectively rather than just understanding their problem.
Let’s start with a rudimentary example before I give you a real-world client example.
Consider the desire to drink coffee. "What for?" might encompass:
- You want to quench your thirst
- You want the caffeine to help you wake up
- You want to develop a morning routine, and this is part of it
Depending on the client’s preferred future or need, you can develop different solutions that help them achieve this. One might opt for a swim, a glass of water, or perhaps some green tea or matcha. This analogy similarly applies to technical solutions in the world of product management.
Here’s a simplified client illustration: users expressed dissatisfaction with constant news notifications from a specific part of the application.
The team’s response was to eliminate the notification center of the tool. However, user discontent persisted. The team overly fixated on the explicit problem relayed by the user without delving into the underlying needs. The users’ actual need (their preferred future) was greater control over the notifications, desiring designated quiet periods of specific parts in the app. This could have been addressed with a notification scheduler, allowing users to designate when to receive or mute notifications. After reflecting on the client’s feedback, the team honed in on the phrase notification all the time, which was an invitation to explore what exactly the client meant by all the time.
The team’s misdirection was primarily due to the mindset, "We are the ones deciding what solution we implement. Users tell us their problems." I only partly agree with this. Users tell us their context and topics, and we need to find out their preferred future (in the client’s case, it was more control over quiet times). Based on that, we can define different technical solutions to test with our target group.
The key success factor for me is clear and helpful communication from every angle. While picking up classic product management methods like User Stories or Roadmapping is straightforward, the tricky part is filling in the methods’ blanks. This calls for solid communication and leadership skills - and solution-focus with all its facets helps a lot. While product leaders aren’t coaches - we do have coaching-like conversations to understand what users actually want, which saves a lot of time and money, even in the short term. And before you think, "Isn’t everybody solution-focused?" give me a chance to explain what solution-focus is and how it’s different from solution-orientation.
The meaning of solution-focus and benefits for product leaders
Suppose you modernized a software product and you are now in a user interview with a passionate customer who is angry because in the previous version of the product, he had a feature that doesn’t exist in the new one.
User: Are you out of your mind to remove this feature? This is typical for your company, destroying the best features. Just LEAVE THE PRODUCT AS IT IS and STOP. Everything was better before, and you keep on making the product worse.
Before you read further, I invite you to think about how you would tackle this challenging situation. How would you proceed in the conversation with the user?
As product leaders, we could go into a defensive mode or get vehement ourselves and talk bad about the user. However, look at this example from a different perspective. You probably will realize that this user is super enthusiastic about the product and wants to help make it better; why else would they take the time for the interview? The user said four words that can turn the conversation: "Everything was better before." You might miss those words if you do not actively listen to the conversation or read messages thoroughly.
What is solution-focus, and how does it help us?
Let me show you a picture of Haesun Moon’s Dialogic Orientation Quadrant (DOQ) to explain what solution-focus means to me briefly.
When we are conversing, we can talk about topics or ask questions in several ways. Solution focus happens in the Resourceful Past and Preferred Future Quadrant. Problem focus occurs in the Troubled Past and the Dreaded Future quadrants.
Let’s explore potential questions of the software modernization example based on the DOQ together. What would be the answers to the following questions if you put on the user’s glasses?
- Troubled Past: Why is it worse than before? What makes you angry?
- Dreaded Future: What would make it even worse?
The answers to the questions from the bottom quadrants are probably not very helpful. They often intensify the anger, and seldom help get to the user’s needs. Language that fits into the bottom quadrants is often referred to as "away from" language because it gives answers about a state that individuals want to escape, rather than a desired outcome they want to move toward. This kind of communication can end up in a negative loop, preventing meaningful progress and solutions.
Now, let’s explore the upper two quadrants.
- Resourceful Past: You say everything was better before. When was it better? What was different then?
- Preferred Future: What needs to happen for it to become better again?
What differences do you notice in the questions and potential answers? They seem to be more helpful, right? We also refer to language that fits into these two quadrants as "toward to" language because it gives helpful hints about the preferred future and state.
Quick tip: If you find that in user interviews or conversations, people (or even yourself) are in the problem-focused quadrant, ask, "What do you want instead?" to make steps into the preferred future.
Consider it as appreciation - "Thank you for openly sharing your thoughts with me. You seem to be very passionate about the product," and chances are high that magic happens.
By the way, you can use this with any conversation. In meetings with teams, instead of over-analyzing complex problems, it has consistently been useful to aim for the upper two quadrants. The benefits are that you get to desired solutions faster, people feel appreciated, you reduce the number of meetings, you feel better yourself because you see emotions through different lenses, and many more!
I invite you to listen carefully and be interested whenever you are in a conversation. For me, the DOQ and solution focus brought a whole new perspective on active listening skills; I can tell you it has fundamentally changed how I talk and listen.
Distinguishing solution-oriented from a solution-focused approach
At first glance, both terms include the word "solution." My perspective is that being solution-oriented is the general tendency to seek solutions instead of merely discussing problems. In contrast, solution-focused encompasses an entire mindset, many tangible techniques, attitudes, and guiding principles. These support you (and your users and stakeholders) in defining, focusing, and working toward a preferred future. The DOQ mentioned above explains what it is about at the core.
An important side note: I’ve occasionally heard solution-focused practitioners called "problem-phobic." Within the solution-focused realm, we indeed acknowledge and value the problems presented to us. However, we emphasize the desired future rather than delving into the root cause of complex problems. The latter often proves to be time-consuming, conflict-inducing, and, in intricate scenarios, nearly impossible due to the lack of a straightforward cause-and-effect link. As an example, if you asked a team, "Why aren’t you working together?", you would probably get different answers, and blaming those will not be very helpful in improving the situation.
Furthermore, solution-focus comes with a comprehensive set of attitudes and principles. Some might seem cheesy at a glance, but essentially, they demand continuous learning to be practiced effectively. Let’s delve into some of the attitudes and principles and how I have adapted them for product management.
If something works, do more of it
I use this principle in the same way as the Build-Measure-Learn Cycle in Eric Ries‘ book Lean Startup. It’s all about learning from our assumptions and the functionalities we build. However, it’s also about how we collaborate. Is there a certain collaboration way that works better than others? When did the collaboration with the developers improve? What did you or they do differently? What do users appreciate most in our development process?
The attitude of not knowing
This is probably one of the hardest attitudes to master. It’s all about staying curious, leaving our interpretations out of conversations, and working with assumptions in product development.
Consider the phrase "I work out sometimes" as a simple example. The word "sometimes" can mean different intervals - I have verified this at conferences I have spoken at. Some say it’s once a week; some say it’s three times a week, and one person said it’s once a year. The words "work out" can mean different things as well.
As product leaders, we need to ensure that we understand the communication world of our interaction partners. We need to make sure that we clarify expensive words that could cost us a lot of development effort. "Expensive," in this case, can be interpreted in many ways. I know this concept from Mark McKergow. Examples of expensive words or needs can be flexibility, responsiveness, customization, efficiency, speed, control, security, etc. When you hear expensive words, my advice is always to ask, "What kind of [expensive need] is that [expensive need]?" (Clean Language Question by Judy Rees). To gather data that shows you and them signs of progress toward that need (or preferred future), you can ask, "How would you notice that you have this [expensive need]?"
Users are experts in their context
This one is a major step toward reducing waste and creating a user-centric product. It’s all about acknowledging users as experts in their context. The users truly know best how a product fits into their daily lives. Here it’s not about the technical solution in the first place. It’s about focusing on the user‘s needs and the value of their feedback, user interviews, and user testing rather than the needs we think the user has and building upon that. You and your product team are experts in technical solutions for a broader audience, UI/UX, product management conversation techniques, etc. The experts for their needs are the users. Use that to the advantage of the product!
Living these attitudes and principles can take some time, and that’s fine. Start small. They help us build better products, have more helpful conversations, and deal better with difficult situations.
There is no resistance
One common difficult situation for product leaders is resistance - from developers, managers, stakeholders and from users. The problem with resistance is that we often get sensitive about it or feel somehow attacked, which is not very helpful for the conversation, for the product, or the interacting people. Steve de Shazer (one of the founders of solution-focus) points out in his article Resistance revisited to "Einstein’s idea that your theory determines what you see." Simply, this means that what we already believe can change how we see resistance.
I encourage you to reframe your understanding of resistance. Think about resistance as needs in disguise. In the long run, it can help you channel your frustration into curiosity and find out what your interaction partners need. Recognizing and addressing these needs can have a significant positive impact on your product.
Working with stakeholder assumptions
To build upon Einstein’s words, I would like to introduce you to the concept of stakeholder assumptions.
Whenever you interact with stakeholders or users, the conversation is different based on your assumptions about them.
Let’s assume you think all your stakeholders are political and ego-centric. Chances are high that you will perceive parts of the conversations as political and ego-centric. You will probably hear many phrases that confirm your thinking—also called confirmation bias. This is probably not very helpful.
Instead, you could find assumptions that lead to a better collaboration like:
- Each stakeholder and colleague wants what’s best for the product
- I am confident that we will come up with a solution together today
These two assumptions help me a lot and make a significant difference in my collaboration with others. I often get excellent feedback on conversations I lead with people, and most of it comes from being solution-focused and having optimistic, helpful assumptions. You can find your assumptions or choose mine - it’s up to you!
Your development toward solution-focus
For me, the solution-focused approach has led to asking even more concrete questions and developing a helpful attitude for conversations. Generally, I would say I’ve always been an open person with a positive attitude - however, I listen differently, and hear helpful phrases and words more frequently now. Especially in my role as a product leader, I focus much more on the user’s needs and help them better understand what they want. Overall, collaboration with people has become much smoother.
If you want to get into solution-focus as well, it’s all about practice, practice, practice. Integrating the attitudes and principles into your daily life takes time and mental investment. Solution-focus is easy to learn but hard to master.
Take your time and start with a small step. Perhaps each month you could practice one principle. You could say that in one of your meetings, you particularly want to practice "the attitude of not-knowing." Afterward, ask yourself what difference this attitude made for you.
Ultimately, I believe that it’s all about lifelong learning. There will be situations where you will succeed and others where you will fall short. I encourage you to focus on the successes and analyze what difference those made to you and your environment.
Regarding book recommendations for solution-focus, it’s worth noting that most of them cater to coaches. Although we, as product leaders, aren’t coaches, we often have coaching-like conversations. Extract what’s helpful to you and leave behind what’s not.
- The Solution Focus by Mark McKergow and Paul Jackson
- Brief Coaching Library from solutionsurfers, free resources
- German: Faszination Lösungsfokus: Wie du mit gezieltem Blick die gewünschte Zukunft gestaltest by Elfie J. Czerny, Dominik Godat et al
- German: Coaching - erfrischend einfach: Einführung ins lösungsorientierte Kurzzeitcoaching by Daniel Meier and Peter Szabo
Product management is a hard job, challenging product leaders on many levels. I invite you to experiment with parts of the article that resonate with you. Try it out and see what benefits it brings to your daily activity.