As a product manager, an important part of your role is interacting with other people to achieve common goals, be that senior leaders, stakeholders or your team. To enable you to achieve great things together, you need to be able to align around a common purpose and overcome any challenges that arise as you progress towards that vision. This is where coaching comes in.
Coaching skills are valuable for product managers, as they open up creative problem-solving and lead to a commitment to make necessary changes. A common coaching model used is GROW, which works by asking open questions* to explore each aspect of the model:
- Goal
- Reality
- Options
- Way forward (or Will)
* A quick note on open questions: these start with ‘what’, ‘how’, ‘where’, ‘when’ and ‘who’, and result in a variety of answers, not just yes/no. Be wary of asking ‘why’ as that can appear judgemental and close down the conversation.
Let’s take a look at four coaching questions that every product manager should be asking.
What are we trying to achieve here?
Defining a goal is about understanding the outcomes you are trying to achieve. Too often when a problem is presented, we jump straight to brainstorming potential solutions, without first getting a solid understanding of the objective.
Consider this scenario: an engineer comes to you to say they have got stuck with an investigation into a supplier’s API. Going straight into solutions, you might come up with options like reading documentation, asking another engineer to take a look at it, reaching out to the supplier’s support team, and so on. However, if you were to ask ‘what are we trying to achieve here?’ the options might look different. Say the answer is ‘I’m trying to understand how we could fetch this data for the MVP’, you could consider using alternative data exchange methods that avoid an API integration altogether, or even use mock data to first prove the concept.
Get clarity on the shared goal first, as that impacts the approach you ultimately take.
Where are we at right now?
It’s tempting to also skip over reality when looking at solutions, but it’s important to take note of what has been tried so far to take the learnings into account – and appreciate how far you have already come.
Continuing with the previous scenario, the engineer responds to this question by outlining they have spent a whole day trying to figure out how to integrate the API with little success. The sunk cost fallacy applies here: you cannot get that time back, so what are you going to do differently now? Together you can explore what has worked, what hasn’t worked, and come back to the goal to assess if you need to try a different approach.
Making an honest assessment of the situation enables you to move into exploring options that might actually work.
What are the options available?
When coaching somebody on the options you want to ensure that you explore everything – nothing is off the table, there are no silly suggestions. This stage is about going broad, using divergent thinking to generate as many possibilities as you can. This is a great exercise for a whiteboard session – in person or remote. If you get stuck, you can also loop other people into the discussion (after first bringing them up to speed on the goal and the reality!)
Sometimes people get stuck here, so you may need to gently encourage them to open their minds. For instance, our example engineer might say, ‘I’ve tried x, y, z – and nothing’s worked.’ When this happens, come back to the goal or use prompts such as ‘what would this look like when the product is live?’ By asking people to envision the future that can enable them to work backwards to the now and generate more suggestions.
Be super clear on what options are available and how those relate to the goal, before moving onto the next stage which narrows them down again.
How do we take this forward?
Some options are going to be more feasible, viable and valuable than others, so at this point you want to strike out any that don’t meet your requirements. Ideally, pick one that everybody agrees is an appropriate next step and define the timelines and support required to achieve that. It’s important that the person who will do the task has the will to take it forward, so if there’s any hesitation you may need to spend some time understanding and addressing the objections by revisiting reality and options.
In our example scenario, if you and your engineer have narrowed it down to a few options but there is a disagreement about which one to progress first, come back to the goal. From this you can assess which option is likely to give you a positive outcome in the shortest amount of time. If, for instance, your engineer suggests using a secure file transfer server to exchange data with the supplier, you can validate if that would take less time to implement than continuing with the API integration. You can also consider other aspects and risks, like data security, robustness and scalability beyond MVP.
Once you have a commitment to move forwards, you have completed the coaching model. At this stage, you can agree another checkpoint, and if insufficient progress has been made then you can revisit the scenario using GROW again.
Wrapping up
At first, it may feel clunky and unfamiliar to be asking these questions, but with practice, you will become more confident and fluent in their use. In addition, our example uses an engineer as our ‘coachee’, but this model also works with others including senior stakeholders. In fact, it’s a great approach to adopt to ‘manage upwards’ when you need to clarify or manage expectations – I’ve used it many times in Product Reviews when suggestions have been put forward by senior leaders, just to validate that we’re on the same page about what’s important. Using GROW makes explicit the implicit assumptions held by others, and gives you a model to work through together towards achieving the outcomes you both desire. Give it a go and see how it works for you.
Discover more content on product management
- Humility and personal resilience in product – MTP Engage Hamburg 2022
- Career clinic for product managers by John Cutler
- Don’t do free work in your next interview
Comments 0