Product Skills: How to Dispel Ambiguity
Every modern worker today has to take on ambiguous asks or needs and turn them into positive results.
As we’ve automated away a lot of the repetitive and straightforward work, we’re left with the problems we don’t know how to solve or even identify, e.g. our partner team needs to integrate their tooling with our feature; we’re not meeting a metric goal and we don’t know why; we need to decide which user audience we’re going after.
How do we figure out how to solve the problem? Here’s a path to work through the ambiguity and get to a clear plan.
1. What is the purpose of this project? How will I know whether I have solved the problem?
Start with the end. Ambiguous problems usually have undefined paths, so if we don’t know what we’re working towards, we won’t know if we’re getting closer to it. These are commonly broken down into the goal (what we’re trying to achieve) and the metrics (what we’ll measure to know whether we’ve achieved it).
2. Who is the audience? What actions or decisions will they take as a result of this project?
Understanding second-order consequences is critical to ensuring we’re actually solving the problem. Let’s say the project is complete and wildly successful: what has changed in the world and in what ways? Defining this deepens our understanding of the problem by creating some criteria and constraints for solving it.
3. What is the state of the world today? What would happen if we didn’t address the problem?
Outlining the pains today that the problem causes helps us understand its impact and urgency. This helps us decide how much to invest in a solution, fit the project in among the rest of our priorities, and convince others to help when needed.
4. What information do I need to know how to solve the problem? Who should I ask for input?
To decide on the most appropriate solution to the problem, or even brainstorm options for solutions, we will often run into known unknowns: what’s technically possible, who has previous experience with similar problems, what are common failure points, etc. Sharing context from the previous steps broadly with colleagues can help surface expertise to address the open questions and identify more that we didn’t think of (unknown unknowns).
5. How should we solve the problem?
Finally, we should have all the inputs we need at this point to define the path to solve the problem. There may be one clear solution or there may be numerous options we’ll need to weigh against each other. We pick the most promising one based on all the inputs we’ve gathered.
6. How will I evolve the solution as circumstances change? How will I know things have changed?
Only hindsight is 20/20, so at some point, we need to commit to a path. Once we’ve executed, we can usually adjust for the things we have gotten wrong. Even if we got it right, our audience and the state of the world will inevitably change eventually. To work effectively today, we need to build in feedback loops for our solutions. The criteria and constraints are key here, as these are likely the things that will change; if we’ve picked good metrics, we’ll know as soon as this has happened and can iterate quickly.
An example: Creating a new comms channel in the company
Let’s walk through turning an ambiguous ask into a clear execution plan. I’ve picked a non-product example to illustrate this can be applied broadly. You’re an Internal Comms professional, asked by your CEO to create a new comms channel for company-wide announcements.
- Step 1: You start by asking the CEO about the ask. You discover that she feels the company has gotten siloed across departments as it has grown and she is worried that the company is wasting resources reinventing the wheel across these. So the real goal of this project is to create more collaboration between departments. You decide to measure this by tracking whether the number of projects occurring across departments increases after the channel is launched.
- Step 2: Anyone will be able to consume this channel, but mid-level managers have the most context to impact the goal by identifying where a collaboration could help. This requires the manager to recognise that another department has expertise their own team needs and know who to connect with from it (criteria). That connection needs to have the time and motivation to offer help (constraints).
- Step 3: Today, the majority of cross-department collaboration comes through coincidence — managers who happen to ask for favours or department heads who are paying particular attention to their peers and happen to notice opportunities at the highest level. This means there’s a lot of unnecessary external consulting and agency hires and a lot of mistakes being repeated. We could even take a sample of projects and quantify what % of total budget was spent on outsourced expertise that could have been saved.
- Step 4: To address the ask, the posts on this channel will need to be written in a format useful to managers, so it’s important to include a few of them for brainstorming & early feedback. We’ll also need to a define a process for gathering the content that will go into the posts, so we’ll want to include Internal Comms folks within each department. We could benefit from talking to IT about our options for tools on which this channel will live, which will affect how many people will see it and what formats we can use for communicating.
- Step 5: After our brainstorm, we decide that a monthly company email spotlighting one department’s learnings over the previous quarter and upcoming projects will be most helpful to raising awareness among mid-level managers on the skills that each department contains, while creating minimal new overhead for department Comms teams. We choose several POCs from each department to act as network connectors for managers wanting to collaborate; they will also report back to us on new collaborations, so we can track our metric.
- Step 6: We’ll track open rates and include a feedback survey so employees can share ideas. We’ll do a semi-annual listening tour with our target audience, the mid-level managers, to understand how they’re using it and how we can evolve it as departments start to more regularly collaborate.
