Product Operations conversations unpacked...

This article is roughly based on a slack conversation between myself and Chris Compston, Product Operations Principal at Farfetch, where we explored various topics such as perception, communication and managing changes.

Our Product Ops team has a strong habit of continuously exchanging ideas while we work. Working together through opinions, experience and challenges. This article is based on only one of those conversations so that others can see what goes on into our team and how we face our challenges on a day-to-day basis.

You might notice a bit of a jump through various topics and concepts, but that’s how these organic conversations go. Between the four of us, there are various such conversations and we hope you enjoy this peek under the hood.

Perception is reality

Have you noticed the number of times that perceptions are so different from reality? Have you ever sat in a meeting and seen two people debating, only to realize they’re saying the same thing, but in different words?

In product teams, this can be exasperated to a whole new level, especially when we try to compare internal product development approaches to the often theoretical ideals of how we should work set out by such gurus as Marty Cagan, Melissa Perri, Gibson Biddle, Teresa Torres, and Bruce Mccarthy.

It’s almost natural to assume that those ideals seem so far away. As if every other product organization must be doing it better than we are. We aptly dubbed this as the “Grass is Greener” complex in our chats.

Even if we see an organization transforming its approach for the product team to be more product-led and outcome-driven, the perception on the ground may be that we’re moving further away from those ideals. And that is their reality, even if it's not a true reality.

We assume that all of this happens because the teams are in the messy middle. They’re in the thick of things and have to wade through the “thick mud”. Again, they also have no visibility of the real mess going on inside other product organizations and may automatically assume that the grass is greener on the other side.

Sadly, there aren’t enough talks or articles that discuss the challenge of obtaining those ideas. It’s not something that can be done in a few months, especially in large organizations. It’s a strategy to work towards and can’t always be a replica, because each organization does have its differences.

Some of the questions for us with all these thoughts running through our minds:

  • How may we help the team to have a clearer understanding of the final vision for the change?
  • How can we be sure the team received the final vision of that change and understood it?
  • How do we better support them through the change to avoid confusion and increase confidence?
  • How do we build up the team’s resilience to change?
  • How do we make it clearer that in truth we all want the same thing?
  • How do we help teams realize and get comfortable with the fact that these things take a long time to get right and may never be perfect?

Aligning everyone’s perception to reality is complex and we’re constantly challenging ourselves to find better ways to do that. The next topic touches on one of the reasons why it’s often difficult to align both.

Positive blindness

Imagine the scenario: a major change is presented to the organization, we go through months of ups and downs. Some things go well, while others do not so well. At the final stage of the change, we suddenly come face to face with the biggest challenge or blocker to the change, and confusion and mess ensue.

This is where the concept of positive blindness comes into play. Similar to the psychological term of serial position effect, which shows that people tend to remember the first and last things on a list of items, the concept of positive blindness is about being so bogged down in the mess and confusion that we become almost blind to anything positive that might have happened.

It’s something that we’ve seen in various orgs and teams, where a lot of the focus seems to continuously be on what went wrong, and we found that the one way to invert that impression is for a neutral team or party to come in and spotlight the good. A product ops team is an example of an internal team that could potentially have that role. In other cases, we may need to bring in a consultant or thought leader external to the organization.

This also explains why often it is so difficult to promote change internally to managers or stakeholders because they are blind to the positives the team is presenting. How frustrating is it when we see an external stakeholder or another team in the company present an idea similar to something we may have already presented, only to be met with awe and applause as if it’s life-changing and completely new to them?

As a Product Ops team, this brings up some things to keep in mind when we want to implement change:

  • Is my position neutral enough that I won’t fall into a blind spot?
  • How do we keep track of things without bias?
  • Is my position neutral enough that I can help people identify the positives?
  • Would it be a better strategy to bring in someone, whether they’re internal or external,  in a more neutral position to get your message across?
  • Is there a way I can provide a clear visual or update that spotlights the positives?

Again, we reach a point where we’ve diagnosed a symptom, but the treatment will vary depending on various factors such as maturity, discipline and stage of the process to name a few. Moving into the phase of change presents us with a whole new set of challenges and so being clear about when to act or react becomes important.

Knowing when to regroup

Implementing change, even the most well laid out plan, is packed with unknowns on whether adoption will go well or what the impact on the team will be. It can easily go wrong, or go in an unexpected direction.

Looking back after some time, it’s easy to see what went wrong or where we could have changed our approach, but during the process of change, it’s very difficult to recognize the problem and even harder, the best approach to adopt.

