What can we do about those torturous weekly readouts of digital KPIs and priorities?

This guest post is part of our Continuous Product Design (CPD) Evangelist series.

In this post, Karl Goodhew, Director of Software Engineering at Macy’s, shares why he thinks it’s so hard to get alignment across leaders in product, engineering, customer service, QA, etc.—and what we can do about it.

The Monday morning 8 am call we all know and…

How many of us have been here? A Monday morning 8 am call to discuss last week’s business results. They’re bad. Really bad.

The round robin starts with an overview of results and how every category is down year over year.

Customer service discusses last week’s ramp up of calls on site issues with no resolution.

The product team doesn’t have answers – but they’ll research and “circle back.”

Engineering acknowledges the Monday release didn’t go smoothly, but they backed it out on Wednesday, and patched it on Thursday.

QA will run through all p1 scenarios again first thing today to validate flows.

The consensus is that there are macro-economic issues, but everyone should research their areas and report back on a plan.

The torture of the weekly read out of siloed digital KPIs and priorities

Why do we torture ourselves with this weekly read out? We end up with a list of action items and research points that will no-doubt fix some issues but not the fundamentals?

Because that’s how we’ve been trained.

We work in teams. Each team has its own goals and KPIs. Each team has its own backlog, bugs, and priorities.

It doesn’t have to be that way

How should this scenario ideally play out?

Well, there shouldn’t be a need for a weekly lookback if teams are 100% aware of KPIs at any given moment.

That monthly release could have been a daily or weekly release with fewer touchpoints.

A single pane of glass view, with data transparency, identifies issues as soon as they occur. The bugs become less business-impacting.

QA automation gets releases out the door sooner. Even without, smaller releases with targeted changes reduce risk. Negative changes can quickly be identified, prioritized, and resolved.

Why do we argue about what caused last week’s sales dips and what to do about it?

First, it’s accountability. No one wants to accept blame for 100% of the problem – because it’s not 100% their fault.

Maybe accountability becomes easier if it can be quantified in dollars and cents with some level of certainty?

Perhaps that loyalty release escalated by a board member – shifting all dev resources in the process – is actually not as painful to the bottom line as a hidden bug in the checkout flow, that prevented 100s of customers from entering their credit card numbers.

Second, it’s prioritization. Is the CEO’s mandate to fix the loyalty bug more important than the checkout bug? If the CEO knew about the checkout bug, would more resources be made available to automate QA?

So many questions would be answered better if the issues, risks, and dependencies were known up front.

More tools, more data, more problems

I believe most companies have solved some of these quandaries by giving their teams tools to find problems and solve major issues. CSAT feedback, analytics tools, application performance monitoring (APM), real user monitoring (RUM), or even session replay. But these are siloed tools that require someone to gather teams in a room to let them know there’s an issue.

Development and Operations – or DevOps, potentially – works to find technical issues but might not always include the product team. Nor might they understand the impact of the issue in dollars and cents.

Customer satisfaction might hear about a bug and raise it up, but not know that the business impact is minimal.

In other words, there are many sources of truth. To the DevOps team, their truth is real and impacting. To the CEO, her truth is real and painful.

To use a car metaphor (I love F1 btw as it’s a great analogy to business): Everyone has a sensor and is adjusting the entire car to make that single sensor green. But this potentially impacts other areas that they hadn’t even considered.

We need a single pane of truth and a single set of priorities

Teams need to work from a single pane of truth. They need a single set of priorities that are driven by KPIs with the ability to learn, course-correct, and iterate with an acceptable level of risk and a safety net (in the way of alerting, quick reaction, and operational readiness).

This single pane of truth has to capture and output real-time behavioral and technical input. It needs to integrate with all the tools that are already in the team’s toolkit, and it needs to be able to scale with the business.

How we can (mostly) eliminate those torturous weekly readouts

This is a people, process, and technology solve.

First, our leaders have to change their mindset and not jump on the first problem that they hear about. But listen to the most important problems in order of dollars and cents impact. They may not be as shiny.

Second, we need to adopt a process of Continuous Product Design where the feedback loop is continuous across all teams. And all teams are aligned on where improvements should be made.

When we have a single pane of glass with a prioritization scheme we all agree on, teams can deep-dive, solve, and deliver faster.