I once had a user tell me that the app I had just been pulled in to start working on, already in production, was the worst thing that ever happened to his job.  It was alarming.  I told him I was specifically there to learn about his problems so that I could fix them.  He wasn’t convinced.  He asked who my PO was; and when I told him, he shook his head and walked away.

The Feedback Loop

In all my Scrumming, I’ve started to see a strong disconnect in the way we as developers talk about feedback, and the way that clients and product-owners think about feedback.

We ask questions during standup, and we get feedback.  We ask questions during backlog refinement, and we get feedback.  We demo each sprint, and we get feedback.  We invite the PO to our retro, and we get feedback.  These are all good opportunities for feedback, and its usually where the conversation about feedback stops in a Scrum process.

The problem is that within this feedback loop, no one is talking to the end users, actually on-site working with the app.

End users vs product owners

Let’s face it, the product owner (PO) – in many cases – probably isn’t going to use your application.  They might be a project manger-type (in fact that may even be their job title) whose sole role within the organization is to get software built.  Or they might be a subject matter expert who used to fit the role of the end user, but has since moved on.

The benefits of a disconnected PO

In a rare case, you might have a PO that’s actually going to be an end user.  In terms of developing correctly, that can lead to some dangerous decision making, as you want to make sure you have someone who can take a step back, look at the big picture, and keep consistent with the overarching plan.  That might be according to deliverable timelines, feature priorities, or just generally being able to see the forest through the trees.  Or, as one PO put it to me about his users last week:

Forget about the forest. I’m pretty sure they can’t even see past the bark at this point.

The PM as PO is generally what you want form a dev-cycle standpoint, since they’re not so invested in every small detail that they can make the tough calls about what actually constitutes an MVP.  That’s hard to get from talking to the end-users all the time.  Just as it’s hard to even get end-users to commit to making a standup even twice a week, or making it to a regularly scheduled demo.  Their job is to be out there, doing the thing you’re going to facilitate with your sweet app.  They can’t be on call when questions come up.

Despite all of these benefits, there’s a flip-side, and a cost.

Losing touch with the product

So you develop, your PO answers questions, you make your way through your release backlog, and you ship.  All is right in the world.  Your team looks like rockstars, you PO met another goal of getting features built, and everyone’s happy.

What happens then?  Do you get any time to vet that release through a real-world user acceptance period?  Are members of your dev team ever going on-site for a live beta?  Is your project or its timeline going to make time for feature alignment post-release?

Don’t get me wrong, your PO means well.  But if he’s the disconnected PO outlined above, he probably has a list of features he needs to get checked off before a certain point, and he’s probably more interested in your team moving ahead to start on the next feature, rather than waiting around to see if the one you just built was adequate for your users.

And that’s where things get ugly.

Sounds Like Waterfall

So we ask a lot of questions of the PO as we develop.  Were his answers accurate?  Do we ever find out?  More importantly, does he ever find out?  Or do we just move on and assume everything went well, because we asked a lot of smart questions and changed directions when we needed to?

If it’s the latter, then a lot of things can go wrong.

Sometimes that select element that we built with mock data ends up having over a thousand options once we make it to production.  Or that field that we display as a data record identifier turned out to have duplicate entries in the third-party ERP.  Instead of seeing accurate data as you developed, you were given a subset that may have been accessible for export, but doesn’t represent real-world use.

Maybe your PO didn’t have all of the right answers, and that one thing he said could be left out was actually needed to bypass several steps in the end-user workflow.  Or maybe he thought he had an answer, but he didn’t double-check with the end users.  That can lead to some dangerous results.

If we’re not involved in the tracking of that feedback, it can go into the most over-used bucket-of-whatever since the “More” button in a main navigation – bug-fixes.  And unless the users actually cannot find a way to use the feature you’ve built, bugs are never a top priority.

Fight for your right to be wrong

As developers, we don’t want to see our product go to waste or be the bane of an end-user’s existence – to have the product of our blood, sweat, and tears be the worst thing that ever happened to an end-user’s job.  Our entire existence revolves around (getting paid for) making users’ lives easier through effective software.

Unless we can convince our POs and their bosses to allow for that, we’ll never know what the problems are.  We move on to the next feature, and never get to revisit the software in production to see how effective it is.

This might require a culture change.  It might require a shift in the way your PO is reviewed at the end of every year or every quarter.  If their review depends on them checking off a list of features to be developed within a certain time frame, then you have to ask yourself if the process is truly working, or just facilitating the leftovers of a waterfall mentality.

In an Agile world, the product or the feature is never truly done.  We believe in getting it wrong the n-th time.  We want to hear that it needs to be improved with a little x, a little y, and a whole lotta z, because we want to improve it.

It’s up to us to communicate that to the POs.  When they start talking about how they’ve already started filling the backlog with the next feature, we have to hit the brakes and ask when we’re going to get feedback about the latest release.  We have to ask how he’s going to prioritize feature alignment over feature creation.  While their priorities might be focused on checking off a list of features to be developed, giving a user a feature that doesn’t meet their needs can be as bad as never delivering in the first place.

Comments are closed.