Another point to consider is the long-term vision of the change. Teams can easily get bogged down in the mess and lose sight of what they want to achieve. It can then become overwhelming and sometimes even seem as if we’re moving away from that vision. Interpretation of the vision can also change with time.

The big question we were struggling with in this conversation, rather than a retrospective of what went wrong, was how we might potentially avoid these issues in the future? How may we recognize that we need to change our approach in time? And how do we make sure that vision is always clear and empowering to the team?

During this long thread, an idea came to mind, and funny enough, it’s inspired by product development processes and an iterative approach to the change; with two potential impacts.

The idea is very simple, rather than setting just a long-term vision of the change, why not build it out with smaller objectives or milestone objectives instead? Potentially by quarters or half years.

What this would mean, would be that we set out a vision for the change we want to implement over the next 2-3 years. We accept that this may inspire the team at first, but could easily be perceived as a pipe dream as soon as things get messy.

The next step would be to present a smaller milestone for the first leg of the journey. Everyone works towards the goals established for that milestone. Reaching that milestone would have two objectives:

  1. We would be able to share with the team the objectives we were able to achieve and how that had an impact on both the product and our journey towards the vision of the change.
  2. We would also be able to analyze how that stage went, what we learnt and what might need to be approached in another way.

The baseline concept is that we can’t just hope that being transparent and sharing the change and its vision is enough to reduce discomfort in the team. We need to help them along the journey and provide them with small wins during the process.

Our questions or doubts still remaining:

  • Will having those milestones only create noise?
  • Will the team celebrate those milestones or focus on how the “vision” seems so far away?
  • Will it reduce the feeling that we’re going in the opposite direction because they have a roadmap of the change?
  • Would a better solution be to show the whole plan or vision? Or is it better to only share parts at a time?
  • How will we manage the discomfort if the exact vision isn’t achieved because we changed and iterated along the way?

Understanding that maybe our approach has to change, we then need to make some hard decisions on where to focus to create impact. We need to continually consider how much pressure needs to be applied and where.

When to talk and when to act

Imagine you want to implement a major change. With the best of intentions, you present the vision and objectives. You describe all the improvements and what impact they will have throughout this new process. Explaining how the team’s life will change for the better and how, because of it, we’ll be building a better product with a more coherent team.

You feel energized with the prospect, the team feels inspired as if we’re following the suggestion of product management gurus!

Everybody digs into the change process. The whole team is invested in the change when suddenly the first stumbling block is hit. We make some changes and get back on track until we hit another hurdle and another and then another.

With each hurdle we face and with each promise we need to go back on, skepticism and doubt in the team grows. We may ask them to have patience and to bear with us, but the truth is that the seed of doubt has already started to grow.

We may feel a drop in team morale and overall team health. But how do we decide the best course of action to change that downward spiral, especially if we know there may be more challenges coming up. We may find we can’t deliver on all the promises we made.

Thinking through this, we reasoned that there comes a time where we have to stop making promises or trying to tone down the negative things. We can’t send out more surveys asking people how they’re feeling or what they think needs improving. Chances are that at this point if we’ve accompanied the change well, we already know the answers to those questions.

At this time, we feel we need to go into action. We need to start showing that things can and will happen. We need to reduce the maybes and the potentials and start showing something more tangible to increase trust and confidence.

The big questions we have though:

  • What kind of action will create the impact?
  • What are the certainties that we know will happen?
  • How do we showcase the wins and amplify the good?
  • Do we have to change the narrative and how might we do that?

In conclusion

Enacting a change is easy, but managing that change is so much harder. Knowing when to stop, regroup or keep driving forward is important.

The vision and the ideas for change don’t always get well-translated hierarchical levels, causing uncertainty or discomfort.

As you can see, we go through a series of topics, but this is done in a much more synthesized way. I’ve unpacked each point a bit more in this article so that you, the reader, have as much context as we may have on the topic. Our real chats wouldn’t make half as much sense if I just shared them!

Many of these topics have already evolved to another level, while others have been saved for later until it makes more sense to explore them further.

In many cases, we’re just talking through these points to reach much more mature conclusions. Other times it’s about stating the obvious, but having these thoughts out in the open, helps us to work through them more effectively.

I hope you enjoyed the article and were able to follow along the often winding path of a Product Operations team’s conversation!

And finally... proving just how collaborative our team really is, this article was a truly collaborative effort with valuable inputs from both Bruno and Chris, which made the article even better.

Get Product Ops Certified👇