Can product operations and innovation be friends?

Product innovation and operational frameworks have traditionally been perceived at odds with one another – one tries to go fast and messy while the other tries to create structure and order.  In my past product roles, I have been guilty of the former - any extra overhead, tooling and process seemed to just slow my team down.  We were constantly trying things, often with minimal research, to see what could gain traction and then accelerate - efficiency was not the most important KPI.

As I have moved into a consulting role, I have had a chance to work with mid-to-large size companies that are looking to maintain a culture of creativity, innovation and speed but not at the expense of siloed and unstructured work. They want product teams to be accountable, transparent and efficient in their pursuit of new customer and enterprise value. This goal relies entirely on the effective partnership between product operations and product innovation - what is the right structure for product teams to move quickly without breaking things?  The below outlines some lessons I have seen work:

Seasoned product managers know that innovative breakthroughs do not happen in a single release, but through iterative improvements centered on a big customer problem. The challenge that I see with many teams is that there isn’t the patience or framework to start small - they will spend many sprints to get a release out the door with very minimal validation - a huge and unnecessary risk.  This approach has high costs and limited success, often creating unused UI clutter and more technical debt.  

A recent client was struggling with this very issue, and I worked with their product operations team to introduce a different approach.  It started with identifying a problem or pain point which affects a large segment of customers. To create a solution to the problem, the teams formed a hypothesis that describes a situation which drives successful customer behavior. Product operations facilitated a way for product, design and engineering to come together around this problem and hypothesis, and design the lowest friction experiment which could validate the idea - here’s an example of what the teams ended with:

From here, the product team designed a lightweight test to email a segment of customers with a sample report and analysis. Additionally, they defined measurements of success – what must be true in order to devote more time to get this to full production. In this case, the teams were testing if: 1) the prospect schedules a meeting to learn more about the service, and 2) the prospect signs up to test the service. Goals were exceeded and the teams were able to move forward with strong confidence.  

If the team had listened to what clients were asking for, they would have built a feature that led drivers on their GPS to service stations where their car could be inspected - a far less reliable solution to the problem statement. This test served as a model for other product teams to follow and was a nice win for the product operations team to gain further trust and partnership across the product squads.

As rapid testing caught on, a new issue surfaced for the product operations team.  Teams were starting to test everything, identifying dozens of problem statements and hypotheses – there needed to be better focus and prioritization. As a next step, I guided the product operations team to bring team OKRs back into greater focus. Product team OKRs had been set at the beginning of the year, but were seldom brought into discussions and rarely updated. After closer review with the product operations team, we realized that many were not very meaningful.  Some had goals of releasing features, and researching new markets using AI - more of a to-do list instead of a set of goalposts. 

I coached the product operations team to use this as an opportunity to further strengthen the new energy around innovation through rapid testing.  We worked with the product leaders to refine their OKRs to be more focused and metric driven, and then re-published these to the teams.  The teams were now able to prioritize their tests more easily – if a hypothesis or test did not directly impact an OKR, it fell off the list. 

As one can imagine, this is a lot of change for a team to go through and it did change the nature of communication.  Sales was not getting the steady set of features they were used to.  Even if many of these features went unused, there was still the perception that the team wasn’t building enough and sales felt they had much less to talk about with clients.

We had started to see good habits and results stem from the product team’s rapid experimentation, but to ensure everyone appreciated the value, a modified way of communication had to be put in place. Once again, I worked with product operations and the product leaders to make sure experiments, releases, learnings and planning were accessible to everyone, while setting up the right forums to broadcast and showcase the work.  After some experimentation, we found the following to be most effective:

A nice side effect of standardizing these meetings was the actual…yes…reduction of meetings!  Now that OKRs and roadmaps were always updated and available, people didn’t need to schedule meetings to get an answer to a question — or if they did, they could just join the monthly broadcast meeting.  It wasn’t a silver bullet, but definitely eased the product managers’ schedules to some degree.

Every company has a different appetite for speed vs efficiency, but in all cases, product operations can help establish a foundation for product teams to go fast while ensuring the right levels of quality and thinking.  I have seen the best results when product operations team members are former product managers – they speak the same language and have the context and empathy for a successful partnership.  The right product operations team can be a partner for organized speed and remove overhead from the product managers, freeing up more time to design tests, speak to customers and drive their product forward.