Over the last few months, I’ve been reflecting on how I’ve had the chance to work with teams with different realities/product maturity. For one, the product is more mature i.e. it has been around longer. For others, it’s a fresh slate. The latter requires me to change context multiple times before I even grab my lunch for the day. As someone who loves ambiguity, that’s my forte. However, I have a strong opinion that the purpose of ambiguity is to bring clarity/structure. Ambiguity is good for a start but it stinks when it remains for far too long.

Where it started

My embrace of the unknown isn’t a new thing. It’s a character I’ve displayed throughout my life (like anything, I believe it’s learnable for anyone). For example, back in the university, I consistently choose the most ambiguous, theoretical, and challenging courses whenever I have the chance. I ensured I took every mathematical programming, econometrics, and macroeconomics course I could get my hands on.

It didn’t stop there, several times, I tried to distill my reality into economic models and I often wonder how my models can become more practical. This was how I got into the technology space. Thanks to computer programming, I’ve come to see how a nation’s economy can be programmed into a game e.g. Old School RuneScape, Asheron’s Call. Commerce has been distilled into the likes of Shopify. And finance now lives on Bench. That brings us to the purpose of ambiguity. Structure.

The purpose of ambiguity is to bring structure

As product people, we join teams with so much ambiguity. No primary metrics. No product principles. No process to product discovery and development. Everything is everywhere. Everyone does everything. Things slip through the wall and we begin to step on each other’s toes. No one wants that!

How can you turn ambiguity into structure

  1. It starts with your triad

I’ll scope this to a squad level, not a departmental. Within your triad, be clear on responsibilities and who does what. This helps us avoid the problem of everyone doing everything and stepping on other people’s toes. An exercise I’ll recommend is the Triad Responsibility Exercise.

traid responsibility exercise

Attempt this exercise as a team and have the hard conversations early on. There are two categories of responsibilities for a triad team, sole and shared responsibilities. At the end of the exercise, let everyone know their sole responsibilities. You must have difficult conversations on the shared responsibilities as well. Having this clarity helps each member of the triad avoid assumptions on who does what. That way, things don’t slip through the wall. You might want to revisit this task on an annual basis or when you have new team members.

  1. Be aligned with the company’s cadence (Plan top-down)

Everything in a company happens in a given cadence. The period of each cadence differs. The higher up the cadence, the longer the duration. If you don’t have one, start that conversation and start creating them within your area of responsibility or influence.

company cadence

Having this cadence helps you achieve at least three things:

  • Put a structure to your daily activities.
  • Ensure that the work you’re doing has meaning. This reinforces the psychological safety of your team. The fear that your work or team could be axed because it’s providing no impact to the business and users is tapered.
  • Align your work to the company’s mission.

You can employ frameworks like OKRs, SMART Goals to help us align your team’s work to the company’s cadence. Within this would be your key metrics.

  1. Define your team ceremonies and team norms

A product manager without a team is nothing. If you have an agile coach, you’re lucky. I’ve found them invaluable in this aspect. I’m not an expert in this area but I’ve discovered that defining the team norms and ceremonies (stand up, grooming, sprint planning, retrospective, and demo meetings) is one more thing that helps you bring structure to ambiguity to your work.