Upgrading an Existing Editor in an OKR-based Strategic Environment: Product Management Case Study

Executive Summary/TL;DR

In spite of the drawbacks of an OKR-based strategic environment, the team and I managed to complete an important project within one quarter’s time that had typically been left behind — for far too long.

Introduction

Disclaimer: For the sake of confidentiality and anonymity, all details contained in this case study (especially PII such as names, addresses etc.) are fictitious and don’t contain any details about the respective client. If you’d like to learn more, reach out to me directly.

This case considers my work on a web application which main use was to allow users to create and update their own records, consisting of different sections, or modules.

Overall, data quality was of paramount concern, i.e. having as much current, relevant and high-quality information as possible.

Problem Statement

Initial Assessment

During planning for the impending quarter, my first scan of the backlog revealed a larger item – overhauling an entire module’s data display and entry for names, time periods, location information, and freeform data (such as comments and annotations).

After inquiring with multiple tenured coworkers, I learned the following:

This was a re-write project. These are usually dangerous, as they can turn into bottomless pits of scope creep, and end up costing an incredible lot of resources, while not delivering sufficient value to balance the scales.
This had already been attempted, and stopped again. Twice. For good reason? Or had it just not been approached properly? I was yet to find out.
Work had already been done on it — however the remaining work burden (estimate) and viability of existing code was unclear.

Accordingly, the involved team was rather apprehensive about engaging this topic — especially since stopping work on a topic is easily perceived as a failure, which obviously is a strong demotivator.

However, upper management was highly keen on getting this done. So there must’ve been motivators that I yet had to uncover.

What I was already able to learn was that this problem was threefold:

What was the origin issue, i.e. why was this initiative set up in the first place?
What was the reason for this previously having been started but not finished?
Finally, what was the reason why this wasn’t re-attempted (after not being finished twice)?

The Origin Issue

By speaking to Product and Engineering leadership, I was able to establish the original motivation for this rewrite was a broader technological upgrade from the Engineering side (as it frequently is the case).

From the Product perspective, this would yield one key improvement:

Previously, updating a record required two clicks — first, entering the edit mode (from view mode), and secondly, opening a modal for the specific data item/section to be updated.

Hope this helps to retrace the concept. “Design” is my own, all emojis designed by OpenMoji — the open-source emoji and icon project. License: CC BY-SA 4.0

With the change, only one click would be required, as editing would be directly possible from view mode.

“Design” is my own, all emojis designed by OpenMoji — the open-source emoji and icon project. License: CC BY-SA 4.0

Just one click?

Well — as data quality (and freshness) was the most important KPI for this product, removing friction by enabling updates with less clicks was a fairly obvious target for a project initiative.

Half-Baked

Further conversations with involved team members revealed the answer to my second question. The short answer was:

It was too big.

The entirety of the project was quite a bit of work, and every time it was scoped for a quarter, the team would — especially with other topics fighting for priority — end up dropping it in favor of something more urgent or feasible.

Indeed, previous planning would aim to incorporate the entire technical re-write and the product-facing feature changes into one big work packet.

Was this feasible within three months? By default, sure.

Was this feasible within 3 months while doing 4 other important things? Rather not.

Left Behind

To find out why this hadn’t been picked back up again, I had to connect the dots:

Observing the OKR process, I noticed a risk that planning for quarterly cycles inherently bears:

If a team finishes a project within 3 months, it’s a success. Great planning, great execution, yay!
If a team doesn’t finish a project within 3 months, it’s…well, maybe not a full-blown failure, but a miss, and a lesson.

Obviously, as a team, you’ll want to pick a manageable-size project, or a few smaller projects, because you can win at them, and steer clear of the large stuff, because you’re set up to miss the mark on those.

That’s a good thing. Right?

Overall, sure. However, some things are just a bit bigger and complicated, and can’t be fully accomplished within 3 months — but just not doing them isn’t a solution.

Slicing

Now, you might be thinking — “maybe the planned iteration was too big, so it needs to be broken down further?” — and if you are, yes, that’s exactly what you should do, correct answer!

But — why hadn’t anyone thought of that earlier?

Of course, I wasn’t the first one in the organization to understand the concept of slicing & iterating quickly.

I was only able to deduce that because of the interdependence of the re-writing goal and the feature goal, their values had become conflated — to the problematic extent that the two elements’ distinct values seemed ‘not worth it on their own’.

And everyone in the organization had become so used to this perception that no one questioned it.

As an external person unburdened by political dynamics, I literally had my work cut out for me.

Solution

Instead of describing the used approach, I’d refer to Tami Reiss’ great talk at Productized 2023 —

You can (and should) watch the entire thing here.

— because she described it much more precisely:

“Where do we want to go?” (WHERE TO?)
“Where are we coming from?” (WHERE FROM?)
“Where do we want to go next? (WHERE NEXT?)

Now, 1. was pretty clear — as the project overall had been well-scoped already.

The team helped me understand 2. — we did find out that the re-write was already approximately 2/3 done.

So 3. was:

Can we easily finish the re-write?
And can we deliver on the most minimal feature scope of the upgrade?

Changing the goal definitions reframed the conversation for the team — it felt less like they were just being asked to hit a set target, but to also help define that target.

Going from a black box to a well-segmented plan. “Design” is my own, all emojis designed by OpenMoji — the open-source emoji and icon project. License: CC BY-SA 4.0

So we decided to commit to “Operation: Third Time’s a Charm” — and went at it for a quarter.

Results

To be fully honest with you — we didn’t finish exactly on time.

It took us two weeks longer.

But — hey, we:

first of all, finally finished the damn project,
were able to deliver pretty much the same value despite reduced scope, and
also finished a bunch of other work and had to deal with the usual day-to-day issues (illness, turnover, reorganization and so forth).

Conclusion

This one may seem obvious, but I’ll re-iterate — there’s a good reason why Tami differentiates between “Where do we want to go?” (WHERE TO?) and “Where do we want to go next? (WHERE NEXT?):

As a product manager, you’re in charge of keeping those two perspectives separately — especially for all your stakeholders.

And if it seems obvious and second-nature to you — it likely isn’t for others.

It’s not their domain of expertise, it’s yours.

And as the bulk of product management work isn’t glamorous evangelization of your newest brilliant framework or being the person with the brightest ideas, but talking to a lot of people and answering a lot of questions over and over:

Be prepared to rather use grit than genius.

Recommendations

Never just accept a “Tried it, didn’t work”. Genuinely bad ideas usually don’t become great ideas over night, but there’s also no guarantee that all ideas that were bad at some point will be irreversably bad for eternity. At least re-open discovery if a topic re-surfaces. Try a different approach. See past mistakes as learning opportunities. Make sure you understand as much of the full picture as you can.
Sharpen your julienne knife — get great at slicing. Try to find the most meaning you can get out of the least work investment possible — it may seem logically straightforward, but this often hinges on
Watch the video if you have the time.

Thank you very much for reading!

If you’d like me to help you with a similar challenge you’re facing, I’m a Freelance Product Manager & Consultant for hire — feel free to reach out to me at hi[@]bertrandrothen.com